今天閑聊下消息中間件的一些關(guān)鍵特性，對于消息中間件基礎(chǔ)知識，包括各種開源消息中間件的比較選型文章，網(wǎng)上已經(jīng)有很多，在這里就不再重復(fù)進(jìn)行描述。

因此這篇文章僅僅選擇一些消息中間件的一些關(guān)鍵特性和實(shí)踐中常遇到的問題進(jìn)行總結(jié)。

同時兼顧消息發(fā)布訂閱和隊列

點(diǎn)對點(diǎn)隊列模式消息模式

發(fā)布訂閱模型Topic消息模型

消息中間件有一個關(guān)鍵能力，即1對多的消息發(fā)布訂閱模式。因此對于消息中間件也常說兩個能力，一個是Queue消息隊列能力，一個是Topiic消息主題能力。對于消息Topic即消息主題模式，支持消息的發(fā)布訂閱。

對于Queue模式消息被消費(fèi)掉即從隊列中清除，不管是哪個消息端消費(fèi)掉。對于Topic模式，單個訂閱端獲取到消息，消息并不會清除，而是需要所有訂閱端全部消費(fèi)掉消息。

那么我們來舉一個最簡單的場景，即ERP系統(tǒng)需要將消息分發(fā)給CRM和SRM兩個系統(tǒng)。因此啟用了消息發(fā)布模式，建立了一個消息主題，比如會計科目分發(fā)消息。同時SRM和CRM系統(tǒng)是消息的訂閱方，因此在訂閱端寫了相應(yīng)的監(jiān)聽程序來訂閱消息。如下：

但是CRM和SRM都是集群部署，每個應(yīng)用都有三個集群節(jié)點(diǎn)，每個節(jié)點(diǎn)在啟動的時候都會對消息主題進(jìn)行訂閱和監(jiān)控。

那么當(dāng)ERP分發(fā)會計科目的時候，如果常規(guī)模式就變成了該消息會被6個訂閱端全部獲取到。這個時候?qū)τ贑RM系統(tǒng)中集群三個點(diǎn)，獲取到三次消息顯然是重復(fù)的。因此我們需要對于訂閱端，在一個集群分組內(nèi)部應(yīng)該只要有一個節(jié)點(diǎn)獲取到消息，消息就應(yīng)該清除掉。但是在不同的集群分組間，仍然應(yīng)該是Topic模式。

因此在消息中間件實(shí)現(xiàn)中，需要有一個針對集群節(jié)點(diǎn)的進(jìn)一步分組能力，比如上面的CRM和SRM應(yīng)該分為兩個組，也就是常說的ClientID。有了ClientID分組，就可以實(shí)現(xiàn)組間的Topic能力，而組內(nèi)啟用Queue模式。

不同的消息中間件在這塊的實(shí)現(xiàn)思路基本一致，即都需要有一個ClientID分組的概念。

比如在ActiveMQ中實(shí)現(xiàn)了虛擬Topic的功能。使用起來非常簡單。對于消息發(fā)布者來說，就是一個正常的Topic，名稱以VirtualTopic.開頭。例如VirtualTopic.TEST。

對于消息接收端來說，是個隊列，不同應(yīng)用里使用不同的前綴作為隊列的名稱，即可表明自己的身份即可實(shí)現(xiàn)消費(fèi)端應(yīng)用分組。例如Consumer.A.VirtualTopic.TEST，說明它是名稱為A的消費(fèi)端，同理Consumer.B.VirtualTopic.TEST說明是一個名稱為B的客戶端。

可以在同一個應(yīng)用里使用多個consumer消費(fèi)此queue，則可以實(shí)現(xiàn)上面兩個功能。又因?yàn)椴煌瑧?yīng)用使用的queue名稱不同（前綴不同），所以不同的應(yīng)用中都可以接收到全部的消息。每個客戶端相當(dāng)于一個持久訂閱者，而且這個客戶端可以使用多個消費(fèi)者共同來承擔(dān)消費(fèi)任務(wù)。

同時兼顧消息發(fā)布訂閱和路由

進(jìn)一步來談消息發(fā)布訂閱，還是基于前面的場景，ERP分發(fā)會計科目消息，當(dāng)前有SRM和CRM兩個訂閱端。但是仍然會出現(xiàn)一些特殊的場景：

比如CRM接收到消息，但是自己處理出現(xiàn)問題導(dǎo)致消息丟失，需要讓ERP系統(tǒng)重發(fā)消息。其次就是某些會計科目可能只有SRM系統(tǒng)需要使用，需要定向只發(fā)送給SRM系統(tǒng)。那么在這種情況下一個Topic主題往往并不能支持該需求。當(dāng)然對于不同的Route規(guī)則可以建立不同的Topic，但是如果路由規(guī)則復(fù)雜，這樣會建立出大量的Topic本身也不現(xiàn)實(shí)。

而對于這種常見，類似主流的基于JMS的消息中間件往往并沒有topic+路由規(guī)則的消息投遞能力，對于這種情況只能夠單獨(dú)新實(shí)現(xiàn)接口來進(jìn)行處理。或者是消息仍然按傳統(tǒng)規(guī)則進(jìn)行分發(fā)，對于訂閱端拿到消息如果確實(shí)自己不需要或已經(jīng)存在，就自己丟棄掉。

而對于RabbitMQ，可以看到專門有一個Topic Exchange模式。Topic Exchange是根據(jù)routing key和Exchange的類型將message發(fā)送到一個或者多個Queue中，可以通過它來實(shí)現(xiàn)pub/sub模式，即發(fā)布訂閱。類似下圖：

可靠性和消息持久化

在整個技術(shù)架構(gòu)中引入了消息中間件后，雖然達(dá)到了異步解耦的作用，但實(shí)質(zhì)是增加了整個集成架構(gòu)的復(fù)雜度，同時也影響了整體架構(gòu)的可靠性。

對于消息中間件如何增加可靠性，一個方面是高可用集群架構(gòu)，一個則是消息本身要支持持久化存儲。通過消息持久化存儲來確保消息不丟失。

對于消息持久化，一般來說分為文件和數(shù)據(jù)庫兩大類。對于文件本身又分為了本地磁盤文件和共享文件系統(tǒng)兩個方式。

本地磁盤方式可以看到，如果當(dāng)前Broker節(jié)點(diǎn)宕機(jī)，雖然消息可以在本地暫存，但是在當(dāng)前節(jié)點(diǎn)沒有手工恢復(fù)前，消費(fèi)端無法及時獲取消息。對于這個問題的實(shí)際解決思路是啟用類似Master-Slave的部署架構(gòu)方式，即消息會快速的實(shí)時同步到Slave節(jié)點(diǎn)。這樣即使Master節(jié)點(diǎn)無法訪問，訂閱端也可以快速的從Slave節(jié)點(diǎn)獲取消息。

對于共享文件系統(tǒng)或數(shù)據(jù)庫方式，實(shí)際消息只持久化到一個集中的地方，因此不存在消息多點(diǎn)復(fù)制的操作，某個節(jié)點(diǎn)宕機(jī)，共享存儲的消息也可以快速的恢復(fù)到其它冗余節(jié)點(diǎn)。

分布式事務(wù)

在前面談到過基于消息中間件來實(shí)現(xiàn)消息最終一致性，具體如下：

場景：在采購系統(tǒng)中擬制采購訂單，在提交單據(jù)申請的時候既需要將單據(jù)成功保存到本地，同時又需要啟動遠(yuǎn)程流程平臺提供的流程啟動服務(wù)。在該場景中，第二個步驟屬于必須要最終完成的操作，同時業(yè)務(wù)上也允許最終一致（不要因?yàn)榱鞒唐脚_本身問題導(dǎo)致單據(jù)提交不成功，啟流程失敗如何重試是系統(tǒng)內(nèi)部的事情）

對于該場景，基于消息實(shí)現(xiàn)最終一致性邏輯如下：

可以看到，報賬單提交和流程啟動仍然需要控制到一個事務(wù)里面，這個本身也是一個分布式事務(wù)控制場景。特別是在消息中間件需要在獲取到消息進(jìn)行持久化的時候。

也就是說從報賬單提交，到消息發(fā)送給消息中間件，兩個活動需要控制在一個事務(wù)里面。而對于消息中間件本身又有兩種做法。

一種是只要獲取到消息，消息還在內(nèi)存里面就認(rèn)為成功并返回給發(fā)送端，即異步刷盤。還有一種就是拿到消息后必須持久化寫入成功后才返回，即同步刷盤。

因此要確保無任何消息丟失，必須是同步刷盤模式，確保消息持久化成功才能夠返回。

持久化還有什么作用？

當(dāng)訂閱端取消息的進(jìn)度緩慢，或者說訂閱端遲遲不取走消息，那么消息就一直在消息中間件中堆積，消息中間件內(nèi)存容量優(yōu)先，必須將更多的歷史消息先進(jìn)行持久化處理進(jìn)行內(nèi)存釋放。否則消息中間件本身也很難應(yīng)對。

那么消息大量積壓如何辦？常用的方式就是設(shè)置消息的過期機(jī)制，比如設(shè)置為5天，那么超過5天訂閱端還沒有取走的消息就自動廢棄。但是這種方式本身也影響到消息發(fā)送的完整性。

當(dāng)然對于擠壓消息也可以手工清理。

比如當(dāng)前已經(jīng)產(chǎn)生1億條消息，分別由ERP分發(fā)給SRM和CRM系統(tǒng)，但是CRM系統(tǒng)對這些消息沒有消費(fèi)而處于積壓狀態(tài)。我們需要手工對CRM訂閱的這部分消息進(jìn)行清理。這個時候可以看到和基于數(shù)據(jù)庫進(jìn)行大表的Delete條件刪除差不多。

即性能極其緩慢。因?yàn)榍謇硐⑦^程實(shí)際就是條件刪除過程，同時這些數(shù)據(jù)還可能存在于多個磁盤文件中，清除后還需要對磁盤文件進(jìn)行重整。對于消息的持久化存儲前面談到，寫消息到磁盤文件性能極高，比數(shù)據(jù)庫快很多，但是一遇到這種條件刪除或消息清理場景，那么性能就會極差。

JMS還是AMQP

JMS（JAVA Messaging Service）是Java平臺上有關(guān)面向消息中間件(MOM)的技術(shù)規(guī)范，它便于消息系統(tǒng)中的Java應(yīng)用程序進(jìn)行消息交換,并且通過提供標(biāo)準(zhǔn)的產(chǎn)生、發(fā)送、接收消息的接口簡化企業(yè)應(yīng)用的開發(fā)，翻譯為Java消息服務(wù)。

傳統(tǒng)企業(yè)內(nèi)部使用的消息集成中間件，比如IBM MQ，Weblogic JMS, 開源的ActiveMQ等基本都基于JMS標(biāo)準(zhǔn)規(guī)范和協(xié)議。支持點(diǎn)對點(diǎn)隊列模式，也支持消息發(fā)布訂閱。

AMQP，即Advanced Message Queuing Protocol，一個提供統(tǒng)一消息服務(wù)的應(yīng)用層標(biāo)準(zhǔn)高級消息隊列協(xié)議，是應(yīng)用層協(xié)議的一個開放標(biāo)準(zhǔn)，為面向消息的中間件設(shè)計。基于此協(xié)議的客戶端與消息中間件可傳遞消息，并不受客戶端/中間件不同產(chǎn)品，不同的開發(fā)語言等條件的限制。

比如RabbitMQ即是通過AMQP協(xié)議實(shí)現(xiàn)。

在這里并不能說基于AMQP實(shí)現(xiàn)的消息中間件性能就一定好于JMS，對于阿里基于JMS實(shí)現(xiàn)的RocketMQ網(wǎng)上能夠查到的性能測試數(shù)據(jù)實(shí)際是好于RabbitMQ的。

具體的測試數(shù)據(jù)可以參考網(wǎng)上的一個對比圖:

高可用性集群搭建

對于集群可以分為兩類，一類是應(yīng)用中間件集群，一類是涉及到持久化中間件集群。

應(yīng)用中間件集群

對于應(yīng)用中間件集群，比如常見的weblogic，Tomcat應(yīng)用中間件和Web容器。這類要實(shí)現(xiàn)高可用性本身相對容易，因?yàn)楸旧聿簧婕暗綌?shù)據(jù)的持久化存儲方面的問題。

應(yīng)用集群高可用，唯一就是服務(wù)器節(jié)點(diǎn)之間的Session狀態(tài)信息同步，當(dāng)前也有很多的方案，類似Session同步復(fù)制，采用數(shù)據(jù)庫，redis等共享庫來保持Sesion會話信息等。再簡單點(diǎn)，你完全可以在上層接入到負(fù)載均衡設(shè)備，通過負(fù)載均衡設(shè)備配置Session會話保持來保持會話信息。在這種情況下僅是需要容忍集群節(jié)點(diǎn)出現(xiàn)故障，當(dāng)前在該節(jié)點(diǎn)的會話不可用。

其次就是集群節(jié)點(diǎn)的心跳檢測，一種是最簡單的方法就是心跳ping節(jié)點(diǎn)，如果出現(xiàn)異常則認(rèn)為節(jié)點(diǎn)出現(xiàn)故障。而這種情況下無法判斷集群節(jié)點(diǎn)是否假死或Hang住了。因此也有進(jìn)一步的做法，即采用OpenRestry來實(shí)現(xiàn)集群負(fù)載和動態(tài)的心跳監(jiān)控。

持久化中間件集群

對于消息中間件，Redis緩存數(shù)據(jù)庫等都可以看到，典型特點(diǎn)就是涉及到數(shù)據(jù)持久化的問題。而這些中間件本身的高可用集群思路基本完全一樣。

集群節(jié)點(diǎn)配置問題

集群節(jié)點(diǎn)配置，可以看到有1主1從，多主，多（主+從）等多種模式來實(shí)現(xiàn)集群擴(kuò)展。要看到主從的目的是實(shí)現(xiàn)Master宕機(jī)的時候消息還能夠從Slave上獲取，不影響消息實(shí)時性，Slave節(jié)點(diǎn)實(shí)際是實(shí)時在復(fù)制主節(jié)點(diǎn)數(shù)據(jù)，并不提供性能分擔(dān)。

而多主的目的則是真正分散消息并發(fā)泄到集群時候的性能問題。即使是一個最簡單的點(diǎn)對點(diǎn)消息模型，Producer也可以將消息分發(fā)到兩個Master節(jié)點(diǎn)進(jìn)行性能分擔(dān)，以減輕單Master節(jié)點(diǎn)下的性能壓力。

所以如果僅僅是高可靠，Master+Slave基本就能夠滿足。但是要滿足高可靠+高性能，則必須搭建多個Master+多個Slave組成的集群。

管理或心跳監(jiān)控節(jié)點(diǎn)

管理節(jié)點(diǎn)有很多方法，比如RocketMQ里面自己實(shí)現(xiàn)的Name Server集群，Redis集群實(shí)現(xiàn)的Sentinel哨兵集群，或者通用的Zookeeper集群來實(shí)現(xiàn)分布式協(xié)調(diào)等。

但是不論哪種方式都能看到管理節(jié)點(diǎn)往往是3臺服務(wù)器配置模式。

首先Admin節(jié)點(diǎn)采用單點(diǎn)肯定不行，即存在單點(diǎn)故障。

因此你至少需要配置兩臺Server來作為Admin管理節(jié)點(diǎn)，但是配置2臺服務(wù)器的時候又發(fā)現(xiàn)一個新問題，即如果2臺服務(wù)器檢測到的節(jié)點(diǎn)狀態(tài)不一致那么聽誰的？

正是這樣原因引入了第3臺服務(wù)器，即能夠超過半數(shù)的投票機(jī)制來實(shí)現(xiàn)文檔的集群管理節(jié)點(diǎn)。可以看到類似Kurbernetes集群同樣也是需要3臺服務(wù)器來實(shí)現(xiàn)多主的高可用配置。

持久化存儲

前面已經(jīng)談到了持久化存儲。對于消息中間件在集群下，實(shí)際每個集群節(jié)點(diǎn)都可能接收到大量的消息，消息是存儲在本地磁盤還是共享文件存儲是需要考慮的問題。

如果是本地磁盤，那么一般需考慮Master-Slave模式，實(shí)現(xiàn)消息的實(shí)時同步復(fù)制，以確保在Master宕機(jī)的情況下不影響到消息的實(shí)時獲取。如果是共享存儲模式，實(shí)際可以看到不一定必須配置Slave節(jié)點(diǎn)，即某個Master宕機(jī)后，另外一個節(jié)點(diǎn)可以從共享存儲中重新裝載消息，雖然稍微有一定延遲，但是基本不會影響到消息的實(shí)時性。

類似Weblogic JMS集群基本采用這種方式，即共享文件進(jìn)行持久化存儲，當(dāng)節(jié)點(diǎn)出現(xiàn)故障的時候，請求信息會漂移到其它非故障節(jié)點(diǎn)完成高可用性。