訊息佇列之概論

訊息佇列之概論

什麼是訊息佇列？訊息佇列能做什麼？訊息佇列為什麼會出現？再說訊息佇列之前我們要先知道什麼是訊息佇列、能夠做什麼、為什麼會出現訊息佇列？

1、什麼是訊息佇列

訊息佇列是在分散式系統中最常用的且最重要的元件之一，這個分散式系統不是指你的一個服務部署到不同的機器中，如果你是一個相同的服務部署到不同的機器這種不能稱之為分散式系統，準確來說應該說是叢集服務，而分散式系統通常是指有很多個不同的服務分別部署到不同的伺服器中，
如圖：

，如何在不同的服務中進行快速的資料互動或者呼叫，通常有兩種方式分別是RPC呼叫和訊息佇列，常見的RPC呼叫分別有Http、GRPC等。而訊息佇列的方式是指由三個重要部分分別是《訊息生產者、訊息服務中心、訊息消費者》組成。

• 生產者： 訊息的生產者只負責將訊息傳送給訊息服務中心，它只在意訊息是否成功的儲存在了訊息佇列服務中。
• 訊息服務中心： 訊息服務中心其實可以當做一箇中間商來看，其實它的作用就是將資料持久化到自己服務內，不在意是誰傳送的訊息。
• 訊息消費者： 訊息消費者是指從中間商獲取訊息的一個部分，它只在意我是否能拿到訊息至於是誰釋出的它不在意。

2、訊息佇列能做什麼

訊息佇列可以做：應用解耦、流量削峰、日誌收集、訊息通訊、事務最終一致性等場景都可以使用訊息佇列。

2.1、流量削峰

什麼是流量削峰，在網際網路行業中，可能會在某一個時間段網站迎來使用者的請求高峰期的> 情況例如（12306、淘寶雙十一）等，在系統設計之初可能只是簡單寫入資料庫，但是如果一直延續這樣的設計遇到高峰期的請求就會給資料庫帶來巨大的壓力，併發量超出了系統的承載能力可能會引起系統雪崩。當訪問量劇增的> 時候系統一覽可以繼續使用最常見的是使用訊息佇列，將短時間的高併發請求持久化到訊息佇列服務中，從而實現削平高峰期的請求併發流量，改善系統效能。

2.2、系統解耦

在大型系統的開發過程中會經常碰到 類情況 隨著需求的疊加 各模組之間逐漸變成了相互呼叫的關係，這種模組間緊密關聯的關係就是緊相合 緊相合帶來的問題是對一個模組的功能變更將導致其關聯模組發生變化，因此各個模組難以獨立演要解決這個題，可以在模組之間呼叫時增加 箇中問層來實現解楠，這也方便了以後的 擴充套件。所謂解錮，簡單地講，就是一個模組只關心自己的核心流程，而依賴該棋塊執行結果的其他模組如果做的不是很重要的事情，有通知即可，無須等待結果 換句話說，基於訊息佇列的模型，關心的是通 ，而非處理。

2.3、事務最終一致性

如果系統很小，將兩個表儲存在相同的資料庫中，我們可以通過資料庫的強一致性事務進行管理，如果我們是大型系統需要操作不同的資料庫完成一個業務那麼就無法使用資料庫事務來完成了，？業界曾經提出過 個處理分散式事務的規範 XAo XA 主要定義了全事務管理器（ Transaction Manager ）和區域性資源管理器（ Resource Manager ）之間的接。 XA介面是雙向的系統介面，在事務管理器及 個或多個資源管理器之間形成通訊橋樑。兀氣引入事務管理器充當全域性事務中的協調者的角色。事務管理器控制著全域性事務，管理事務生命週期，並協調資源。資源管理器負責控制和管理實際資源（如資料庫或 JMS 佇列）。目前各主流資料庫都提供了對凡氣規範的支援。它的缺陷是效能很差，不適合高併發和高效能要求的場景。我們可以通過訊息佇列來處理事務問題，其實在分散式事務中最主要的是CAP定理，和Base理論，在此不詳細介紹CAP定理和Base理論，具體的可以自行百度。

2.4、日誌收集

訊息佇列也可以用來做日誌收集，在專案執行中日誌也是一個很重要的組成部分，可以通過日誌跟蹤除錯資訊、定位問題、使用者操作行為等等。具體的日誌分析就需要大資料來進行分析了，日誌收集的訊息佇列用的最多的就是kafka。

3、訊息服務中心的功能與特點

訊息佇列它包含了兩個關鍵詞《訊息和佇列》，訊息是指在不通服務之間傳遞的具體資料，訊息可以是各式各樣的；對於佇列的含義我個人理解的其實就是資料結構中佇列的概念，是指先進先出，訊息的入隊和出隊並不一定是同步進行的，所以需要一個容器來暫存和處理訊息，而訊息服務中心就是這個容器。在上面有提到過三個重要的組成部分，分別是：訊息生產者->Producer、訊息服務中心->Broker、訊息消費者->Consumer，除了這些一個好的訊息佇列還應該具備以下功能：訊息堆積、訊息持久化、可靠投遞、訊息重複、高可用叢集部署等各種問題。

3.1、訊息堆積

因為訊息佇列的生產者、消費者是兩個分開處理訊息的系統，也無法預製兩者對訊息的處理速度快慢，一旦在某個時間段內消費者的處理速度沒有跟上生產者傳送訊息的速度會導致訊息處理中心積壓無法及時得到釋放。因此一個好的訊息佇列產品需要具備處理這種情況，比如通過設定一個閥值，超過閥值的訊息不在放入處理中心等，避免訊息中心繫統資源耗盡，導致訊息中心服務當機。

3.2、訊息持久化

在設計一個訊息佇列時，如果生產者的訊息到達訊息服務中心不做任何處理就直接轉給消費者那麼訊息服務中心的存在也就失去了意義，無法滿足流量削峰等需求，所以訊息服務中心的常規做法都是將訊息暫存到訊息服務中心本地，然後擇機將訊息投遞給消費者，訊息的暫存可以在記憶體中，也可以選擇儲存到磁碟、資料庫、檔案等地方。將訊息存放到記憶體中最大的問題就是一旦當機訊息會丟失。如果你的業務場景要求訊息不能丟失，那麼勢必需要將訊息持久化，前面也有提到過持久化方案分為很多種。

3.3、可靠投遞

可靠投遞是指不允許存在訊息途中丟失的情況。從訊息的整個生命週期來分析的話，訊息丟失的情況一般出現在以下過程中：

• 從生產者到訊息服務中心
• 從訊息服務中心到訊息消費者
• 訊息中心一旦當機是否持久化了訊息

由於跨越不同系統，中間呼叫會朋友許多問題，例如網路問題、系統當機等不確定的情形，但是對訊息傳送者來說都是一件事，訊息沒有送達，在有些場景下需要保證訊息不能丟失，例如網購時訂單支付成功訊息不能丟失，否則這筆訂單會卡在未支付環節。

3.4、叢集

在大型系統應用中，系統架構一般都需要實現高可用性，用來排除單點故障引起的系統中斷，保證7*24小時不間斷執行，所以訊息服務中心需要對叢集模式提供支援，叢集不僅可以讓消費者和生產者在某個節點當機的情況下繼續執行，叢集之間的多個節點還能夠共享負載，當某臺機器或者網路出現故障時自動進行負載均衡，從而保證多節點來提高訊息通訊的吞吐量。

4、主流訊息服務中介軟體對比

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
單機吞吐量	萬級，與RocketMQ、kafka相比吞吐量略低	1W量級，與RocketMQ、kafka相比吞吐量略低	10 萬級，支撐高吞吐	10 萬級，高吞吐，一般配合大資料類的系統來進行實時資料計算、日誌採集等場景
Topic數量對吞吐量的影響	未知	未知	topic 可以達到幾百/幾千的級別，吞吐量會有較小幅度的下降，這是 RocketMQ 的一大優勢，在同等機器下，可以支撐大量的 topic	topic 從幾十到幾百個時候，吞吐量會大幅度下降，在同等機器下，Kafka 儘量保證 topic 數量不要過多，如果要支撐大規模的 topic，需要增加更多的機器資源
時效性	ms 級	微秒級，這是 RabbitMQ 的一大特點，延遲最低	毫秒級	毫秒
可用性	可以基於主從架構實現高可用	可以基於主從架構實現高可用	很高(主從模式)	非常高，分散式，一個資料多個副本，少數機器當機，不會丟失資料，不會導致不可用
訊息丟失	有較低的概率丟失資料	基本不丟	引數優化配置，可以做到 0 丟失	引數優化配置，可以做到 0 丟失
消費模式		推拉	推拉	拉取
優點	MQ領域的功能極其完備	由於erlang語言的特性，mq 效能較好，高併發；健壯、穩定、易用、跨平臺、支援多種語言、文件齊全；社群活躍度高；路由機制完備	MQ功能較為完善，還是分散式的，擴充套件性好,支援10億級別的訊息堆積，不會因為堆積導致效能下降	效能卓越，單機寫入TPS約在百萬條/秒，最大的優點，就是吞吐量高。
缺點	官方社群現在對ActiveMQ 5.x維護越來越少，較少在大規模吞吐的場景中使用。	erlang開發，很難去看懂原始碼，基本職能依賴於開源社群的快速維護和修復bug，不利於做二次開發和維護。RabbitMQ吞吐量會低一些，這是因為他做的實現機制比較重。需要學習比較複雜的介面和協議，學習和維護成本較高。	支援的客戶端語言不多，目前是java及c++，其中c++不成熟； 社群活躍度一般, 沒有在 mq 核心中去實現JMS等介面，有些系統要遷移需要修改大量程式碼	Kafka單機超過64個佇列/分割槽，Load會發生明顯的飆高現象，佇列越多，load越高，傳送訊息響應時間變長

總結

訊息中介軟體是非底層作業系統軟體、非業務應用軟體，更不是直接面對終端使用者使用的，不能直接給使用者帶來價值的軟體統稱為中介軟體。訊息中介軟體關注的是資料的傳送和結構，利用高效、可靠的非同步訊息投遞機制整合成分散式系統。