大規模分布式消息中間件簡介

目前各種RPC中間件技術已經廣泛應用于各個領域。其中，伺服器之間消息通訊這種功能廣泛應用于這些中間件中，于是，将這種面向消息的中間件（Message Oriented Middleware，MOM）抽象出來，形成通用的消息中間件，成為業内主流。目前消息中間件的标準主要有：JMS和AMQP。實作則是百花齊放。

消息中間件從功能上需要解決以下問題：

1. 同步或異步的消息傳輸，尤其是異步的消息傳輸

同步發送消息是發送消息後，阻塞等待消息是否發送成功的回饋，如果設定有逾時時間，則逾時後跳出阻塞狀态。

異步發送消息是發送消息後，不阻塞立即執行其他操作。如果關心消息是否發送成功，則可以通過回調函數（Java中的Listener）處理消息是否成功。

2. 消息的安全性，消息中間件對持久的支援

在分布式系統中，消息從發送到接收，環節非常多，沒有任何一個環節是安全的，而任何環節出了問題，都會導緻丢消息。當有需求是，我們必須保證在不是絕對安全的多環節裡，完成消息安全的傳輸。這其中，消息中間的持久是非常重要的。

3. 消息的重發性

如果使用的系統保證了幂等性，則對此沒有要求。否則，有些場景需要保證消息不重發。在既要保證消息安全，又要保證消息不重發，是非常困難的。目前業内還沒有人能解決此問題。

目前，在有消息重發的情況下，使用的系統都是使用狀态機保證了系統對消息的幂等性。

4. 消息的順序性

如果使用的系統有要求，則有可能需要保證消息的順序。在大規模分布式不可靠環境下，在保證消息傳輸高效和消息安全的情況下，要解決此問題，也是非常困難的。

如果隻是小規模的系統，對性能要求不高，可以以伺服器時間為準，使用排隊隊列即可解決。

如果以發送端時間為準，并且保持順序的消息由此一個發送端發送，則使用消息序号即可解決。

另外，有些系統隻需要滿足局部的消息順序性，在排序消息數量不大的情況下，可以使用多條排序消息一次性發送解決。

5. 消息傳輸模型：點對點的傳輸消息（PTP），訂閱/釋出模型（Pub/Sub）

PTP，就是你在消息方設定消息接收者的唯一辨別符，然後，消息發送方和消息接受方建立一一對應的關系。消息發送方發送所有的消息都被消息接收方接收。

Pub/Sub，就是消息發送方和消息接收方都确定自己的發送和接收消息的标簽（或者你可以了解為組GroupID），所有有這個标簽的消息，訂閱了這個标簽的消息接收方一定能接收到。

JMS（Java消息服務，Java Message Service）是專用于J2EE的一種消息中間件規範。它主要做了接口上的規範，消息傳輸模型和消息類型的規範，并沒有給予實作。同樣，它也完全沒有給出伺服器端的架構，你甚至可以不使用伺服器直接在用戶端之間傳輸消息（雖然可能最終結果隻是一個玩具）。http://java.sun.com/products/jms/docs.html。 JMS也沒有規定消息的順序，安全，重發等特性。

AMQP（進階消息隊列協定，The Advanced Message Queuing Protocol）是一種和語言無關的，在金融行業使用的新興消息中間件，目前成為消息中間件圈内關注的焦點。與JMS規範了API不同，它是一個異步消息傳遞所使用的應用層協定規範。AMQP的原始用途隻是為金融界提供一個可以彼此協作的消息協定，而現在的目标則是為通用消息隊列架構提供通用建構工具。http://www.amqp.org/

出處：http://blog.csdn.net/huyiyang2010/article/details/5969944

版權申明：内容來源網絡，版權歸原創者所有。除非無法确認，我們都會标明作者及出處，如有侵權煩請告知，我們會立即删除并表示歉意。謝謝。

-END-