項目中要用到RabbitMQ,上司讓我先了解一下。在之前的公司中,用到過消息隊列MQ,阿裡的那款RocketMQ,當時公司也做了簡單的技術分享,自己也看了一些部落格。自己在有道雲筆記上,做了一些整理,但後來也就擱在那了。現在有時間,就對MQ的一些簡單的概念做下整理吧。
RabbitMQ的一些介紹,請參考https://www.jianshu.com/p/e55e971aebd8,裡面對一些概念和使用的講解還是非常詳細的。
什麼是消息隊列-定義
我們來看下維基百科上面的定義:
是一種程序間通信或同一程序的不同線程間的通信方式,軟體的軟體的貯列用來處理一系列的輸入,通常是來自使用者。
消息隊列提供了異步的通信協定,每一個貯列中的紀錄包含詳細說明的資料,包含發生的時間,輸入裝置的種類,以及特定的輸入參數。
也就是說:消息的發送者和接收者不需要同時與消息隊列互動。消息會儲存在隊列中,知道接收者取回它。
下面是架構圖:
![](https://img.laitimes.com/img/9ZDMuAjOiMmIsIjOiQnIsISPrdEZwZ1Rh5WNXp1bwNjW1ZUba9VZwlHdsATOfd3bkFGazxCMx8VesATMfhHLlN3XnxCMwEzX0xiRGZkRGZ0Xy9GbvNGLpZTY1EmMZVDUSFTU4VFRR9Fd4VGdsYTMfVmepNHLrJXYtJXZ0F2dvwVZnFWbp1zczV2YvJHctM3cv1Ce-cmbw5iY1MTYlZjY3IjZzY2N2IWOyETM2cTNhVzYiJjZzMmMl9CX0IzLcRDMxIDMy8CXn9Gbi9CXzV2Zh1WavwVbvNmLvR3YxUjL4M3Lc9CX6MHc0RHaiojIsJye.png)
Producer:消息生産者,負責生産和發送消息到Broker;
Broker:消息進行中心,負責消息存儲、确認、重試等;
Consumer:消息消費中心,負責從Broker中擷取消息并處理。
消息隊列-特性
異步性:将耗時的同步任務通過發送消息的方式進行異步處理,減少等待時間。
松耦合:不同系統、服務之間可以通過消息隊列進行通信,不用關心彼此的實作細節,資料格式一緻。
分布式:為了防止消息堵塞,可以對消費者叢集進行橫向擴充,避免單點故障,同樣隊列本身也可以。
可靠性:将接收到的消息落盤,就算伺服器重新開機或者發生故障,恢複之後也能重新加載。
應用場景-簡單描述
根據特性,應用場景可以簡單描述為:
在處理高并發,而且不需要立即擷取結果的時候。
常用的消息隊列有:
RabbitMQ,RocketMQ,ActiveMQ,Kafka等。資料庫Redis或者MySQL也可以實作消息隊列模式。Redis實作消息隊列模式可以參考之前的一篇介紹Redis的随筆
應用場景-異步處理
應用場景-應用解耦
應用場景-限流削峰
應用場景-日志處理
消息模式介紹-簡介
1、點對點模式:REQ/REP
最基本的模式,生産者發送一條消息,消費者去除并消費資訊,給出響應後會從隊列中删除該消息,是以不能重複發送,隻能被一個消費者消費。
2、釋出/訂閱模式:Pub/Sub
非常常見也是非常有用的一種模式,将釋出者與訂閱者進行解耦。釋出者隻負責生産資料,而不需要關心誰是訂閱者,有多少訂閱者。類比于微信公衆号。
3、推/拉模式:Push/Pull
也是一種比較重要的模式,無論是Push端還是Pull端都可以做伺服器,綁定到特定的位址等待對方通路。
如果我們在Push端綁定位址,那麼這是一個PushServer,對應的PullClient可以連結到這個PushServer往外拉資料;反之,如果建立一個PullServer,對應的PushClient就可以連結到PullServer并往裡面壓資料。
4、路由/代理模式:Router/Dealer
是一種典型的中間人模式,比較适用于多對多的網絡當中,雙方在互相不認識的情況下達成共識并交易。類比于:顧客--->逾時<--供應商。
使用TurboMQ的注意事項:
1、避免多線程處理消息,減少異步請求,不要開多餘的Task去處理消息
2、減少無效的重複推送,高并發下可以利用Redis做一些去重處理。
下圖是市場上的一些消息隊列MQ: