億級流量系統架構之如何保證百億流量下的數據一致性（下）？【石杉的架構筆記】

歡迎關注我的公衆號：石杉的架構筆記（ID:shishan100）

週一至週五早8點半！精品技術文章準時送上！

目錄

1、前情提示

2、選擇性訂閱部分核心數據

3、RabbitMQ的queue與exchange的綁定回顧

4、direct exchange實現消息路由

5、按需訂閱數的代碼實現

6、更增強大並且靈活的按需訂閱

一、前情提示

上一篇文章《億級流量系統架構之如何保證百億流量下的數據一致性（中）？》，咱們已經給出了一整套的數據一致性的保障方案。

咱們從以下三個角度，給出了方案如何實現。而且經過數據平臺和電商系統進行了舉例分析。

• 核心數據的監控
• 數據鏈路追蹤
• 自動化數據鏈路分析

目前爲止，咱們的架構圖大概以下所示：

而且我們以前對於這種架構下，如何基於MQ進行解耦的實現也作了詳細的說明。

有不清楚的同窗，能夠具體看一下以前的三篇文章：

一、億級流量系統架構之如何在上萬併發場景下設計可擴展架構（上）？

二、億級流量系統架構之如何在上萬併發場景下設計可擴展架構（中）？

三、億級流量系統架構之如何在上萬併發場景下設計可擴展架構（下）？

那麼這篇文章，咱們就基於這個架構，在數據一致性方面作進一步的說明。一樣，咱們以RabbitMQ這個消息中間件來舉例。

二、選擇性的訂閱部分核心數據

首先一個基於MQ實現的細節點就在於，好比對數據監控系統而言，他可能僅僅只是要從MQ裏訂閱部分數據來消費罷了。

這個是啥意思呢？由於好比實時計算平臺他是會將本身計算出來的全部的數據指標都投遞到MQ裏去的。

可是這些數據指標多是多達幾十個甚至是幾百個的，這裏面不可能全部數據指標都是核心數據吧？

基本上按照咱們過往經驗而言，對於這種數據類的系統核心數據指標，大概就佔到10%左右的比例而已。

而後對於數據查詢平臺而言，他多是須要把全部的數據指標都消費出來，而後落地到本身的存儲裏去的。

可是對於數據監控系統而言，他只須要過濾出10%的核心數據指標便可，因此他須要的是有選擇性的訂閱數據。

我們看看下面的圖，立馬就明白是什麼意思了。

三、RabbitMQ的queue與exchange的綁定

不知道你們是否還記得以前講解基於RabbitMQ實現多系統訂閱同一份數據的場景。

咱們採用的是每一個系統使用本身的一個queue，可是都綁定到一個fanout exchange上去，而後生產者直接投遞數據到fanout exchange。

fanout exchange會分發一份數據，綁定到本身的全部queue上去，而後各個系統都會從本身的queue裏拿到相同的一份數據。

你們再看看下面的圖回顧一下。

在這裏有一個關鍵的代碼以下所示：

也就是說，把本身建立的queue綁定到exchange上去，這個綁定關係在RabbitMQ裏有一個專業的術語叫作：binding。

四、direct exchange實現消息路由

若是僅僅使用以前的fanout exchange，那麼是沒法實現不一樣的系統按需訂閱數據的，若是要實現容許不一樣的系統按需訂閱數據，那麼須要使用direct exchange。

direct exchange容許你在投遞消息的時候，給每一個消息打上一個routing key。同時direct exchange還容許binding到本身的queue指定一個binding key。

這樣，direct exchange就會根據消息的routing key將這個消息路由到相同binding key對應的queue裏去，這樣就能夠實現不一樣的系統按需訂閱數據了。

說了這麼多，是否是感受有點暈，老規矩，我們來一張圖，直觀的感覺一下怎麼回事兒：

並且一個queue是可使用多個binding key的，好比說使用「k1」和「k2」兩個binding key的話，那麼routing key爲「k1」和「k2」的消息都會路由到那個queue裏去。

同時不一樣的queue也能夠指定相同的ruoting key，這個時候就跟fanout exchange實際上是同樣的了，一個消息會同時路由到多個queue裏去。

五、按需訂閱的代碼實現

首先在生產者那塊，好比說實時計算平臺吧，他就應該是要定義一個direct exchange了。

以下代碼所示，全部的數據都是投遞到這個exchange裏去，好比咱們這裏使用的exchange名字就是「rt_data」，意思就是實時數據計算結果，類型是「direct」：

channel.exchangeDeclare(
                "rt_data", 
                "direct");
複製代碼

並且，在投遞消息的時候，要給一個消息打上標籤，也就是他的routing key，代表這個消息是普通數據仍是核心數據，這樣才能實現路由，以下代碼所示：

上面第一個參數是指定要投遞到哪一個exchange裏去，第二個參數就是routing key，這裏的「common_data」表明了是普通數據，也能夠用「core_data」表明核心數據，實時計算平臺根據本身的狀況指定普通或者核心數據。

而後消費者在進行queue和exchange的binding的時候，須要指定binding key，代碼以下所示：

上面第一行就是在消費者那裏，好比數據監控系統那裏，也是定義一下direct exchange。

而後第二行就是定義一個「rt_data_monitor「這個queue。

第三行就是對queue和exchange進行綁定，指定了binding key是「core_data」。

若是是數據查詢系統，他是普通數據和核心數據都要的，那麼就能夠在binding key裏指定多個值，用逗號隔開，以下所示：

channel.queueBind(
                "rt_data_query", 
                "rt_data", 
                "common_data, core_data");
複製代碼

到這裏，你們就明白如何對數據打上不一樣的標籤（也就是routing key），而後讓不一樣的系統按需訂閱本身須要的數據了（也就是指定binding key），這種方式用到了direct exchange這種類型，很是的靈活。

最後，再看看以前畫的那幅圖，你們再來感覺一下便可：

六、更增強大並且靈活的按需訂閱

RabbitMQ還支持更增強大並且靈活的按需數據訂閱，也就是使用topic exchange，其實跟direct exchange是相似的，只不過功能更加的強大罷了。

好比說你定義一個topic exchange，而後routing key就須要指定爲用點號隔開的多個單詞，以下所示：

而後，你在設置binding key的時候，他是支持通配符的。 * 匹配一個單詞，# 匹配0個或者多個單詞，好比說你的binding key能夠這麼來設置：

這個product.*.* ，就會跟「product.common.data」匹配上，意思就是，可能某個系統就是對商品類的數據指標感興趣，無論是普通數據仍是核心數據。

因此到這裏，你們就應該很容易明白了，經過RabbitMQ的direct、topic兩種exchange，咱們能夠輕鬆實現各類強大的數據按需訂閱的功能。

經過本文，咱們就將最近講的數據一致性保障方案裏的一些MQ中間件落地的細節給你們說明白了。

end

若有收穫，請幫忙轉發，您的鼓勵是做者最大的動力，謝謝！

一大波微服務、分佈式、高併發、高可用的原創系列文章正在路上

歡迎掃描下方二維碼，持續關注：

石杉的架構筆記（id:shishan100）

十餘年BAT架構經驗傾囊相授

推薦閱讀：

一、拜託！面試請不要再問我Spring Cloud底層原理

二、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問？

三、【性能優化之道】每秒上萬併發下的Spring Cloud參數優化實戰

四、微服務架構如何保障雙11狂歡下的99.99%高可用

五、兄弟，用大白話告訴你小白都能聽懂的Hadoop架構原理

六、大規模集羣下Hadoop NameNode如何承載每秒上千次的高併發訪問

七、【性能優化的祕密】Hadoop如何將TB級大文件的上傳性能優化上百倍

八、拜託，面試請不要再問我TCC分佈式事務的實現原理坑爹呀！

九、【坑爹呀！】最終一致性分佈式事務如何保障實際生產中99.99%高可用？

十、拜託，面試請不要再問我Redis分佈式鎖的實現原理！

十一、【眼前一亮！】看Hadoop底層算法如何優雅的將大規模集羣性能提高10倍以上？

十二、億級流量系統架構之如何支撐百億級數據的存儲與計算

1三、億級流量系統架構之如何設計高容錯分佈式計算系統

1四、億級流量系統架構之如何設計承載百億流量的高性能架構

1五、億級流量系統架構之如何設計每秒十萬查詢的高併發架構

1六、億級流量系統架構之如何設計全鏈路99.99%高可用架構

1七、七張圖完全講清楚ZooKeeper分佈式鎖的實現原理

1八、大白話聊聊Java併發面試問題之volatile究竟是什麼？

1九、大白話聊聊Java併發面試問題之Java 8如何優化CAS性能？

20、大白話聊聊Java併發面試問題之談談你對AQS的理解？

2一、大白話聊聊Java併發面試問題之公平鎖與非公平鎖是啥？

2二、大白話聊聊Java併發面試問題之微服務註冊中心的讀寫鎖優化

2三、互聯網公司的面試官是如何360°無死角考察候選人的？（上篇）

2四、互聯網公司面試官是如何360°無死角考察候選人的？（下篇）

2五、Java進階面試系列之一：哥們，大家的系統架構中爲何要引入消息中間件？

2六、【Java進階面試系列之二】：哥們，那你說說系統架構引入消息中間件有什麼缺點？

2七、【行走的Offer收割機】記一位朋友斬獲BAT技術專家Offer的面試經歷

2八、【Java進階面試系列之三】哥們，消息中間件在大家項目裏是如何落地的？

2九、【Java進階面試系列之四】扎心！線上服務宕機時，如何保證數據100%不丟失？

30、一次JVM FullGC的背後，竟隱藏着驚心動魄的線上生產事故！

3一、【高併發優化實踐】10倍請求壓力來襲，你的系統會被擊垮嗎？

3二、【Java進階面試系列之五】消息中間件集羣崩潰，如何保證百萬生產數據不丟失？

3三、億級流量系統架構之如何在上萬併發場景下設計可擴展架構（上）？

3四、億級流量系統架構之如何在上萬併發場景下設計可擴展架構（中）？

3五、億級流量系統架構之如何在上萬併發場景下設計可擴展架構（下）？

3六、億級流量架構第二彈：你的系統真的無懈可擊嗎？

3七、億級流量系統架構之如何保證百億流量下的數據一致性（上）

3八、億級流量系統架構之如何保證百億流量下的數據一致性（中）？

做者：石杉的架構筆記 連接：https://juejin.im/post/5c263a936fb9a049ec6b2688 來源：掘金 著做權歸做者全部，轉載請聯繫做者得到受權！