訊息佇列介紹以及對比
一、什麼是訊息佇列
訊息佇列（Message Queue），是分散式系統中重要的元件，主要解決了應用耦合、非同步處理、流量削鋒等問題。當前主要使用的訊息佇列有RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMq等,部分DB類儲存系統也可以實現訊息佇列,本質類似於java的jms,主要實現訊息物件的接收、儲存與傳送。
二、訊息佇列的應用
訊息佇列在實際應用中包括：
1. 應用耦合,多個系統需要呼叫統一介面,對同一引數進行處理,為避免併發呼叫導致系統壓力,導致整個系統失敗。之前公司做的電商系統,屬於一個偽微服務的系統,只是將幾個不是訂單處理的系統分離出來,在物流
2. 非同步處理,多系統對單一系統中的同一訊息都需要進行處理,使用訊息佇列的廣播模式進行併發處理,縮短了時間;
3. 廣泛應用於秒殺或搶購活動中，避免流量過大導致應用系統掛掉的情況；
三、訊息佇列的模式
1.點對點模式:訊息生產者將訊息傳送到佇列中,然後訊息接收者從佇列中取出並消費訊息,被消費的訊息會直接刪除,不會出現重複消費;
特點是:每個訊息只有一個消費者,傳送者和消費者沒有依賴關係,消費者消費成功之後會響應訊息佇列,以便刪除訊息;
2.釋出/訂閱模式:釋出者將A主題的訊息傳送到訊息佇列,消費者可以根據主題消費響應的訊息,或佇列將訊息推送給消費者
特點:每個訊息可以被多個消費者消費,消費者和生產者之間有時間依賴性;為了消費訊息,訂閱者需要提前訂閱該角色主題;
四、接觸過的訊息佇列的對比
第一個公司做的電商專案中用到了ActiveMQ進行訂單處理和秒殺系統的處理,第二個公司使用RabbitMQ作為分散式系統的訊息通訊,非同步處理和削鋒的工具,因為使用,所以調研過MQ,加上RocketMQ是馬家的,所以關注了一下,以下是這三個MQ的對比:
ActiveMQ | RabbitMQ | RocketMQ | |
關注度 | 高 | 高 | 中 |
成熟度 | 成熟 | 成熟 | 比較成熟 |
社群 | Apache | Mozilla開源社群 | Alibaba |
社群活躍度 | 高 | 高 | 中 |
文件 | 多 | 多 | 少 |
特點 | 功能齊全,被大量使用 | 由於Erlang語言的併發能力，使得效能很好 | 各個環節分散式擴充套件設計，主從高可用群集；支援上萬個佇列；多種消費模式；效能很好 |
開源 | 開源 | 開源 | 開源 |
語言 | Java | Erlang(面向併發程式語言) | Java |
Client語言 | 支援Java | 支援Java | 支援Java |
支援協議 | OpenWire、STOMP、REST、XMPP、AMQP | AMQP | 自定義的一套，提供了支援JMS客戶端的API |
持久化 | 記憶體,檔案,資料庫 | 記憶體,檔案 | 磁碟檔案 |
事務 | 支援 | 不支援 | 支援 |
叢集和負載均衡 | 支援 | 支援 | 支援 |
管理頁面 | 一般 | 好 | 無 |
部署方式 | 獨立,嵌入 | 獨立 | 獨立 |
評價 | 優點：成熟的產品，已經在很多公司得到應用（非大規模場景）。有較多的文件。各種協議支援較好，有多重語言的成熟的客戶端； 缺點：根據其他使用者反饋，會出莫名其妙的問題，並且會丟訊息。其重心放到activemq6.0產品—apollo上去了，目前社群不活躍，且對5.x維護較少； Activemq 不適合用於上千個佇列的應用場景 | 優點：由於erlang語言的特性，mq效能較好；管理介面較豐富，在網際網路公司也有較大規模的應用；支援amqp協議，有多中語言且支援 amqp 的客 戶端可用。 缺點：erlang語言難度較大。 | 優點：模型簡單，介面易用。在阿里大規模應用。目前支付寶中的餘額寶等新興產品均使用rocketmq。叢集規模大概在50臺左右，單日處理訊息上百億；效能非常好，可以大量堆積訊息在 broker 中；支援多種消費，包括叢集消費、廣播消費等。開發度較活躍，版本 更新很快。 缺點：產品較新，文件比較缺乏。沒有在 mq 核心中去實現 JMS 等介面，對 已有系統而言不能相容。 |
五、總結
綜合以上來看,三種MQ各有優劣,ActiveMQ和RabbitMQ相對成熟,使用起來略微順手,網上文件也很多,坑基本上被踩完了,前者使用java寫的,學習成本低,後者使用Elang語言比較難以學習,都支援出就花和叢集,唯一的是RabbitMQ不支援事務,但是公司現在也用不到這個。RabbitMQ是阿里自己開發的,設計的很強大,但是肯定會偏向阿里的業務,不一定對所有的公司都適合,加上文件少,不是很成熟,沒有深厚的技術底蘊,難以放心的使用;總之,技術沒有最好的,只有最適合的,貼合自己公司的業務和實際情況選出來的就是最好的!