為什么需要消息隊列
消息隊列是歷史最悠久的中間件之一，它可以和不同的進(jìn)程進(jìn)行通信，從而實現(xiàn)上下游之間的消息傳遞。基于此特性，我們可以在以下三個場景中使用消息隊列。
- 解耦；
- 限流；
- 流量削峰；
1）解耦
先來看解耦，假設(shè)有兩個服務(wù)：A 和 B，當(dāng)服務(wù) A 依賴服務(wù) B 時，請求的耗時就是這兩個服務(wù)之和。但如果服務(wù) B 耗時比較長怎么辦？
顯然這時服務(wù) A 可以將消息發(fā)送到隊列中，服務(wù) B 從隊列里面去取即可，從而實現(xiàn)兩個服務(wù)之間的邏輯解耦 + 物理解耦。
當(dāng)用戶注冊賬號時，會將注冊信息發(fā)給賬號服務(wù)，賬號服務(wù)將信息寫入數(shù)據(jù)庫后，會調(diào)用短信服務(wù)給用戶發(fā)送短信。如果不使用消息隊列，那么必須等短信發(fā)送成功之后才能返回。
但為了給用戶更好的體驗，我們可以將發(fā)送短信這一步獨(dú)立出去，賬號服務(wù)將用戶手機(jī)號和短信內(nèi)容投入消息隊列中就可以返回了，這樣用戶就能立刻收到注冊結(jié)果。而短信服務(wù)會消費(fèi)消息，異步執(zhí)行發(fā)送短信邏輯，這就是消息隊列的作用之一：解耦。
使用消息隊列進(jìn)行解耦，不僅可以提升性能，還可以使整個系統(tǒng)更加的模塊化。以電商為例，訂單服務(wù)是電商系統(tǒng)中的核心部分，它會被一系列下游服務(wù)依賴。并且隨著業(yè)務(wù)的發(fā)展，依賴訂單的下游服務(wù)會不斷增加、不斷變化。
因此負(fù)責(zé)訂單服務(wù)的開發(fā)團(tuán)隊不得不花費(fèi)大量精力，應(yīng)對不斷增加變化的下游服務(wù)，不停地修改調(diào)試訂單服務(wù)與這些下游服務(wù)的接口。任何一個下游服務(wù)的接口產(chǎn)生變更，都需要訂單模塊重新進(jìn)行一次上線，對于一個電商的核心服務(wù)來說，這幾乎是不可接受的。
因此所有的電商系統(tǒng)都選擇用消息隊列，來解決這種系統(tǒng)耦合過于緊密的問題。引入消息隊列后，訂單服務(wù)在訂單變化時發(fā)送一條消息到消息隊列的一個主題 order 中，所有下游服務(wù)都訂閱主題 order，這樣每個下游服務(wù)都可以獲得一份實時完整的訂單數(shù)據(jù)。并且此時下游服務(wù)發(fā)生變化，不會影響訂單服務(wù)。
2）限流
一個完善的系統(tǒng)一定具備自我保護(hù)的能力，即使面對海量請求，也能盡最大努力去處理，處理不了的則會拒絕掉，從而保證系統(tǒng)運(yùn)行正常。因此如果我們能預(yù)估出系統(tǒng)的最大處理能力，就可以用消息隊列實現(xiàn)一個令牌桶，進(jìn)行流量控制。
令牌桶控制流量的原理是：單位時間內(nèi)發(fā)放固定數(shù)量的令牌到令牌桶中，規(guī)定服務(wù)在處理請求之前必須先從桶中取走一個令牌，如果桶里面沒有令牌，則拒絕請求。這樣就保證單位時間內(nèi)，能處理的請求數(shù)不超過發(fā)放令牌的數(shù)量，起到了流量控制的作用。
令牌桶可以簡單地用一個有固定容量的消息隊列加一個令牌生成器來實現(xiàn)：令牌生成器按照預(yù)估的處理能力，勻速生產(chǎn)令牌并放入令牌隊列（如果隊列滿了則丟棄令牌）。網(wǎng)關(guān)（流量的入口）在收到請求時從令牌隊列消費(fèi)一個令牌，獲取到令牌則繼續(xù)調(diào)用后端服務(wù)，如果獲取不到令牌則直接返回失敗。
3）流量削峰
任何的大型服務(wù)，特別是秒殺服務(wù)，都離不開消息隊列。因為消息隊列除了解耦和限流之外，還可以起到流量削峰的作用，就是緩沖瞬時的突發(fā)流量，使其更平滑。
對于那些發(fā)送能力很強(qiáng)的上游系統(tǒng)，如果沒有消息隊列的保護(hù)，脆弱的下游系統(tǒng)可能會直接被壓垮導(dǎo)致全鏈路服務(wù)雪崩。而一旦有了消息隊列，它就能夠有效地對抗上游的流量沖擊，避免了流量的震蕩。
我們舉一個實際的例子，比如在京東購買商品，當(dāng)點擊購買的時候，會調(diào)用訂單服務(wù)生成對應(yīng)的訂單。然而要處理該訂單則會依次調(diào)用下游的多個子服務(wù)，比如查詢登錄信息、驗證商品信息、確認(rèn)地址信息，調(diào)用銀行等支付接口進(jìn)行扣款等等。
顯然上游的訂單操作比較簡單，它的 TPS 要遠(yuǎn)高于處理訂單的下游服務(wù)。因此如果上游和下游直接對接，勢必會出現(xiàn)下游服務(wù)無法及時處理上游訂單從而造成訂單堆積的情況。特別是當(dāng)出現(xiàn)雙十一以及秒殺業(yè)務(wù)的時候，上游訂單流量會瞬間增加，可能出現(xiàn)的結(jié)果就是直接壓垮下游子系統(tǒng)服務(wù)。
解決此問題的一個做法是對上游的訂單服務(wù)進(jìn)行限流，比如采用上面說的令牌桶。但對于一個電商系統(tǒng)來說，這么做很明顯是不合適的，因為問題不是出現(xiàn)在訂單服務(wù)上面，而且用戶買東西還限流，這樣錢送到嘴邊都賺不到。
所以會引入消息隊列來對抗這種上下游系統(tǒng)的 TPS 不一致以及瞬時的峰值流量，引入消息隊列之后，上游系統(tǒng)不再直接與下游系統(tǒng)進(jìn)行交互。當(dāng)新訂單生成之后它僅僅向隊列中發(fā)送一條消息，而下游消費(fèi)隊列中的消息，從而實現(xiàn)上游訂單服務(wù)和下游訂單處理服務(wù)的解耦。
這樣當(dāng)出現(xiàn)秒殺業(yè)務(wù)的時候，消息隊列能夠?qū)⑺矔r增加的訂單流量全部以消息的形式保存在隊列中，既不影響上游服務(wù)的 TPS，同時也給下游服務(wù)留出了足夠的時間去消費(fèi)，這就是消息隊列存在的最大意義所在。
簡單來說，我們在單體應(yīng)用里面需要使用本地隊列解決的問題，在分布式系統(tǒng)中大多都可以用消息隊列來解決。但同時我們也要認(rèn)識到，消息隊列也有它的一些問題：
- 引入消息隊列帶來的延遲問題；
- 增加了系統(tǒng)的復(fù)雜度；
- 可能產(chǎn)生數(shù)據(jù)不一致的問題；
所以在軟件開發(fā)中沒有銀彈，需要根據(jù)業(yè)務(wù)的特點和自身條件選擇合適的架構(gòu)。
消息隊列該怎么選擇
消息隊列如同數(shù)據(jù)結(jié)構(gòu)一樣，沒有最好的，只有最合適的。但不管哪種消息隊列，如果想要用于生產(chǎn)環(huán)境中，都應(yīng)該具備以下幾個特點：
- 消息的傳遞一定是可靠的；
- 支持阻塞等待拉取消息；
- 支持發(fā)布 / 訂閱模式；
- 具備 ack 機(jī)制，消費(fèi)失敗后可重新消費(fèi)，消息不丟失；
- 實例宕機(jī)了，消息也不會丟失，也就是支持?jǐn)?shù)據(jù)持久化；
- 消息可積壓；
- 支持集群部署；
- 開源免費(fèi)，社區(qū)具有一定的活躍度；
- 生態(tài)完善；
- 性能足夠好，能滿足絕大部分場景；
符合以上需求的消息隊列，主要有以下幾種。
1）RabbitMQ
RabbitMQ 是一個在 AMQP（高級消息隊列協(xié)議）基礎(chǔ)上完成的可復(fù)用的企業(yè)消息系統(tǒng)，最早為電信行業(yè)系統(tǒng)之間的可靠通信而設(shè)計，是當(dāng)前最主流的消息隊列之一。
早期的 RabbitMQ 只支持 AMQP 協(xié)議，現(xiàn)在也支持 MQTT 協(xié)議。
RabbitMQ 都具備哪些優(yōu)點呢？
- 采用 Erlang 語言編寫，Erlang 語言最初用于交換機(jī)領(lǐng)域，它有著和原生 socket 一樣的延遲，因此性能較好，吞吐量在萬級，并且時效性在微秒級。
- 功能完善，健壯、穩(wěn)定、易用、跨平臺。
- 支持大部分主流語言，文檔豐富，還提供了管理界面，并擁有非常高的社區(qū)活躍度和更新頻率。
有優(yōu)點，自然就有缺點，缺點如下：
- RabbitMQ 對消息堆積的支持并不好，在它的設(shè)計理念里面，消息隊列是一個管道，大量的消息積壓是一種不正常的情況，應(yīng)當(dāng)盡量去避免。當(dāng)大量消息積壓的時候，會導(dǎo)致 RabbitMQ 的性能急劇下降。
- RabbitMQ 的性能比較差，根據(jù)官方給出的測試數(shù)據(jù)以及使用經(jīng)驗，隨著硬件配置的不同，它大概每秒鐘可以處理幾萬到十幾萬條消息。其實這個性能也足夠支撐絕大多數(shù)的應(yīng)用場景了，但如果你的應(yīng)用對消息隊列的性能要求非常高，那就不適合選擇 RabbitMQ 了。
- RabbitMQ 使用的編程語言 Erlang，這個編程語言不僅非常小眾，學(xué)習(xí)曲線也很陡峭。
2）RocketMQ
阿里巴巴開源的一款消息隊列，用 JAVA 語言實現(xiàn)，在設(shè)計時參考了 Kafka，并做了一些改進(jìn)。在阿里內(nèi)部廣泛應(yīng)用于訂單、交易、重置、流計算、消息推送、日志流式處理、以及 binlog 分發(fā)等場景，經(jīng)歷過多次雙十一考驗，其性能、穩(wěn)定性和可靠性都是值得信賴的。
優(yōu)點如下：
- 支持單機(jī)吞吐量達(dá)到數(shù)十萬級，可用性高，分布式架構(gòu)保證消息零丟失；
- 功能較為完善，擴(kuò)展性好，支持 10 億級別的消息堆積，不會因為消息堆積導(dǎo)致性能下降；
- 對在線業(yè)務(wù)的響應(yīng)時延做了很多的優(yōu)化，大多數(shù)情況下可以做到毫秒級的響應(yīng)；
所以 RocketMQ 在吞吐量和消息堆積方面要比 RabbitMQ 高很多，如果你比較在意這兩個方面，那么可以使用 RocketMQ。而 RocketMQ 的缺點就是支持的客戶端語言不多，社區(qū)活躍度一般。
3）Kafka
大數(shù)據(jù)的殺手锏，談到大數(shù)據(jù)領(lǐng)域的消息傳輸，必然離不開 Kafka。這款為大數(shù)據(jù)而生的消息隊列，有著百分級 TPS 的吞吐量，在數(shù)據(jù)采集、傳輸、存儲的過程中發(fā)揮至關(guān)重要的作用，任何的大公司、或者做大數(shù)據(jù)的公司都離不開 Kafka。
- Kafka 的特點是性能卓越，單機(jī)寫入 TPS 在百萬條每秒，時效性也在毫秒級。
- Kafka 是分布式的，一個數(shù)據(jù)多個副本，少數(shù)的機(jī)器宕機(jī)也不會丟失數(shù)據(jù)。
- 消費(fèi)者采用 pull 方式獲取消息，消息有序、并且可以保證所有消息被消費(fèi)且僅被消費(fèi)一次。
- 擁有優(yōu)秀的第三方 Kafka Web 管理界面 Kafka-Manager，在日志領(lǐng)域比較成熟，在大數(shù)據(jù)領(lǐng)域的實時計算以及日志采集等場景中被大規(guī)模使用。
- 和周邊生態(tài)系統(tǒng)的兼容性非常好，在大數(shù)據(jù)和流計算領(lǐng)域，幾乎所有的開源軟件系統(tǒng)都會優(yōu)先支持 kafka。
Kafka 使用 Scala 和 Java 語言開發(fā)，設(shè)計上大量使用了批量和異步的思想，這種設(shè)計使得 Kafka 能做到超高的性能。但也正是這種異步批量設(shè)計使得 Kafka 的響應(yīng)時延比較高，因為客戶端發(fā)送消息的時候，不會立即發(fā)出，而是攢夠一批之后一起發(fā)送。
所以 Kafka 不太適合在線業(yè)務(wù)場景，它的重點是吞吐量，而不是低延遲。并且 Kafka 還有如下缺點：
- 單機(jī)超過 64 個分區(qū)，CPU 使用率會發(fā)生明顯的飆高現(xiàn)象，隊列越多 CPU 使用率越高，發(fā)送消息響應(yīng)時間變長；
- 使用短輪詢方式，實時性取決于輪詢間隔時間，消費(fèi)失敗不支持重試；
- 雖然支持消息有序，但如果某臺機(jī)器宕機(jī)，就會產(chǎn)生消息亂序。
那么這些消息隊列，我應(yīng)該選擇哪一種呢？
RabbitMQ：如果說消息隊列并不是你系統(tǒng)的主角之一，你對消息隊列的功能和性能都沒有很高的要求，只需要一個開箱即用易于維護(hù)的產(chǎn)品，建議使用 RabbitMQ。
RocketMQ：天生為金融領(lǐng)域而生，適合可靠性要求很高的場景，尤其是電商里面的訂單扣款、以及業(yè)務(wù)削峰。RocketMQ 在穩(wěn)定性上絕對值得信賴，畢竟這些業(yè)務(wù)場景在阿里雙十一已經(jīng)經(jīng)歷了多次考驗，如果你的業(yè)務(wù)也有類似場景，那么建議選擇 RocketMQ。
Kafka：基于 Pull 模式來處理消息，追求高吞吐量，一開始的目的就是用于日志收集和傳輸，高吞吐量是 Kakfka 的目標(biāo)。因此如果要處理海量的消息（比如日志采集、監(jiān)控信息、前端埋點），或者使用了大數(shù)據(jù)、流計算相關(guān)的開源產(chǎn)品，那么首選 Kafka。
消息隊列的存儲模型
任何一款消息隊列，都可以視為三部分：生產(chǎn)者、broker、消費(fèi)者。
- 生產(chǎn)者和消費(fèi)者都可以視為客戶端；
- broker 便是服務(wù)端啟動之后的進(jìn)程，比如 Kafka broker；
生產(chǎn)者會將消息發(fā)送至 broker 中，broker 會對消息進(jìn)行存儲以及持久化，消費(fèi)者負(fù)責(zé)從 broker 中拉取消息。如果拋開那些花里胡哨的概念，其實整個過程是非常簡單的。
而這里我們要探討的是，消息在隊列中是如何存儲的？
最初的消息隊列，就是一個嚴(yán)格意義上的隊列，它是一個先進(jìn)先出的線性表，通常使用鏈表或數(shù)組來實現(xiàn)。隊列只允許在后端（稱為 rear）進(jìn)行插入操作，在前端（稱為 front）進(jìn)行刪除操作。
這個定義里面包含幾個關(guān)鍵點：
- 先進(jìn)先出：這意味著消息在入隊和出隊的過程中，需要保證這些消息嚴(yán)格有序，消息的寫入順序和讀取順序是一致的；
- 早期的消息隊列，就是按照隊列的數(shù)據(jù)結(jié)構(gòu)來設(shè)計的；
- 生產(chǎn)者發(fā)消息是入隊操作，消費(fèi)者收消息是出隊（刪除）操作；
- 服務(wù)端存放消息的容器自然就是隊列
如果有多個生產(chǎn)者往同一個隊列里面發(fā)消息，這個隊列中可以消費(fèi)到的消息就是這些生產(chǎn)者生產(chǎn)的所有消息的合集，消息的順序就是這些生產(chǎn)者發(fā)送消息的自然順序。
同理，如果有多個消費(fèi)者接收同一個隊列的消息，這些消費(fèi)者之間就是競爭關(guān)系，每個消費(fèi)者只能收到隊列中的一部分消息，也就是說任何一條消息只能被其中的一個消費(fèi)者收到。
如果需要將一份消息數(shù)據(jù)分發(fā)給多個消費(fèi)者，要求每個消費(fèi)者都能收到全量的消息，比如一份訂單數(shù)據(jù)，要求風(fēng)控系統(tǒng)、分析系統(tǒng)、支付系統(tǒng)等都需要接收消息。這時單個隊列就滿足不了需求，一個可行的解決方式是，為每個消費(fèi)者創(chuàng)建一個單獨(dú)的隊列，讓生產(chǎn)者發(fā)送多份。
顯然這是個比較笨的做法，同樣的一份消息被復(fù)制到多個隊列中會浪費(fèi)資源。更重要的是，生產(chǎn)者必須知道有多少個消費(fèi)者，為每個消費(fèi)者單獨(dú)發(fā)送一份消息，這實際上違背了消息隊列的解耦這個設(shè)計初衷。
為了解決這個問題，演化出了另外一種消息模型：發(fā)布/訂閱模型。
在發(fā)布/訂閱模型中，消息的發(fā)送方被稱為發(fā)布者（Publisher），消息的接收方被稱為訂閱者（Subscriber），服務(wù)端存放消息的容器稱為主題（Topic）。發(fā)布者將消息發(fā)送到主題中，訂閱者在接收消息之前需要先訂閱主題，每份訂閱中，訂閱者都可以接收到主題的所有消息。
在消息領(lǐng)域的歷史上很長的一段時間，隊列模式和發(fā)布/訂閱模式是并存的，有些消息隊列同時支持這兩種消息模型。但我們仔細(xì)對比一下這兩種模型，會發(fā)現(xiàn)它們并沒有本質(zhì)的區(qū)別，生產(chǎn)者就是發(fā)布者，消費(fèi)者就是訂閱者，隊列就是主題。它們最大的區(qū)別其實就是，一份消息數(shù)據(jù)能不能被消費(fèi)多次的問題。
實際上，在這種發(fā)布/訂閱模型中，如果只有一個訂閱者，那它和隊列模型就基本是一樣的了，因此發(fā)布/訂閱模型在功能層面上可以兼容隊列模型。
現(xiàn)代的消息隊列產(chǎn)品使用的消息模型大多是這種發(fā)布/訂閱模型，當(dāng)然也有例外。
RabbitMQ 的消息模型
RabbitMQ 是少數(shù)依然堅持使用隊列模型的產(chǎn)品之一，那它是怎么解決多個消費(fèi)者的問題呢？在 RabbitMQ 里面有一個別的消息隊列都沒有的概念：Exchange（交換機(jī)），它位于生產(chǎn)者和隊列之間，生產(chǎn)者并不關(guān)心將消息發(fā)送給哪個隊列，而是將消息發(fā)送給 Exchange，由 Exchange 上配置的策略來決定將消息投遞到哪些隊列中。
同一份消息如果需要被多個消費(fèi)者消費(fèi)，則需要配置 Exchange 將消息發(fā)送到多個隊列，每個隊列中都存放一份完整的消息數(shù)據(jù)，可以為一個消費(fèi)者提供消費(fèi)服務(wù)。這也可以變相地實現(xiàn)發(fā)布/訂閱模型中，一份消息數(shù)據(jù)可以被多個訂閱者來多次消費(fèi)這樣的功能。
所以 RabbitMQ 消息傳遞模型的核心思想是：生產(chǎn)不會直接將消息發(fā)送到隊列，而是先發(fā)送到交換機(jī)。交換機(jī)的工作內(nèi)容就是接收生產(chǎn)者的消息，并且按照指定的規(guī)則將消息推入隊列，因此交換機(jī)必須清楚地知道如何處理接收到的消息，是把這些消息推送到特定隊列、還是多個隊列，亦或是丟棄它們，這要由交換機(jī)的類型決定。
交換機(jī)有 4 種類型：direct、fanout、topic、headers，默認(rèn)是 direct，不同的類型的交換機(jī)會有不同的表現(xiàn)。
RabbitMQ 會通過 Binding 將 Exchange 和 Queue 綁定在一起，并且在綁定 Exchange 和 Queue 的同時（可多次綁定），會指定一個 Binding key。而生產(chǎn)者將消息發(fā)送到 Exchange 的時候，也會帶上一個 Routing key。
- 如果交換機(jī)的類型是 direct，它會將消息推送到 Binding Key 和 Routing Key 相匹配的 Queue 中。因為交換機(jī)和隊列可以多次綁定，所以一個隊列可以有多個 Binding Key，只要一個能匹配上即可；
- 如果交換機(jī)的類型是 fanout，它會直接把消息推送到所有與它綁定的隊列中；
- 如果交換機(jī)的類型是 topic，那么 Binding Key 會支持 * 通配符，從而和 Routing Key 進(jìn)行模糊匹配；
- 如果交換機(jī)類型是 headers，會根據(jù)發(fā)送的消息內(nèi)容中的 headers 屬性進(jìn)行匹配；
RocketMQ 的消息模型
RocketMQ 使用標(biāo)準(zhǔn)的發(fā)布/訂閱模型，但它除了生產(chǎn)者、消費(fèi)者和主題之外，也有隊列這個概念，并且隊列在 RocketMQ 中是一個非常重要的概念。每個主題包含多個隊列，通過多個隊列來實現(xiàn)并行生產(chǎn)和消費(fèi)。需要注意的是，RocketMQ 只在隊列上保證消息的有序性，主題層面是無法保證消息的嚴(yán)格順序的。
RocketMQ 中，訂閱者的概念是通過消費(fèi)者組（Consumer Group）來體現(xiàn)的，每個消費(fèi)者組都消費(fèi)主題中一份完整的消息，不同消費(fèi)者組之間消費(fèi)進(jìn)度彼此不受影響。也就是說，一條消息被 Consumer Group1 消費(fèi)過，也可以再給 Consumer Group2 消費(fèi)。
但消費(fèi)者組中包含多個消費(fèi)者，同一個組內(nèi)的消費(fèi)者是競爭關(guān)系，每個消費(fèi)者負(fù)責(zé)消費(fèi)組內(nèi)的一部分消息。如果一條消息被消費(fèi)者 Consumer1 消費(fèi)了，那同組的其它消費(fèi)者就不會再收到這條消息。
在 Topic 的消費(fèi)過程中，由于消息需要被不同的組進(jìn)行多次消費(fèi)，所以消費(fèi)完的消息并不會立即被刪除，這就需要 RocketMQ 為每個消費(fèi)者組在每個隊列上維護(hù)一個消費(fèi)位移（Consumer Offset）。這個位移之前的消息都被消費(fèi)過，之后的消息都沒有被消費(fèi)過，每成功消費(fèi)一條消息，消費(fèi)位移就加一。
如果你對 RocketMQ 中的這些概念還有些困惑的話，那么沒關(guān)系，我們看一下 Kafka 的消息模型。如果你熟悉 Kafka 的話，那么你會瞬間理解 RocketMQ。
Kafka 的消息模型
Kafka 的消息模型和 RocketMQ 是完全一樣的，上面說的所有 RocketMQ 中的概念，和生產(chǎn)消費(fèi)過程中的確認(rèn)機(jī)制，都完全適用于 Kafka。唯一的區(qū)別是，在 Kafka 中，隊列這個概念的名稱不一樣，Kafka 中對應(yīng)的名稱是分區(qū)（Partition），但含義以及功能和 RocketMQ 的隊列是沒有任何區(qū)別的。
所以如果你熟悉 Kafka，那么你會瞬間理解 RocketMQ，因為兩者的消息模型是一樣的。只不過 RocketMQ 是一個主題對應(yīng)多個隊列，而 Kafka 是一個主題對應(yīng)多個分區(qū)。
小結(jié)
以上我們就探討了消息隊列的應(yīng)用場景，以及它們存儲模型之間差異。關(guān)于這些隊列更詳細(xì)的內(nèi)容，可以參考網(wǎng)上的資料。
總之當(dāng)你的數(shù)據(jù)量不大時，使用 RabbitMQ 是一個不錯的選擇。
