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

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