#程式設計師# #訊息佇列# #技術分析# #dev# #技術乾貨#

今天調研了一下行業裡的訊息佇列技術，把重點總結了一下成大綱，分享給大家。

訊息佇列的協議 AMQP：高階訊息佇列協議（AMQP，Advanced Message Queuing Protocol），RabbitMQ 和 HornetQ 都實現了該協議。 優勢：功能最豐富，能夠適用最多的場景。 劣勢：其實現上不輕量化。 應用場景：簡單的pub/sub模型無法滿足要求的場景。 ZeroMQ：這是一種協議，也是一個開源元件，無中心化的broker。 優勢：無中心化，速度很快。 劣勢：學習曲線比較高。 應用場景：需要海量吞吐和無單點故障的場景 STOMP：面向流文字的訊息傳輸協議（STOMP，Streaming Text Oriented Messaging Protocol），是 WebSocket 通訊標準。在通常的釋出－訂閱語義之上，它透過 begin/publish/commit 序列以及 acknowledgement 機制來提供訊息可靠投遞。 優勢：由於協議簡單且易於實現，幾乎所有的程式語言都有 STOMP 的客戶端實現。 劣勢：但是在訊息大小和處理速度方面並無優勢。 應用場景：資訊交換基於文字，適用要求簡單的場景。 MQTT：一種二進位制的協議，MQTT（Message Queue Telemerty Transport），主要用於伺服器和那些低功耗的物聯網裝置（IoT）之間的通訊。它位於 TCP 協議的上層，除了提供釋出－訂閱這一基本功能外，也提供一些其它特性：不同的訊息投遞保障（delivery guarantee），“至少一次”和“最多一次”。透過儲存最後一個被確認接受的訊息來實現重連後的訊息恢復。Mosquitto和VerneMQ實現了MQTT協議。 優勢：它非常輕量級，並且從設計和實現層面都適合用於不穩定的網路環境中。 劣勢：實現的很簡單，因為就是面向嵌入式物聯網場景的。 應用場景：物聯網（IoT）場景中更適合，支援幾乎所有語言進行開發，並且瀏覽器也可透過 WebSocket 來發送和接收 MQTT 訊息。 JMS：Java 訊息服務（JMS，Java Messaging Service），是一種協議，同時也是 Java 訊息服務規範的標準實現。JMS可以用來實現 請求/響應 模式的遠端過程呼叫 RPC(Remote Procedure Calls)/RMI(Remote Method Invocation)。AMQP和ZeroMQ是透過響應佇列（response-queue）來實現這種模式，而JMS可以直接實現RMI。 優勢：直接可以進行RMI。 劣勢：？ 應用場景：不引入其他元件，直接用java實現RMI 。

訊息佇列中介軟體

RabbitMQ ActiveMQ：同時支援amqp，mqtt，openwire，stomp。 Apache RocketMQ：由阿里巴巴開源，使用自定義協議 ，不支援AMQP。 Redis Kafka：由linkedin使用自定義協議 ，不支援AMQP。 memcacheq LightQ：LightQ是一個基於MIT協議開源的高效能代理訊息佇列，它支援瞬態（每秒1M的效能）和持久化（每秒300k左右的效能）兩種佇列。LightQ的持久化佇列類似於Kafka，即首先資料寫入到檔案，而由消費者再從檔案中讀取資料。

知識大綱就是這些了，後面的文章再依次分享各個重點技術或者軟體。