超詳細的RabbitMQ入門與實戰介紹,看這篇文章就夠了
一、前情提示
上一篇文章《 教你面試的時候如何迅速完成90%以上的海量資料處理題 》,我們已經給出了一整套的資料一致性的保障方案。
我們從如下三個角度,給出了方案如何實現。並且通過資料平臺和電商系統進行了舉例分析。
- 核心資料的監控。
- 資料鏈路追蹤。
- 自動化資料鏈路分析。
目前為止,我們的架構圖大概如下所示:
並且咱們之前對於這種架構下,如何基於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中介軟體落地的細節給大家說明白了。
- Spring中實現非同步呼叫的方式有哪些?
- 帶引數的全型別 Python 裝飾器
- 整理了幾個Python正則表示式,拿走就能用!
- 設計模式之狀態模式
- 如何實現資料庫讀一致性
- SOLID:開閉原則Go程式碼實戰
- React中如何引入CSS呢
- 慢查詢 MySQL 定位優化技巧,從10s優化到300ms
- 一個新視角:前端框架們都卷錯方向了?
- 編碼中的Adapter,不僅是一種設計模式,更是一種架構理念與解決方案
- 手寫程式語言-遞迴函式是如何實現的?
- 一文搞懂模糊匹配:定義、過程與技術
- 新來個阿里 P7,僅花 2 小時,做出一個多執行緒永動任務,看完直接跪了
- Puzzlescript,一種開發H5益智遊戲的引擎
- @Autowired和@Resource到底什麼區別,你明白了嗎?
- “四招”守護個人資訊保安
- CSS transition 小技巧!如何保留 hover 的狀態?
- React如此受歡迎離不開這4個主要原則
- 我是怎麼入行做風控的
- 重溫三十年前對於 NN 的批判:神經網路無法實現可解釋 AI