日日操夜夜添-日日操影院-日日草夜夜操-日日干干-精品一区二区三区波多野结衣-精品一区二区三区高清免费不卡

最近發(fā)現(xiàn)很多號(hào)主發(fā)消息隊(duì)列的文章，質(zhì)量參差不齊，相關(guān)文章我之前也寫(xiě)過(guò)，建議直接看這篇。

這篇文章，主要講述 Kafka、RabbitMQ、RocketMQ 和 ActiveMQ 這 4 種消息隊(duì)列的異同，無(wú)論是面試，還是用于技術(shù)選型，都有非常強(qiáng)的參考價(jià)值。

不 BB，上文章目錄：

圖片

01 消息隊(duì)列基礎(chǔ)

1.1 什么是消息隊(duì)列？

消息隊(duì)列是在消息的傳輸過(guò)程中保存消息的容器，用于接收消息并以文件的方式存儲(chǔ)，一個(gè)消息隊(duì)列可以被一個(gè)也可以被多個(gè)消費(fèi)者消費(fèi)，包含以下 3 元素：

• Producer：消息生產(chǎn)者，負(fù)責(zé)產(chǎn)生和發(fā)送消息到 Broker；
• Broker：消息處理中心，負(fù)責(zé)消息存儲(chǔ)、確認(rèn)、重試等，一般其中會(huì)包含多個(gè) Queue；
• Consumer：消息消費(fèi)者，負(fù)責(zé)從 Broker 中獲取消息，并進(jìn)行相應(yīng)處理。

圖片

1.2 消息隊(duì)列模式

• 點(diǎn)對(duì)點(diǎn)模式：多個(gè)生產(chǎn)者可以向同一個(gè)消息隊(duì)列發(fā)送消息，一個(gè)具體的消息只能由一個(gè)消費(fèi)者消費(fèi)。

圖片

• 發(fā)布/訂閱模式：?jiǎn)蝹€(gè)消息可以被多個(gè)訂閱者并發(fā)的獲取和處理。

圖片

1.3 消息隊(duì)列應(yīng)用場(chǎng)景

• 應(yīng)用解耦：消息隊(duì)列減少了服務(wù)之間的耦合性，不同的服務(wù)可以通過(guò)消息隊(duì)列進(jìn)行通信，而不用關(guān)心彼此的實(shí)現(xiàn)細(xì)節(jié)。
• 異步處理：消息隊(duì)列本身是異步的，它允許接收者在消息發(fā)送很長(zhǎng)時(shí)間后再取回消息。
• 流量削鋒：當(dāng)上下游系統(tǒng)處理能力存在差距的時(shí)候，利用消息隊(duì)列做一個(gè)通用的”載體”，在下游有能力處理的時(shí)候，再進(jìn)行分發(fā)與處理。
• 日志處理：日志處理是指將消息隊(duì)列用在日志處理中，比如 Kafka 的應(yīng)用，解決大量日志傳輸?shù)膯?wèn)題。
• 消息通訊：消息隊(duì)列一般都內(nèi)置了高效的通信機(jī)制，因此也可以用在純的消息通訊，比如實(shí)現(xiàn)點(diǎn)對(duì)點(diǎn)消息隊(duì)列，或者聊天室等。
• 消息廣播：如果沒(méi)有消息隊(duì)列，每當(dāng)一個(gè)新的業(yè)務(wù)方接入，我們都要接入一次新接口。有了消息隊(duì)列，我們只需要關(guān)心消息是否送達(dá)了隊(duì)列，至于誰(shuí)希望訂閱，是下游的事情，無(wú)疑極大地減少了開(kāi)發(fā)和聯(lián)調(diào)的工作量。

02 常用消息隊(duì)列

由于官方社區(qū)現(xiàn)在對(duì) ActiveMQ 5.x 維護(hù)越來(lái)越少，較少在大規(guī)模吞吐的場(chǎng)景中使用，所以我們主要講解 Kafka、RabbitMQ 和 RocketMQ。

2.1 Kafka

Apache Kafka 最初由 LinkedIn 公司基于獨(dú)特的設(shè)計(jì)實(shí)現(xiàn)為一個(gè)分布式的提交日志系統(tǒng)，之后成為 Apache 項(xiàng)目的一部分，號(hào)稱大數(shù)據(jù)的殺手锏，在數(shù)據(jù)采集、傳輸、存儲(chǔ)的過(guò)程中發(fā)揮著舉足輕重的作用。

它是一個(gè)分布式的，支持多分區(qū)、多副本，基于 Zookeeper 的分布式消息流平臺(tái)，它同時(shí)也是一款開(kāi)源的基于發(fā)布訂閱模式的消息引擎系統(tǒng)。

重要概念

• 主題（Topic）：消息的種類稱為主題，可以說(shuō)一個(gè)主題代表了一類消息，相當(dāng)于是對(duì)消息進(jìn)行分類，主題就像是數(shù)據(jù)庫(kù)中的表。
• 分區(qū)（partition）：主題可以被分為若干個(gè)分區(qū)，同一個(gè)主題中的分區(qū)可以不在一個(gè)機(jī)器上，有可能會(huì)部署在多個(gè)機(jī)器上，由此來(lái)實(shí)現(xiàn) kafka 的伸縮性。
• 批次：為了提高效率， 消息會(huì)分批次寫(xiě)入 Kafka，批次就代指的是一組消息。
• 消費(fèi)者群組（Consumer Group）：消費(fèi)者群組指的就是由一個(gè)或多個(gè)消費(fèi)者組成的群體。
• Broker: 一個(gè)獨(dú)立的 Kafka 服務(wù)器就被稱為 broker，broker 接收來(lái)自生產(chǎn)者的消息，為消息設(shè)置偏移量，并提交消息到磁盤(pán)保存。
• Broker 集群：broker 集群由一個(gè)或多個(gè) broker 組成。
• 重平衡（Rebalance）：消費(fèi)者組內(nèi)某個(gè)消費(fèi)者實(shí)例掛掉后，其他消費(fèi)者實(shí)例自動(dòng)重新分配訂閱主題分區(qū)的過(guò)程。

Kafka 架構(gòu)

一個(gè)典型的 Kafka 集群中包含 Producer、broker、Consumer Group、Zookeeper 集群。

Kafka 通過(guò) Zookeeper 管理集群配置，選舉 leader，以及在 Consumer Group 發(fā)生變化時(shí)進(jìn)行 rebalance。Producer 使用 push 模式將消息發(fā)布到 broker，Consumer 使用 pull 模式從 broker 訂閱并消費(fèi)消息。

圖片

Kafka 工作原理

消息經(jīng)過(guò)序列化后，通過(guò)不同的分區(qū)策略，找到對(duì)應(yīng)的分區(qū)。

相同主題和分區(qū)的消息，會(huì)被存放在同一個(gè)批次里，然后由一個(gè)獨(dú)立的線程負(fù)責(zé)把它們發(fā)到 Kafka Broker 上。

圖片

分區(qū)的策略包括順序輪詢、隨機(jī)輪詢和 key hash 這 3 種方式，那什么是分區(qū)呢？

分區(qū)是 Kafka 讀寫(xiě)數(shù)據(jù)的最小粒度，比如主題 A 有 15 條消息，有 5 個(gè)分區(qū)，如果采用順序輪詢的方式，15 條消息會(huì)順序分配給這 5 個(gè)分區(qū)，后續(xù)消費(fèi)的時(shí)候，也是按照分區(qū)粒度消費(fèi)。

圖片

由于分區(qū)可以部署在多個(gè)不同的機(jī)器上，所以可以通過(guò)分區(qū)實(shí)現(xiàn) Kafka 的伸縮性，比如主題 A 的 5 個(gè)分區(qū)，分別部署在 5 臺(tái)機(jī)器上，如果下線一臺(tái)，分區(qū)就變?yōu)?4。

Kafka 消費(fèi)是通過(guò)消費(fèi)群組完成，同一個(gè)消費(fèi)者群組，一個(gè)消費(fèi)者可以消費(fèi)多個(gè)分區(qū)，但是一個(gè)分區(qū)，只能被一個(gè)消費(fèi)者消費(fèi)。

圖片

如果消費(fèi)者增加，會(huì)觸發(fā) Rebalance，也就是分區(qū)和消費(fèi)者需要重新配對(duì)。

不同的消費(fèi)群組互不干涉，比如下圖的 2 個(gè)消費(fèi)群組，可以分別消費(fèi)這 4 個(gè)分區(qū)的消息，互不影響。

圖片

2.2 RocketMQ

RocketMQ 是阿里開(kāi)源的消息中間件，它是純 JAVA 開(kāi)發(fā)，具有高性能、高可靠、高實(shí)時(shí)、適合大規(guī)模分布式系統(tǒng)應(yīng)用的特點(diǎn)。

RocketMQ 思路起源于 Kafka，但并不是 Kafka 的一個(gè) Copy，它對(duì)消息的可靠傳輸及事務(wù)性做了優(yōu)化，目前在阿里集團(tuán)被廣泛應(yīng)用于交易、充值、流計(jì)算、消息推送、日志流式處理、binglog 分發(fā)等場(chǎng)景。

重要概念

• Name 服務(wù)器（NameServer）：充當(dāng)注冊(cè)中心，類似 Kafka 中的 Zookeeper。
• Broker: 一個(gè)獨(dú)立的 RocketMQ 服務(wù)器就被稱為 broker，broker 接收來(lái)自生產(chǎn)者的消息，為消息設(shè)置偏移量。
• 主題（Topic）：消息的第一級(jí)類型，一條消息必須有一個(gè) Topic。
• 子主題（Tag）：消息的第二級(jí)類型，同一業(yè)務(wù)模塊不同目的的消息就可以用相同 Topic 和不同的 Tag 來(lái)標(biāo)識(shí)。
• 分組（Group）：一個(gè)組可以訂閱多個(gè) Topic，包括生產(chǎn)者組（Producer Group）和消費(fèi)者組（Consumer Group）。
• 隊(duì)列（Queue）：可以類比 Kafka 的分區(qū) Partition。

RocketMQ 工作原理

RockerMQ 中的消息模型就是按照主題模型所實(shí)現(xiàn)的，包括 Producer Group、Topic、Consumer Group 三個(gè)角色。

為了提高并發(fā)能力，一個(gè) Topic 包含多個(gè) Queue，生產(chǎn)者組根據(jù)主題將消息放入對(duì)應(yīng)的 Topic，下圖是采用輪詢的方式找到里面的 Queue。

RockerMQ 中的消費(fèi)群組和 Queue，可以類比 Kafka 中的消費(fèi)群組和 Partition：不同的消費(fèi)者組互不干擾，一個(gè) Queue 只能被一個(gè)消費(fèi)者消費(fèi)，一個(gè)消費(fèi)者可以消費(fèi)多個(gè) Queue。

消費(fèi) Queue 的過(guò)程中，通過(guò)偏移量記錄消費(fèi)的位置。

圖片

RocketMQ 架構(gòu)

RocketMQ 技術(shù)架構(gòu)中有四大角色 NameServer、Broker、Producer 和 Consumer，下面主要介紹 Broker。

Broker 用于存放 Queue，一個(gè) Broker 可以配置多個(gè) Topic，一個(gè) Topic 中存在多個(gè) Queue。

如果某個(gè) Topic 消息量很大，應(yīng)該給它多配置幾個(gè) Queue，并且盡量多分布在不同 broker 上，以減輕某個(gè) broker 的壓力。Topic 消息量都比較均勻的情況下，如果某個(gè) broker 上的隊(duì)列越多，則該 broker 壓力越大。

圖片

簡(jiǎn)單提一下，Broker 通過(guò)集群部署，并且提供了 master/slave 的結(jié)構(gòu)，salve 定時(shí)從 master 同步數(shù)據(jù)（同步刷盤(pán)或者異步刷盤(pán)），如果 master 宕機(jī)，則 slave 提供消費(fèi)服務(wù)，但是不能寫(xiě)入消息。

看到這里，大家應(yīng)該可以發(fā)現(xiàn)，RocketMQ 的設(shè)計(jì)和 Kafka 真的很像！

2.3 RabbitMQ

RabbitMQ 2007 年發(fā)布，是使用 Erlang 語(yǔ)言開(kāi)發(fā)的開(kāi)源消息隊(duì)列系統(tǒng)，基于 AMQP 協(xié)議來(lái)實(shí)現(xiàn)。

AMQP 的主要特征是面向消息、隊(duì)列、路由、可靠性、安全。AMQP 協(xié)議更多用在企業(yè)系統(tǒng)內(nèi)，對(duì)數(shù)據(jù)一致性、穩(wěn)定性和可靠性要求很高的場(chǎng)景，對(duì)性能和吞吐量的要求還在其次。

重要概念

• 信道（Channel）：消息讀寫(xiě)等操作在信道中進(jìn)行，客戶端可以建立多個(gè)信道，每個(gè)信道代表一個(gè)會(huì)話任務(wù)。
• 交換器（Exchange）：接收消息，按照路由規(guī)則將消息路由到一個(gè)或者多個(gè)隊(duì)列；如果路由不到，或者返回給生產(chǎn)者，或者直接丟棄。
• 路由鍵（RoutingKey）：生產(chǎn)者將消息發(fā)送給交換器的時(shí)候，會(huì)發(fā)送一個(gè) RoutingKey，用來(lái)指定路由規(guī)則，這樣交換器就知道把消息發(fā)送到哪個(gè)隊(duì)列。
• 綁定（Binding）：交換器和消息隊(duì)列之間的虛擬連接，綁定中可以包含一個(gè)或者多個(gè) RoutingKey。

RabbitMQ 工作原理

AMQP 協(xié)議模型由三部分組成：生產(chǎn)者、消費(fèi)者和服務(wù)端，執(zhí)行流程如下：

1. 生產(chǎn)者是連接到 Server，建立一個(gè)連接，開(kāi)啟一個(gè)信道。
2. 生產(chǎn)者聲明交換器和隊(duì)列，設(shè)置相關(guān)屬性，并通過(guò)路由鍵將交換器和隊(duì)列進(jìn)行綁定。
3. 消費(fèi)者也需要進(jìn)行建立連接，開(kāi)啟信道等操作，便于接收消息。
4. 生產(chǎn)者發(fā)送消息，發(fā)送到服務(wù)端中的虛擬主機(jī)。
5. 虛擬主機(jī)中的交換器根據(jù)路由鍵選擇路由規(guī)則，發(fā)送到不同的消息隊(duì)列中。
6. 訂閱了消息隊(duì)列的消費(fèi)者就可以獲取到消息，進(jìn)行消費(fèi)。

圖片

常用交換器

RabbitMQ 常用的交換器類型有 direct、topic、fanout、headers 四種，具體的使用方法，可以參考官網(wǎng)：

官網(wǎng)入口：https://www.rabbitmq.com/getstarted.html

• 1.

圖片

03 消息隊(duì)列對(duì)比

圖片

3.1 Kafka

優(yōu)點(diǎn)：

• 高吞吐、低延遲：Kafka 最大的特點(diǎn)就是收發(fā)消息非常快，Kafka 每秒可以處理幾十萬(wàn)條消息，它的最低延遲只有幾毫秒；
• 高伸縮性：每個(gè)主題（topic）包含多個(gè)分區(qū)（partition），主題中的分區(qū)可以分布在不同的主機(jī)（broker）中；
• 高穩(wěn)定性：Kafka 是分布式的，一個(gè)數(shù)據(jù)多個(gè)副本，某個(gè)節(jié)點(diǎn)宕機(jī)，Kafka 集群能夠正常工作；
• 持久性、可靠性、可回溯：Kafka 能夠允許數(shù)據(jù)的持久化存儲(chǔ)，消息被持久化到磁盤(pán)，并支持?jǐn)?shù)據(jù)備份防止數(shù)據(jù)丟失，支持消息回溯；
• 消息有序：通過(guò)控制能夠保證所有消息被消費(fèi)且僅被消費(fèi)一次；
• 有優(yōu)秀的第三方 Kafka Web 管理界面 Kafka-Manager，在日志領(lǐng)域比較成熟，被多家公司和多個(gè)開(kāi)源項(xiàng)目使用。

缺點(diǎn)：

• Kafka 單機(jī)超過(guò) 64 個(gè)隊(duì)列/分區(qū)，Load 會(huì)發(fā)生明顯的飆高現(xiàn)象，隊(duì)列越多，load 越高，發(fā)送消息響應(yīng)時(shí)間變長(zhǎng)；
• 不支持消息路由，不支持延遲發(fā)送，不支持消息重試；
• 社區(qū)更新較慢。

3.2 RocketMQ

優(yōu)點(diǎn)：

• 高吞吐：借鑒 Kafka 的設(shè)計(jì)，單一隊(duì)列百萬(wàn)消息的堆積能力；
• 高伸縮性：靈活的分布式橫向擴(kuò)展部署架構(gòu)，整體架構(gòu)其實(shí)和 kafka 很像；
• 高容錯(cuò)性：通過(guò)ACK機(jī)制，保證消息一定能正常消費(fèi)；
• 持久化、可回溯：消息可以持久化到磁盤(pán)中，支持消息回溯；
• 消息有序：在一個(gè)隊(duì)列中可靠的先進(jìn)先出（FIFO）和嚴(yán)格的順序傳遞；
• 支持發(fā)布/訂閱和點(diǎn)對(duì)點(diǎn)消息模型，支持拉、推兩種消息模式；
• 提供 Docker 鏡像用于隔離測(cè)試和云集群部署，提供配置、指標(biāo)和監(jiān)控等功能豐富的 Dashboard。

缺點(diǎn)：

• 不支持消息路由，支持的客戶端語(yǔ)言不多，目前是 java 及 c++，其中 c++ 不成熟；
• 部分支持消息有序：需要將同一類的消息 hash 到同一個(gè)隊(duì)列 Queue 中，才能支持消息的順序，如果同一類消息散落到不同的 Queue中，就不能支持消息的順序。
• 社區(qū)活躍度一般。

3.3 RabbitMQ

優(yōu)點(diǎn)：

• 支持幾乎所有最受歡迎的編程語(yǔ)言：Java，C，C ++，C＃，Ruby，Perl，Python/ target=_blank class=infotextkey>Python，php等等；
• 支持消息路由：RabbitMQ 可以通過(guò)不同的交換器支持不同種類的消息路由；
• 消息時(shí)序：通過(guò)延時(shí)隊(duì)列，可以指定消息的延時(shí)時(shí)間，過(guò)期時(shí)間TTL等；
• 支持容錯(cuò)處理：通過(guò)交付重試和死信交換器（DLX）來(lái)處理消息處理故障；
• 提供了一個(gè)易用的用戶界面，使得用戶可以監(jiān)控和管理消息 Broker；
• 社區(qū)活躍度高。

缺點(diǎn)：

• Erlang 開(kāi)發(fā)，很難去看懂源碼，不利于做二次開(kāi)發(fā)和維護(hù)，基本職能依賴于開(kāi)源社區(qū)的快速維護(hù)和修復(fù) bug；
• RabbitMQ 吞吐量會(huì)低一些，這是因?yàn)樗龅膶?shí)現(xiàn)機(jī)制比較重；
• 不支持消息有序、持久化不好、不支持消息回溯、伸縮性一般。

04 消息隊(duì)列選型

Kafka：追求高吞吐量，一開(kāi)始的目的就是用于日志收集和傳輸，適合產(chǎn)生大量數(shù)據(jù)的互聯(lián)網(wǎng)服務(wù)的數(shù)據(jù)收集業(yè)務(wù)，大型公司建議可以選用，如果有日志采集功能，肯定是首選 kafka。

RocketMQ：天生為金融互聯(lián)網(wǎng)領(lǐng)域而生，對(duì)于可靠性要求很高的場(chǎng)景，尤其是電商里面的訂單扣款，以及業(yè)務(wù)削峰，在大量交易涌入時(shí)，后端可能無(wú)法及時(shí)處理的情況。RoketMQ 在穩(wěn)定性上可能更值得信賴，這些業(yè)務(wù)場(chǎng)景在阿里雙 11 已經(jīng)經(jīng)歷了多次考驗(yàn)，如果你的業(yè)務(wù)有上述并發(fā)場(chǎng)景，建議可以選擇 RocketMQ。

RabbitMQ：結(jié)合 erlang 語(yǔ)言本身的并發(fā)優(yōu)勢(shì)，性能較好，社區(qū)活躍度也比較高，但是不利于做二次開(kāi)發(fā)和維護(hù)，不過(guò) RabbitMQ 的社區(qū)十分活躍，可以解決開(kāi)發(fā)過(guò)程中遇到的 bug。如果你的數(shù)據(jù)量沒(méi)有那么大，小公司優(yōu)先選擇功能比較完備的 RabbitMQ。

ActiveMQ：官方社區(qū)現(xiàn)在對(duì) ActiveMQ 5.x 維護(hù)越來(lái)越少，較少在大規(guī)模吞吐的場(chǎng)景中使用。