1.消息中間件在分佈式系統中的作用介紹
消息中間件是在分佈式系統中完成消息的發送和接收的基礎軟件。
1.1消息中間件可利用高效可靠的消息傳遞機制進行平臺無關的數據交流，
並基於數據通信來進行分佈式系統的集成。通過提供消息傳遞和消息
排隊模型，可以在分佈式環境下擴展進程間的通信。
通過消息中間件，應用程序或組件之間可以進行可靠的異步通訊，從而
降低系統之間的耦合度，提高系統的可擴展性和可用性。
1.2通過使用消息中間件對Dubbo服務間的調用進行解耦
總結：
1.分佈式服務間的異步通信
2.對Dubbo服務間的調用進行解耦
3.通過異步提高程序響應速度
異步通訊、解耦、併發緩衝
2.JMS（Java Message Service）
JMS是JavaEE中的一個關於消息的規範，是一套與具體平臺無關的API。
JMS元素
JMS提供者—-連接面向消息中間件的，JMS接口的一個實現。
JMS客戶——生產或消費消息的基於Java的應用程序或對象。
JMS生產者—-創建併發送消息的JMS客戶。
JMS消費者—-接收消息的JMS客戶。
JMS消息——可以在JMS客戶之間傳遞的數據的對象
JMS隊列——一個容納那些被髮送的等待閱讀的消息的區域。
JMS主題——一種支持發送消息給多個訂閱者的機制。
JMS應用程序接口
ConnectionFactory（連接工廠）——用戶用來創建到JMS提供者的連接的被管對象。
Connection（連接）——————-連接代表了應用程序和消息服務器之間的通信鏈路。
Destination（目標）——————-消息發佈和接收的地點，或者是隊列，或者是主題。
MessageProducer（消息生產者）—–由會話創建的對象，用於發送消息到目標。
MessageConsumer（消息消費者）—-由會話創建的對象，用於接收發送到目標的消息。
Message（消息）———————-是在消費者和生產者之間傳送的對象。
Session（會話）————————表示一個單線程的上下文，用於發送和接收消息。
2.1JMS消息模型
1、點對點或隊列模型
JMS 點對點隊列模型特點：
1、消息生產者生產消息發送到queue中，然後消息消費者從queue中取出並且消費消息。
2、消息被消費以後，queue中不再有存儲，所以消息消費者不可能消費到已經被消費的消息。
3、Queue支持存在多個消費者，但是對一個消息而言，只會有一個消費者可以消費。
2、發佈者/訂閱者模型
JMS 發佈/訂閱模型特點：
消息生產者（發佈）將消息發佈到topic中，同時有多個消息消費者（訂閱）消費該消息。
發佈到topic的消息會被所有訂閱者消費。
3.MQ對比與選擇
實現了JMS規範的消息中間件產品
ActiveMQ、RocketMQ、RabbitMQ、HornetQ……
| ActiveMQ | RabbitMQ | RocketMq | Joram | HornetQ | OpenMQ | MuleMQ | SonicMQ | ZeroMQ |
關注度 | 高 | 高 | 中 | 中 | 中 | 中 | 低 | 低 | 中 |
成熟度 | 成熟 | 成熟 | 比較成熟 | 比較成熟 | 比較成熟 | 比較成熟 | 新產品無成功案例 | 成熟 | 不成熟 |
所屬社區/公司 | Apache | Mozilla Public License | Alibaba | OW2 | Jboss | Sun | Mule | Progress |
|
社區活躍度 | 高 | 高 | 中 | 中 | 中 | 低 | 高 | 低 | 低 |
文檔 | 多 | 多 | 中 | 多 | 中 | 中 | 少 | 少 | 中 |
特點 | 功能齊全，被大量開源項目使用 | 由於Erlang 語言的併發能力，性能很好 | 各個環節分佈式擴展設計，主從 HA；支持上萬個隊列；多種消費模式；性能很好 |
| 在 Linux 平臺上直接調用操作系統的 AIO，性能得到很大的提升 |
| 性能非常 好，與 MuleESB 無縫整合 | 性能優越的商業 MQ | 低延時，高性能，最高 43萬條消息每秒 |
授權方式 | 開源 | 開源 | 開源 | 開源 | 開源 | 開源 | 商業 | 商業 | 開源 |
開發語言 | Java | Erlang | Java | Java | Java | Java | Java | Java | C |
支持的協議 | OpenWire、 STOMP、 REST、XMPP、 AMQP | AMQP | 自己定義的一 套(社區提供 JMS–不成熟) | JMS | JMS | JMS | JMS | JMS | TCP、UDP |
客戶端支持語言 | Java、C、 C++、 Python、 PHP、 Perl、.net等 | Java、C、 C++、 Python、 PHP、Perl 等 | Java C++（不成熟）
| Java | Java | Java | Java | Java、C、 C++、.net | python、 java、 php、.net 等 |
持久化 | 內存、文件、數據庫 | 內存、文件 | 磁盤文件 | 內存、文件 | 內存、文件 | 內存、文件 | 內存、文件 | 內存、文件、數據庫 | 在消息發送端保存 |
事務 | 支持 | 不支持 | 支持 | 支持 | 支持 | 支持 | 支持 | 支持 | 不支持 |
集羣 | 支持 | 支持 | 支持 | 支持 | 支持 | 支持 | 支持 | 支持 | 不支持 |
負載均衡 | 支持 | 支持 | 支持 | 支持 | 支持 | 支持 | 支持 | 支持 | 不支持 |
管理界面 | 一般 | 好 | 無社區有 web console 實現 | 一般 | 無 | 一般 | 一般 | 好 | 無 |
部署方式 | 獨立、嵌入 | 獨立 | 獨立 | 獨立、嵌入 | 獨立、嵌入 | 獨立、嵌入 | 獨立 | 獨立 | 獨立 |
評價 | 優點： 成熟的產品，已經在很多公司得到應用（非大規模場景）。有較多的文檔。各種協議支持較好，有多重語言的成熟的客戶端；缺點： 根據其他用戶反饋，會出莫名其妙的問題，切會丟 失消息。 其重心放到 activemq6.0 產品—apollo上去了，目前社區不活躍，且對 5.x 維護較少； Activemq 不適合用於上千個隊列的應用場景 | 優點： 由於 erlang語言的特性，mq性能較好；管理界面較豐富，在互聯網公司也有較大規模的應用；支持amqp系誒，有多中語言且支持 amqp 的客 戶端可用
缺點： erlang語言難度較 大。集羣不支持動態擴展。 | 優點： 模型簡單，接口易用（JMS的接口很多場合並不太實 用）。在阿里大規模應用。目前支付寶中的餘額寶等新興產 品均使用 rocketmq。集羣規模大概在 50 臺左右，單日處理消息上 百億；性能非常好，可以大量堆 積消息在 broker 中；支持多種消費，包括集羣消費、廣播消費等。開發度較活躍，版本 更新很快。
缺點： 產品較新，文檔比較缺乏。 沒有在 mq 核心中去實現JMS 等接口，對已有系統而言不能兼容。阿里內部還有一套未開源 的 MQ API，這一層API可以將上層應用和下層 MQ 的實現解耦（阿里內部有多個mq的實現，如 notify、 |
|
|
|
|
|
|
|
|
| metaq1.x， metaq2.x， rocketmq 等），使得下面mq可以很方便的進行切換和升級而對應用無任何影響，目前這一套東西未開源 |
|
|
|
|
|
|
</div>
