分散式之訊息佇列複習精講

引言

為什麼寫這篇文章?

博主有兩位朋友分別是小A和小B:

1. 小A，工作於傳統軟體行業(某社保局的軟體外包公司)，每天工作內容就是和產品聊聊需求，改改業務邏輯。再不然就是和運營聊聊天，寫幾個SQL，生成下報表。又或者接到客服的通知，某某功能故障了，改改資料，然後下班部署上線。每天過的都是這種生活，技術零成長。
2. 小B，工作於某國企，雖然能接觸到一些中介軟體技術。然而，他只會訂閱/釋出訊息。通俗點說，就是調調API。對為什麼使用這些中介軟體啊？如何保證高可用啊？沒有充分的認識。

慶幸的是兩位朋友都很有上進心，於是博主寫這篇文章，幫助他們複習一下關於訊息佇列中介軟體這塊的要點

複習要點

本文大概圍繞如下幾點進行闡述:

1. 為什麼使用訊息佇列？
2. 使用訊息佇列有什麼缺點?
3. 訊息佇列如何選型?
4. 如何保證訊息佇列是高可用的？
5. 如何保證訊息不被重複消費?
6. 如何保證消費的可靠性傳輸?
7. 如何保證訊息的順序性？

我們圍繞以上七點進行闡述。需要說明一下，本文不是《訊息佇列從入門到精通》這種課程，因此只是提供一個複習思路，而不是去教你們怎麼呼叫訊息佇列的API。建議對訊息佇列不瞭解的人，去找點訊息佇列的部落格看看，再看本文，收穫更大

正文

1、為什麼要使用訊息佇列?

分析:一個用訊息佇列的人，不知道為啥用，這就有點尷尬。沒有複習這點，很容易被問蒙，然後就開始胡扯了。
回答:這個問題,我們只答三個最主要的應用場景(不可否認還有其他的，但是隻答三個主要的),即以下六個字:解耦、非同步、削峰

(1)解耦

傳統模式:

傳統模式的缺點：

• 系統間耦合性太強，如上圖所示，系統A在程式碼中直接呼叫系統B和系統C的程式碼，如果將來D系統接入，系統A還需要修改程式碼，過於麻煩！

中介軟體模式:

中介軟體模式的的優點：

• 將訊息寫入訊息佇列，需要訊息的系統自己從訊息佇列中訂閱，從而系統A不需要做任何修改。

(2)非同步

傳統模式:

傳統模式的缺點：

• 一些非必要的業務邏輯以同步的方式執行，太耗費時間。

中介軟體模式:

中介軟體模式的的優點：

• 將訊息寫入訊息佇列，非必要的業務邏輯以非同步的方式執行，加快響應速度

(3)削峰

傳統模式

傳統模式的缺點：

• 併發量大的時候，所有的請求直接懟到資料庫，造成資料庫連線異常

中介軟體模式:

中介軟體模式的的優點：

• 系統A慢慢的按照資料庫能處理的併發量，從訊息佇列中慢慢拉取訊息。在生產中，這個短暫的高峰期積壓是允許的。

2、使用了訊息佇列會有什麼缺點?

分析:一個使用了MQ的專案，如果連這個問題都沒有考慮過，就把MQ引進去了，那就給自己的專案帶來了風險。我們引入一個技術，要對這個技術的弊端有充分的認識，才能做好預防。要記住，不要給公司挖坑！
回答:回答也很容易，從以下兩個個角度來答

• 系統可用性降低:你想啊，本來其他系統只要執行好好的，那你的系統就是正常的。現在你非要加個訊息佇列進去，那訊息佇列掛了，你的系統不是呵呵了。因此，系統可用性降低
• 系統複雜性增加:要多考慮很多方面的問題，比如一致性問題、如何保證訊息不被重複消費，如何保證保證訊息可靠傳輸。因此，需要考慮的東西更多，系統複雜性增大。

但是，我們該用還是要用的。

3、訊息佇列如何選型?

先說一下，博主只會ActiveMQ,RabbitMQ,RocketMQ,Kafka，對什麼ZeroMQ等其他MQ沒啥理解，因此只能基於這四種MQ給出回答。
分析:既然在專案中用了MQ，肯定事先要對業界流行的MQ進行調研，如果連每種MQ的優缺點都沒了解清楚，就拍腦袋依據喜好，用了某種MQ，還是給專案挖坑。如果面試官問:”你為什麼用這種MQ？。”你直接回答”領導決定的。”這種回答就很LOW了。還是那句話，不要給公司挖坑。
回答:首先，我們先上ActiveMQ的社群，看看該MQ的更新頻率:

我們可以看出，ActiveMq幾個月才發一次版本，據說研究重心在他們的下一代產品Apollo。
接下來，我們再去RabbitMQ的社群去看一下,RabbitMQ的更新頻率

我們可以看出，RabbitMQ版本釋出比ActiveMq頻繁很多。至於RocketMQ和kafka就不帶大家看了，總之也比ActiveMQ活躍的多。詳情，可自行查閱。
再來一個效能對比表

特性	ActiveMQ	RabbitMQ	RocketMQ	kafka
開發語言	java	erlang	java	scala
單機吞吐量	萬級	萬級	10萬級	10萬級
時效性	ms級	us級	ms級	ms級以內
可用性	高(主從架構)	高(主從架構)	非常高(分散式架構)	非常高(分散式架構)
功能特性	成熟的產品，在很多公司得到應用；有較多的文件；各種協議支援較好	基於erlang開發，所以併發能力很強，效能極其好，延時很低;管理介面較豐富	MQ功能比較完備，擴充套件性佳	只支援主要的MQ功能，像一些訊息查詢，訊息回溯等功能沒有提供，畢竟是為大資料準備的，在大資料領域應用廣。

綜合上面的材料得出以下兩點:
(1)中小型軟體公司，建議選RabbitMQ.一方面，erlang語言天生具備高併發的特性，而且他的管理介面用起來十分方便。正所謂，成也蕭何，敗也蕭何！他的弊端也在這裡，雖然RabbitMQ是開源的，然而國內有幾個能定製化開發erlang的程式設計師呢？所幸，RabbitMQ的社群十分活躍，可以解決開發過程中遇到的bug，這點對於中小型公司來說十分重要。不考慮rocketmq和kafka的原因是，一方面中小型軟體公司不如網際網路公司，資料量沒那麼大，選訊息中介軟體，應首選功能比較完備的，所以kafka排除。不考慮rocketmq的原因是，rocketmq是阿里出品，如果阿里放棄維護rocketmq，中小型公司一般抽不出人來進行rocketmq的定製化開發，因此不推薦。
(2)大型軟體公司，根據具體使用在rocketMq和kafka之間二選一。一方面，大型軟體公司，具備足夠的資金搭建分散式環境，也具備足夠大的資料量。針對rocketMQ,大型軟體公司也可以抽出人手對rocketMQ進行定製化開發，畢竟國內有能力改JAVA原始碼的人，還是相當多的。至於kafka，根據業務場景選擇，如果有日誌採集功能，肯定是首選kafka了。具體該選哪個，看使用場景。

4、如何保證訊息佇列是高可用的？

分析:在第二點說過了，引入訊息佇列後，系統的可用性下降。在生產中，沒人使用單機模式的訊息佇列。因此，作為一個合格的程式設計師，應該對訊息佇列的高可用有很深刻的瞭解。如果面試的時候，面試官問，你們的訊息中介軟體如何保證高可用的？你的回答只是表明自己只會訂閱和釋出訊息，面試官就會懷疑你是不是隻是自己搭著玩，壓根沒在生產用過。請做一個愛思考，會思考，懂思考的程式設計師。
回答:這問題，其實要對訊息佇列的叢集模式要有深刻了解，才好回答。
以rcoketMQ為例，他的叢集就有多master 模式、多master多slave非同步複製模式、多 master多slave同步雙寫模式。多master多slave模式部署架構圖(網上找的,偷個懶，懶得畫):

其實博主第一眼看到這個圖，就覺得和kafka好像，只是NameServer叢集，在kafka中是用zookeeper代替，都是用來儲存和發現master和slave用的。通訊過程如下:
Producer 與 NameServer叢集中的其中一個節點（隨機選擇）建立長連線，定期從 NameServer 獲取 Topic 路由資訊，並向提供 Topic 服務的 Broker Master 建立長連線，且定時向 Broker 傳送心跳。Producer 只能將訊息傳送到 Broker master，但是 Consumer 則不一樣，它同時和提供 Topic 服務的 Master 和 Slave建立長連線，既可以從 Broker Master 訂閱訊息，也可以從 Broker Slave 訂閱訊息。
那麼kafka呢,為了對比說明直接上kafka的拓補架構圖(也是找的，懶得畫)

如上圖所示，一個典型的Kafka叢集中包含若干Producer（可以是web前端產生的Page View，或者是伺服器日誌，系統CPU、Memory等），若干broker（Kafka支援水平擴充套件，一般broker數量越多，叢集吞吐率越高），若干Consumer Group，以及一個Zookeeper叢集。Kafka通過Zookeeper管理叢集配置，選舉leader，以及在Consumer Group發生變化時進行rebalance。Producer使用push模式將訊息釋出到broker，Consumer使用pull模式從broker訂閱並消費訊息。
至於rabbitMQ,也有普通叢集和映象叢集模式，自行去了解，比較簡單，兩小時即懂。
要求，在回答高可用的問題時，應該能邏輯清晰的畫出自己的MQ叢集架構或清晰的敘述出來。

5、如何保證訊息不被重複消費？

分析:這個問題其實換一種問法就是，如何保證訊息佇列的冪等性?這個問題可以認為是訊息佇列領域的基本問題。換句話來說，是在考察你的設計能力，這個問題的回答可以根據具體的業務場景來答，沒有固定的答案。
回答:先來說一下為什麼會造成重複消費?
其實無論是那種訊息佇列，造成重複消費原因其實都是類似的。正常情況下，消費者在消費訊息時候，消費完畢後，會傳送一個確認資訊給訊息佇列，訊息佇列就知道該訊息被消費了，就會將該訊息從訊息佇列中刪除。只是不同的訊息佇列傳送的確認資訊形式不同,例如RabbitMQ是傳送一個ACK確認訊息，RocketMQ是返回一個CONSUME_SUCCESS成功標誌，kafka實際上有個offset的概念，簡單說一下(如果還不懂，出門找一個kafka入門到精通教程),就是每一個訊息都有一個offset，kafka消費過訊息後，需要提交offset，讓訊息佇列知道自己已經消費過了。那造成重複消費的原因?，就是因為網路傳輸等等故障，確認資訊沒有傳送到訊息佇列，導致訊息佇列不知道自己已經消費過該訊息了，再次將該訊息分發給其他的消費者。
如何解決?這個問題針對業務場景來答分以下幾點
(1)比如，你拿到這個訊息做資料庫的insert操作。那就容易了，給這個訊息做一個唯一主鍵，那麼就算出現重複消費的情況，就會導致主鍵衝突，避免資料庫出現髒資料。
(2)再比如，你拿到這個訊息做redis的set的操作，那就容易了，不用解決，因為你無論set幾次結果都是一樣的，set操作本來就算冪等操作。
(3)如果上面兩種情況還不行，上大招。準備一個第三方介質,來做消費記錄。以redis為例，給訊息分配一個全域性id，只要消費過該訊息，將<id,message>以K-V形式寫入redis。那消費者開始消費前，先去redis中查詢有沒消費記錄即可。

6、如何保證消費的可靠性傳輸?

分析:我們在使用訊息佇列的過程中，應該做到訊息不能多消費，也不能少消費。如果無法做到可靠性傳輸，可能給公司帶來千萬級別的財產損失。同樣的，如果可靠性傳輸在使用過程中，沒有考慮到，這不是給公司挖坑麼，你可以拍拍屁股走了，公司損失的錢，誰承擔。還是那句話，認真對待每一個專案，不要給公司挖坑。
回答:其實這個可靠性傳輸，每種MQ都要從三個角度來分析:生產者弄丟資料、訊息佇列弄丟資料、消費者弄丟資料

RabbitMQ

(1)生產者丟資料
從生產者弄丟資料這個角度來看，RabbitMQ提供transaction和confirm模式來確保生產者不丟訊息。
transaction機制就是說，傳送訊息前，開啟事物(channel.txSelect())，然後傳送訊息，如果傳送過程中出現什麼異常，事物就會回滾(channel.txRollback())，如果傳送成功則提交事物(channel.txCommit())。
然而缺點就是吞吐量下降了。因此，按照博主的經驗，生產上用confirm模式的居多。一旦channel進入confirm模式，所有在該通道上面釋出的訊息都將會被指派一個唯一的ID(從1開始)，一旦訊息被投遞到所有匹配的佇列之後，rabbitMQ就會傳送一個Ack給生產者(包含訊息的唯一ID)，這就使得生產者知道訊息已經正確到達目的佇列了.如果rabiitMQ沒能處理該訊息，則會傳送一個Nack訊息給你，你可以進行重試操作。處理Ack和Nack的程式碼如下所示（說好不上程式碼的，偷偷上了）:

(2)訊息佇列丟資料
處理訊息佇列丟資料的情況，一般是開啟持久化磁碟的配置。這個持久化配置可以和confirm機制配合使用，你可以在訊息持久化磁碟後，再給生產者傳送一個Ack訊號。這樣，如果訊息持久化磁碟之前，rabbitMQ陣亡了，那麼生產者收不到Ack訊號，生產者會自動重發。
那麼如何持久化呢，這裡順便說一下吧，其實也很容易，就下面兩步
1、將queue的持久化標識durable設定為true,則代表是一個持久的佇列
2、傳送訊息的時候將deliveryMode=2
這樣設定以後，rabbitMQ就算掛了，重啟後也能恢復資料
(3)消費者丟資料
消費者丟資料一般是因為採用了自動確認訊息模式。這種模式下，消費者會自動確認收到資訊。這時rahbitMQ會立即將訊息刪除，這種情況下如果消費者出現異常而沒能處理該訊息，就會丟失該訊息。
至於解決方案，採用手動確認訊息即可。

kafka

這裡先引一張kafka Replication的資料流向圖

Producer在釋出訊息到某個Partition時，先通過ZooKeeper找到該Partition的Leader，然後無論該Topic的Replication Factor為多少（也即該Partition有多少個Replica），Producer只將該訊息傳送到該Partition的Leader。Leader會將該訊息寫入其本地Log。每個Follower都從Leader中pull資料。
針對上述情況，得出如下分析
(1)生產者丟資料
在kafka生產中，基本都有一個leader和多個follwer。follwer會去同步leader的資訊。因此，為了避免生產者丟資料，做如下兩點配置

1. 第一個配置要在producer端設定acks=all。這個配置保證了，follwer同步完成後，才認為訊息傳送成功。
2. 在producer端設定retries=MAX，一旦寫入失敗，這無限重試

(2)訊息佇列丟資料
針對訊息佇列丟資料的情況，無外乎就是，資料還沒同步，leader就掛了，這時zookpeer會將其他的follwer切換為leader,那資料就丟失了。針對這種情況，應該做兩個配置。

1. replication.factor引數，這個值必須大於1，即要求每個partition必須有至少2個副本
2. min.insync.replicas引數，這個值必須大於1，這個是要求一個leader至少感知到有至少一個follower還跟自己保持聯絡

這兩個配置加上上面生產者的配置聯合起來用，基本可確保kafka不丟資料

(3)消費者丟資料
這種情況一般是自動提交了offset，然後你處理程式過程中掛了。kafka以為你處理好了。再強調一次offset是幹嘛的
offset：指的是kafka的topic中的每個消費組消費的下標。簡單的來說就是一條訊息對應一個offset下標，每次消費資料的時候如果提交offset，那麼下次消費就會從提交的offset加一那裡開始消費。
比如一個topic中有100條資料，我消費了50條並且提交了，那麼此時的kafka服務端記錄提交的offset就是49(offset從0開始)，那麼下次消費的時候offset就從50開始消費。
解決方案也很簡單，改成手動提交即可。

ActiveMQ和RocketMQ

大家自行查閱吧

7、如何保證訊息的順序性？

分析:其實並非所有的公司都有這種業務需求，但是還是對這個問題要有所複習。
回答:針對這個問題，通過某種演算法，將需要保持先後順序的訊息放到同一個訊息佇列中(kafka中就是partition,rabbitMq中就是queue)。然後只用一個消費者去消費該佇列。
有的人會問:那如果為了吞吐量，有多個消費者去消費怎麼辦？
這個問題，沒有固定回答的套路。比如我們有一個微博的操作，發微博、寫評論、刪除微博，這三個非同步操作。如果是這樣一個業務場景，那隻要重試就行。比如你一個消費者先執行了寫評論的操作，但是這時候，微博都還沒發，寫評論一定是失敗的，等一段時間。等另一個消費者，先執行寫評論的操作後，再執行，就可以成功。
總之，針對這個問題，我的觀點是保證入隊有序就行，出隊以後的順序交給消費者自己去保證，沒有固定套路。

總結

寫到這裡，希望讀者把本文提出的這幾個問題，經過深刻的準備後，一般來說，能囊括大部分的訊息佇列的知識點。如果面試官不問這幾個問題怎麼辦，簡單，自己把幾個問題講清楚，突出以下自己考慮的全面性。
最後，其實我不太提倡這樣突擊複習，希望大家打好基本功，做一個愛思考，懂思考，會思考的程式設計師。