億級流量系統架構之如何保證百億流量下的資料一致性（下）？【石杉的架構筆記】
歡迎關注個人公眾號：石杉的架構筆記（ID:shishan100）
週一至週五早8點半！精品技術文章準時送上！
目錄
一、前情提示
二、選擇性訂閱部分核心資料
三、RabbitMQ的queue與exchange的繫結回顧
四、direct exchange實現訊息路由
五、按需訂閱數的程式碼實現
六、更加強大而且靈活的按需訂閱
1、前情提示
上一篇文章《億級流量系統架構之如何保證百億流量下的資料一致性（中）？》，我們已經給出了一整套的資料一致性的保障方案。
我們從如下三個角度，給出了方案如何實現。並且通過資料平臺和電商系統進行了舉例分析。
- 核心資料的監控
- 資料鏈路追蹤
- 自動化資料鏈路分析
目前為止，我們的架構圖大概如下所示：
並且咱們之前對於這種架構下，如何基於MQ進行解耦的實現也做了詳細的說明。
有不清楚的同學，可以具體看一下之前的三篇文章：
1、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（上）？
2、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（中）？
3、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（下）？
那麼這篇文章，我們就基於這個架構，在資料一致性方面做進一步的說明。同樣，我們以RabbitMQ這個訊息中介軟體來舉例。
2、選擇性的訂閱部分核心資料
首先一個基於MQ實現的細節點就在於，比如對資料監控系統而言，他可能僅僅只是要從MQ裡訂閱部分資料來消費罷了。
這個是啥意思呢？因為比如實時計算平臺他是會將自己計算出來的所有的資料指標都投遞到MQ裡去的。
但是這些資料指標可能是多達幾十個甚至是幾百個的，這裡面不可能所有資料指標都是核心資料吧？
基本上按照我們過往經驗而言，對於這種資料類的系統核心資料指標，大概就佔到10%左右的比例而已。
然後對於資料查詢平臺而言，他可能是需要把所有的資料指標都消費出來，然後落地到自己的儲存裡去的。
但是對於資料監控系統而言，他只需要過濾出10%的核心資料指標即可，所以他需要的是有選擇性的訂閱資料。
咱們看看下面的圖，立馬就明白是什麼意思了。
3、RabbitMQ的queue與exchange的繫結
不知道大家是否還記得之前講解基於RabbitMQ實現多系統訂閱同一份資料的場景。
我們採用的是每個系統使用自己的一個queue，但是都繫結到一個fanout exchange上去，然後生產者直接投遞資料到fanout exchange。
fanout exchange會分發一份資料，繫結到自己的所有queue上去，然後各個系統都會從自己的queue裡拿到相同的一份資料。
大家再看看下面的圖回顧一下。
在這裡有一個關鍵的程式碼如下所示：
也就是說，把自己建立的queue繫結到exchange上去，這個繫結關係在RabbitMQ裡有一個專業的術語叫做：binding。
4、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裡去。
5、按需訂閱的程式碼實現
首先在生產者那塊，比如說實時計算平臺吧，他就應該是要定義一個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這種型別，非常的靈活。
最後，再看看之前畫的那幅圖，大家再來感受一下即可：
6、更加強大而且靈活的按需訂閱
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架構經驗傾囊相授
推薦閱讀：2、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問？
3、【效能優化之道】每秒上萬併發下的Spring Cloud引數優化實戰
6、大規模叢集下Hadoop NameNode如何承載每秒上千次的高併發訪問
7、【效能優化的祕密】Hadoop如何將TB級大檔案的上傳效能優化上百倍
8、拜託，面試請不要再問我TCC分散式事務的實現原理坑爹呀！
9、【坑爹呀！】最終一致性分散式事務如何保障實際生產中99.99%高可用？
11、【眼前一亮！】看Hadoop底層演算法如何優雅的將大規模叢集效能提升10倍以上？
16、億級流量系統架構之如何設計全鏈路99.99%高可用架構
18、大白話聊聊Java併發面試問題之volatile到底是什麼？
19、大白話聊聊Java併發面試問題之Java 8如何優化CAS效能？
20、大白話聊聊Java併發面試問題之談談你對AQS的理解？
21、大白話聊聊Java併發面試問題之公平鎖與非公平鎖是啥？
22、大白話聊聊Java併發面試問題之微服務註冊中心的讀寫鎖優化
23、網際網路公司的面試官是如何360°無死角考察候選人的？（上篇）
24、網際網路公司面試官是如何360°無死角考察候選人的？（下篇）
25、Java進階面試系列之一：哥們，你們的系統架構中為什麼要引入訊息中介軟體？
26、【Java進階面試系列之二】：哥們，那你說說系統架構引入訊息中介軟體有什麼缺點？
27、【行走的Offer收割機】記一位朋友斬獲BAT技術專家Offer的面試經歷
28、【Java進階面試系列之三】哥們，訊息中介軟體在你們專案裡是如何落地的？
29、【Java進階面試系列之四】扎心！線上服務宕機時，如何保證資料100%不丟失？
30、一次JVM FullGC的背後，竟隱藏著驚心動魄的線上生產事故！
31、【高併發優化實踐】10倍請求壓力來襲，你的系統會被擊垮嗎？
32、【Java進階面試系列之五】訊息中介軟體叢集崩潰，如何保證百萬生產資料不丟失？
33、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（上）？
34、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（中）？
35、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（下）？
作者：石杉的架構筆記
連結：https://juejin.im/post/5c263a936fb9a049ec6b2688
來源：掘金
著作權歸作者所有，轉載請聯絡作者獲得授權！