分布式異步通信模式

優點：系統間解耦，并具有一定的可恢復性，支持異構系統，下游通常可并發執行，系統具備彈 性。服務解耦、流量削峰填谷等。

缺點：消息中間件存在一些瓶頸和一致性問題，對于開發來講不直觀且不易調試，有額外成本。

消息中間件概念

消息中間件就是在通信的上下游之間截斷：break it，Broker 然后利用中間件解耦、異步的特性，構建彈性、可靠、穩定的系統。

異步處理、流量削峰、限流、緩沖、排隊、最終一致性、消息驅動等需求的場景都可以使用消息中 間件

消息中間件的選型

RabbitMQ

RabbitMQ開始是用在電信業務的可靠通信的，也是少有的幾款支持AMQP協議的產品之一。

優點：

• 1. 輕量級，快速，部署使用方便
• 2. 支持靈活的路由配置。RabbitMQ中，在生產者和隊列之間有一個交換器模塊。根據配置的路由規則，生產者發送的消息可以發送到不同的隊列中。路由規則很靈活，還可以自己實現。
• 3. RabbitMQ的客戶端支持大多數的編程語言。

缺點：

• 1. 如果有大量消息堆積在隊列中，性能會急劇下降
• 2. RabbitMQ的性能在Kafka和RocketMQ中是最差的，每秒處理幾萬到幾十萬的消息。如果應 用要求高的性能，不要選擇RabbitMQ，但是RabbitMQ相對的延遲確實最好的。
• 3. RabbitMQ是Erlang開發的，功能擴展和二次開發代價很高。

RocketMQ

RocketMQ是一個開源的消息隊列，使用java實現。借鑒了Kafka的設計并做了很多改進。 RocketMQ主要用于有序，事務，流計算，消息推送，日志流處理，binlog分發等場景。經過了歷次的 雙11考驗，性能，穩定性，可靠性很高。

優點：

• RocketMQ幾乎具備了消息隊列應該具備的所有特性和功能。
• java開發，閱讀源代碼、擴展、二次開發很方便。 對電商領域的響應延遲做了很多優化。在大多數情況下，響應在毫秒級。如果應用很關注響應時間，可以使用RocketMQ。
• 性能比RabbitMQ高一個數量級，每秒處理幾十萬的消息。

缺點：

• 跟周邊系統的整合和兼容不是很好。

Kafka?

Kafka的可靠性，穩定性和功能特性基本滿足大多數的應用場景。跟周邊系統的兼容性是數一數二的，尤其是大數據和流計算領域，幾乎所有相關的開源軟件都支持 Kafka。Kafka高效，可伸縮，消息持久化。支持分區、副本和容錯。

Kafka是Scala和Java開發的，對批處理和異步處理做了大量的設計，因此Kafka可以得到非常高的 性能。它的異步消息的發送和接收是三個中最好的，但是跟RocketMQ拉不開數量級，每秒處理幾十萬的消息。

如果是異步消息，并且開啟了壓縮，Kafka最終可以達到每秒處理2000w消息的級別。

缺點：

• 但是由于是異步的和批處理的，延遲也會高，不適合電商場景。

消息中間件的應用場景

一，電商秒殺案例：

系統應該如何應對高并發的讀請求：

• 使用緩存策略將請求擋在上層中的緩存中
• 能靜態化的數據盡量做到靜態化
• 加入限流（比如對短時間之內來自某一個用戶，某一個IP、某個設備的重復請求做丟棄處理）

系統應該如何應對高并發的寫請求：

場景： 生成訂單，扣減庫存，用戶這些操作不經過緩存直達數據庫。如果在 1s內，有 1 萬個數據連接同 時到達，系統的數據庫會瀕臨崩潰。可以使用 消息隊列解決問題。

消息隊列的作用：

• 削去秒殺場景下的峰值寫流量——流量削峰?

1，將秒殺請求暫存于消息隊列，業務服務器響應用戶“秒殺結果正在處理中。。。”，釋放系統資源去 處理其它用戶的請求。

2，削峰填谷，削平短暫的流量高峰，消息堆積會造成請求延遲處理，但秒殺用戶對于短暫延遲有一定 容忍度。

3，秒殺商品有 1000 件，處理一次購買請求的時間是 500ms，那么總共就需要 500s 的時間。這時你 部署 10 個隊列處理程序，那么秒殺請求的處理時間就是 50s，也就是說用戶需要等待 50s 才可以看到 秒殺的結果，這是可以接受的。這時會并發 10 個請求到達數據庫，并不會對數據庫造成很大的壓力。

• 通過異步處理簡化秒殺請求中的業務流程——異步處理

1，先處理主要的業務，異步處理次要的業務。如主要流程是生成訂單、扣減庫存；次要流程比如購買成功之后會給用戶發優惠券，增加用戶的積分，生成訂單扣減庫存在操作后將訂單信息通過MQ傳遞出去就可以返回了，積分，優惠券發放可以異步對MQ拉取或者MQ推送數據去處理。

• 解耦，實現秒殺系統模塊之間松耦合——解耦

?1，將數據全部發送給消息隊列，然后數據服務訂閱這個消息隊列，接收數據進行處理。不同的模塊去訂閱消費不同的消息隊列，做到解耦。

二，B-C端數據同步案例(招聘網站...)

B端面向企業用戶，C端面向求職者。B端需要獲取C端的更新以更新搜索引擎和緩存；C端需要獲取B端的更新以更新C端的搜索引擎與緩存.

同步方式：B端和C端通過RPC或WebService的方式發布服務，讓對方來調用，以獲取對方的信息。求職者每更新一次簡歷，就調用一次B端的服務，進行數據的同步；B端企業用戶每更新職位需求，就調用C端的服務，進行數據的同步。(Feign)

異步方式：使用消息隊列，B端將更新的數據發布到消息隊列，C端將更新的數據發布到消息隊列，B端訂閱C端的消息隊列，C端訂閱B端的消息隊列。

AMQP協議剖析

AMQP全稱高級消息隊列協議（Advanced Message Queuing Protocol），是一種標準，類似于 JMS，兼容JMS協議（針對JAVA的消息中間件協議）。目前RabbitMQ主流支持AMQP 0-9-1，3.8.4版本支持AMQP 1.0。

AMQP中的概念?：

• Publisher：消息發送者，將消息發送到Exchange并指定RoutingKey，以便queue可以接收到指 定的消息。
• Consumer：消息消費者，從queue獲取消息，一個Consumer可以訂閱多個queue以從多個 queue中接收消息。
• Server：一個具體的MQ服務實例，也稱為Broker。
• Virtual host：虛擬主機，一個Server下可以有多個虛擬主機，用于隔離不同項目，一個Virtual host通常包含多個Exchange、Message Queue。
• Exchange：交換器，接收Producer發送來的消息，把消息轉發到對應的Message Queue中。
• Routing key：路由鍵，用于指定消息路由規則（Exchange將消息路由到具體的queue中），通常需要和具體的Exchange類型、Binding的Routing key結合起來使用。
• Bindings：指定了Exchange和Queue之間的綁定關系。Exchange根據消息的Routing key和 Binding配置（綁定關系、Binding、Routing key等）來決定把消息分派到哪些具體的queue中。這依賴于Exchange類型。
• Message Queue：實際存儲消息的容器，并把消息傳遞給最終的Consumer。

?AMQP 傳輸層架構：

AMQP是一個二進制的協議，信息被組織成數據幀，有很多類型。數據幀攜帶協議方法和其他信 息。所有數據幀都擁有基本相同的格式：幀頭，負載，幀尾。數據幀負載的格式依賴于數據幀的類型。

AMQP 使用的數據類型:

• Integers（數值范圍1-8的十進制數字）：用于表示大小，數量，限制等，整數類型無符號 的，可以在幀內不對齊。
• Bits（統一為8個字節）：用于表示開/關值。
• Short strings：用于保存簡短的文本屬性，字符串個數限制為255，8個字節
• Long strings：用于保存二進制數據塊。
• Field tables：包含鍵值對，字段值一般為字符串，整數等。

協議協商

AMQP客戶端和服務端進行協議協商。意味著當客戶端連接上之后，服務端會向客戶端提出一些選 項，客戶端必須能接收或修改。如果雙方都認同協商的結果，繼續進行連接的建立過程。協議協商是一 個很有用的技術手段，因為它可以讓我們斷言假設和前置條件。

在AMQP中，我們需要協商協議的一些特殊方面：

• 1、 真實的協議和版本。服務器可能在同一個端口支持多個協議。
• 2、 雙方的加密參數和認證方式。這是功能層的一部分。
• 3、 數據幀最大大小，通道數量以及其他操作限制。

數據幀界定

TCP/IP是流協議，沒有內置的機制用于界定數據幀。

現有的協議從以下幾個方面來解決：

• 1. 每個連接發送單一數據幀。簡單但是慢。
• 2. 在流中添加幀的邊界。簡單，但是解析很慢。
• 3. 計算數據幀的大小，在每個數據幀頭部加上該數據幀大小。這簡單，快速，AMQP的選擇。

總結

以上是生活随笔為你收集整理的消息中间件概念与常用中间件选型的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。