消息隊列是什麼,或者說什麼是消息隊列、你用過哪些消息隊列,幾乎是在求職面試中經常問到的問題,我自己也經常問面試者這個問題,簡單說消息隊列是一個能先進先出且存儲消息的容器。
基本組成部分
![](https://img.laitimes.com/img/9ZDMuAjOiMmIsIjOiQnIsISPrdEZwZ1Rh5WNXp1bwNjW1ZUba9VZwlHdsATOfd3bkFGazxCMx8VesATMfhHLlN3XnxCMwEzX0xiRGZkRGZ0Xy9GbvNGLpZTY1EmMZVDUSFTU4VFRR9Fd4VGdsYTMfVmepNHLrJXYtJXZ0F2dvwVZnFWbp1zczV2YvJHctM3cv1Ce-cGcq5CM3gDM5IzN4IWM5IDZiFjNxYzX5QjMwADMwEzLcBTMxIDMy8CXn9Gbi9CXzV2Zh1WavwVbvNmLvR3YxUjL4M3Lc9CX6MHc0RHaiojIsJye.jpg)
基本的消息隊列主要有生産者(Producer)、代理(Broker)、消費者(Consumer)組成。
生産者:消息的産生者,消息的調用端,主要負責消息具體承載的資訊的執行個體化,具體一個隊列的發起方
代理:隊列的大腦,主要的處理單元,負責消息的存儲、投遞、及各種隊列附加功能的實作,是消息隊列最核心的組成部分
消費者:一個消息隊列的終端,也是消息的調用端,具體是根據消費的消息承載的資訊,處理各種業務業務邏輯
目前市場上常用的MQ中間件基本上都是基于這3個主要的基礎元件擴充而成的,尤其是擴充代理,比如延遲隊列、主題 等等
使用場景
消息隊列使用的場景非常多,常見的有異步處理、應用解耦、流量削峰等等
異步處理
異步處理主要應用于對實時性要求不嚴格的場景,比如:使用者注冊發送驗證碼、下單通知、發送優惠券等等。A服務隻需要把協商好的消息發送到消息隊列,剩下的有消費消息的服務去處理就好,不用等待消費服務傳回結果。
應用解耦
應用解耦可以看作是把相關但耦合度不高的系統聯系起來,比如,訂單系統與WMS、EHR系統,有關聯但又不是哪麼緊密,每個系統之間隻需要把約定的消息發送到MQ,另外的系統去消費即可,同時也解決了各個系統可以采用不同的架構、語言來實作,極大的增加了整個大系統的靈活性。
流量削峰
流量削峰一般應用在大流量入口且短時間内業務需求處理不完的服務中心,為了權衡高可用,把大量的并行任務發送到MQ中,依據MQ的存儲及分發功能,平穩的處理後續的業務,起到一個大流量緩沖的作用。
常見消息隊列
目前常見的消息隊列有ActiveMQ、RabbitMQ、Kafka、RocketMQ。但真正項目中使用的是後3種,ActiveMQ在實際的項目中并不常用,一般作為教程了解原理還是不錯的。另外要說明的是下列對比的表格并不完整,比如:RabbitMQ支援死信隊列,RocketMQ支援事務消息,還有跟Kafka對标的的Pulsar,并沒有列出,想具體了解每個MQ,建議針去檢視官方資料。
<col>
特性
ActiveMQ
RabbitMQ
Kafka
RocketMQ
PRODUCER-COMSUMER
支援
PUBLISH-SUBSCRIBE
REQUEST-REPLY
-
API完備性
高
低(靜态配置)
多語言支援
支援,JAVA優先
語言無關
單機呑吐量
萬級
十萬級
單機萬級
消息延遲
微秒級
毫秒級
可用性
高(主從)
非常高(分布式)
消息丢失
低
理論上不會丢失
消息重複
可控制
理論上會有重複
文檔的完備性
中
提供快速入門
有
無
首次部署難度
總結
在現在的項目中,不管是TO C還是TO B ,消息隊列(MQ)幾乎是标配的中間件,建議在熟悉原理的基礎上,并能清楚每種消息中間件的不同點,這樣才能根據業務需求的場景更有效的采用合适的中間件。知識的積累在于沉澱,我們共同進步,做新時代的農民工。