先說個背景。做后端這幾年消息隊列基本是繞不開的中間件。不管是電商的訂單流轉(zhuǎn)、日志收集、異步通知還是高并發(fā)下的削峰填谷你總會遇到一個場景需要引入消息隊列。市面上一堆MQ但真正經(jīng)常被提起、被面試官追問、被生產(chǎn)環(huán)境大規(guī)模使用的無非就是Kafka、RabbitMQ和RocketMQ這三個。我這些年三個隊列都用過踩過不少坑也總結(jié)出一些實戰(zhàn)經(jīng)驗這篇就一次性把它們從選型、部署、代碼接入到問題排查完整串一遍。這篇內(nèi)容不會照著官方文檔念而是從實際使用者的視角出發(fā)講清楚每個隊列的核心原理、安裝關(guān)鍵點和代碼落地的真實細節(jié)。不管你是剛接觸消息隊列的新人還是已經(jīng)用了一段時間、想系統(tǒng)補一遍的開發(fā)者都能從中找到可直接參考的東西。文章比較長建議先收藏等真正用的時候再回來翻。1. 提筆之前消息隊列到底解決什么問題三大隊列該怎么選1.1 消息隊列的核心價值不是隊列而是解耦很多人理解消息隊列第一反應(yīng)就是先進先出的數(shù)據(jù)結(jié)構(gòu)。這個理解沒錯但在實際工程里消息隊列的核心價值根本不是隊列本身而是它帶來的三個能力異步、削峰、解耦。我再拆細一點。異步用戶下單后系統(tǒng)需要發(fā)短信、發(fā)優(yōu)惠券、更新積分。如果這些步驟全部串行執(zhí)行一次請求可能要等幾百毫秒甚至更久。把非核心操作丟進隊列主鏈路只處理扣庫存、生成訂單響應(yīng)時間直接從秒級降到毫秒級。削峰秒殺場景下瞬間涌入十萬請求數(shù)據(jù)庫根本扛不住。讓請求先進隊列后端按自身處理能力慢慢消費系統(tǒng)就不會被流量打垮。解耦訂單服務(wù)不需要知道庫存服務(wù)、物流服務(wù)的具體實現(xiàn)只要往隊列里發(fā)一條訂單創(chuàng)建成功的消息下游服務(wù)各自訂閱自己關(guān)心的內(nèi)容互不干擾。這也是為什么現(xiàn)在的面試題里消息隊列幾乎是必問項。面試官想知道的不只是你會不會調(diào)API而是你有沒有真正理解它解決什么問題、在什么場景下選哪個。1.2 三個隊列的定位差異與選型邏輯Kafka、RabbitMQ、RocketMQ雖然都叫消息隊列但出生背景完全不同這也決定了它們的主戰(zhàn)場不同。Kafka出生在LinkedIn最初是為了處理海量日志流而設(shè)計的。它的架構(gòu)天然適合大規(guī)模數(shù)據(jù)管道、日志采集、流式計算這類場景吞吐量極高但功能相對寡淡——延時消息、死信隊列這些高級特性原生支持都不太好得靠外部或自己實現(xiàn)。RabbitMQ是Erlang寫的老牌消息中間件功能非常豐富路由模式靈活文檔生態(tài)完善適合企業(yè)內(nèi)部業(yè)務(wù)系統(tǒng)之間做消息通信。RocketMQ是阿里開源的消息中間件人家是從電商業(yè)務(wù)里長出來的所以天然補齊了阿里巴巴在交易鏈路上的各種需求事務(wù)消息、延時消息、消息重試、死信隊列甚至消息軌跡追蹤都有。簡單總結(jié)選型邏輯你們做的是大數(shù)據(jù)管道、日志采集、流計算那一路選Kafka業(yè)務(wù)系統(tǒng)內(nèi)部需要靈活的路由、優(yōu)先級、RPC調(diào)用通知選RabbitMQ業(yè)務(wù)量很大并且深度使用Java需要事務(wù)消息和可靠投遞選RocketMQ。這不是絕對的但九成場景這么選都不會錯。2. RabbitMQ功能最全的業(yè)務(wù)消息中間件從安裝到生產(chǎn)落地2.1 安裝部署Windows、Linux和Docker三種方式對比RabbitMQ在Windows上的安裝以前是不少人入門的第一道坎。它依賴Erlang環(huán)境需要先下載Erlang的Windows安裝包再下載RabbitMQ Server的Windows安裝包而且版本要對應(yīng)。網(wǎng)上關(guān)于RabbitMQ下載和安裝的教程很多但我見過太多人卡在Erlang版本和RabbitMQ版本不匹配這個問題上。官網(wǎng)上每個RabbitMQ版本都會標注對應(yīng)的Erlang版本區(qū)間安裝前務(wù)必核對。Windows下安裝完還需要手動激活管理插件命令行執(zhí)行rabbitmq-plugins enable rabbitmq_management然后重啟RabbitMQ服務(wù)瀏覽器訪問http://localhost:15672 用默認賬號guest/guest登錄。這里有個坑默認的guest賬號只能在localhost訪問如果你用IP地址訪問管理臺會被拒絕。要么用localhost訪問要么新建一個用戶并賦予權(quán)限。Linux下安裝稍微順暢一些因為官方提供了apt和yum源。以Ubuntu為例sudo apt-get install -y rabbitmq-server sudo systemctl enable rabbitmq-server sudo systemctl start rabbitmq-server sudo rabbitmq-plugins enable rabbitmq_management但最推薦的方式還是Docker尤其適合本地開發(fā)和測試環(huán)境。一條命令搞定還不用操心底層依賴docker run -d --name rabbitmq \ -p 5672:5672 -p 15672:15672 \ -e RABBITMQ_DEFAULT_USERadmin \ -e RABBITMQ_DEFAULT_PASSadmin123 \ rabbitmq:3.12-management這里要注意鏡像分為兩個版本rabbitmq版本號不帶management和rabbitmq版本號-management帶管理臺插件。本地調(diào)試建議直接用management版本省得手動裝插件。2.2 核心概念與Java客戶端接入RabbitMQ的核心模型是生產(chǎn)者Producer把消息發(fā)給交換機Exchange交換機根據(jù)路由規(guī)則把消息投遞到綁定的隊列Queue消費者Consumer從隊列拉取消息處理。很多人第一反應(yīng)是為什么不直接發(fā)到隊列原因在于交換機提供了靈活的路由能力。交換機有四種類型Direct點對點精確匹配、Fanout廣播給所有綁定的隊列、Topic通配符匹配路由鍵、Headers基于消息頭的匹配用得少。實際工程中Topic交換機用得最多因為它的匹配規(guī)則靈活。比如訂單系統(tǒng)發(fā)一條消息路由鍵是order.created物流服務(wù)綁定order.*積分服務(wù)綁定order.created兩個服務(wù)都能收到消息非常方便。Java客戶端接入的代碼核心就三塊。第一塊是創(chuàng)建連接工廠ConnectionFactory factory new ConnectionFactory(); factory.setHost(localhost); factory.setUsername(admin); factory.setPassword(admin123); Connection connection factory.newConnection(); Channel channel connection.createChannel();第二塊是聲明隊列和交換機并做綁定channel.exchangeDeclare(order.exchange, topic, true); channel.queueDeclare(order.queue, true, false, false, null); channel.queueBind(order.queue, order.exchange, order.#);第三塊是發(fā)送消息和接收消息。發(fā)送String message 訂單創(chuàng)建成功; channel.basicPublish(order.exchange, order.created, null, message.getBytes());接收channel.basicConsume(order.queue, false, (consumerTag, delivery) - { String msg new String(delivery.getBody(), UTF-8); System.out.println(收到消息: msg); channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false); }, consumerTag - {});注意basicConsume的第二個參數(shù)是autoAck工作中我建議一律顯式設(shè)為false手動調(diào)用basicAck確認消息。原因很簡單如果設(shè)置了自動確認消費者收到消息但還沒來得及處理就掛了消息就丟了手動確認可以確保消息被完整處理后才會從隊列移除。2.3 消息可靠性生產(chǎn)端確認與消費端手動Ack消息隊列最讓人頭疼的問題就是消息丟失。RabbitMQ的消息丟失可能發(fā)生在三個環(huán)節(jié)生產(chǎn)者發(fā)送時、隊列存儲時、消費者消費時。生產(chǎn)端要開啟生產(chǎn)確認模式。在channel上調(diào)用confirmSelect()方法發(fā)布消息后等待broker的確認回調(diào)不確認就重發(fā)。這是第一層保障。隊列持久化第二層保障聲明隊列時把durable參數(shù)設(shè)為true這樣RabbitMQ重啟后隊列和消息還在。消費端手動Ack第三層保障前面已經(jīng)提到過。這三層都做好了消息才能做到不丟失。很多人配置完不管不顧直到某天凌晨收到告警郵件才發(fā)現(xiàn)消息丟了一查結(jié)果就是消費者沒做手動確認。這類問題我在生產(chǎn)環(huán)境見過太多次。2.4 高頻問題延時隊列、死信隊列與重復(fù)消費RabbitMQ原生的延時隊列是通過死信交換機DLX機制實現(xiàn)的。思路是給隊列設(shè)置一個TTL消息過期后會被轉(zhuǎn)投到綁定的死信交換機再由死信交換機路由到真正的處理隊列。這個方案雖然繞但生產(chǎn)環(huán)境很常見。比如電商下單后30分鐘未支付自動關(guān)閉訂單就是用延時隊列實現(xiàn)的。所以RabbitMQ面試題里死信隊列是絕對的高頻考點。實現(xiàn)要點是創(chuàng)建兩個隊列和一個交換機一個普通隊列帶DLX配置和TTL一個實際處理隊列綁定死信交換機。重復(fù)消費問題則是所有消息隊列的通病。根本原因在于分布式網(wǎng)絡(luò)環(huán)境下消息可能因為網(wǎng)絡(luò)抖動導(dǎo)致消費者已經(jīng)處理完但Ack沒送達brokerbroker會重發(fā)消息。解決思路也比較統(tǒng)一消費者側(cè)做冪等處理。常見方案有用redis setnx做冪等鍵、數(shù)據(jù)庫唯一約束、業(yè)務(wù)表里加一個處理狀態(tài)字段。我在項目里用的最多的是業(yè)務(wù)鍵Redis的方式消息到達先檢查Redis里是否已存在該消息ID存在則直接返回不存在則處理并寫入Redis。3. Kafka高吞吐的日志與流數(shù)據(jù)處理利器原理和集群安裝一次說清3.1 Kafka的架構(gòu)與工作原理先弄懂Kafka的基本模型BrokerKafka服務(wù)器節(jié)點、Topic消息分類、PartitionTopic的分區(qū)、Producer生產(chǎn)者、Consumer消費者和Consumer Group消費者組。Kafka最大的特點是分區(qū)并行這也是它吞吐量遠超其他MQ的關(guān)鍵。一個Topic可以分成多個Partition每個Partition是獨立的日志文件讀寫互不干擾。消費者組里的每個消費者負責(zé)部分分區(qū)實現(xiàn)水平擴展。Kafka的消息在Partition內(nèi)是有序的不同Partition之間無順序保證。Kafka的存儲機制也很特別。消息寫入后不是立即刪除而是保存在磁盤里基于順序?qū)懞晚摼彺婕夹g(shù)保證高吞吐。消息的消費進度由消費者自己管理——記錄當前消費到哪個Offset。這也解釋了為什么Kafka的消費者可以做到隨時回溯你可以把Offset重置到昨天重新消費一遍。3.2 單機與集群安裝Kafka本身依賴ZooKeeper新版雖然引入了KRaft模式但大多數(shù)生產(chǎn)環(huán)境還在用ZooKeeper安裝Kafka基本離不開ZooKeeper。這也是Kafka安裝鏈路比其他MQ繁重的原因。單機安裝比較簡單這里是Linux環(huán)境操作# 下載解壓kafka wget https://downloads.apache.org/kafka/3.4.0/kafka_2.13-3.4.0.tgz tar -zxvf kafka_2.13-3.4.0.tgz cd kafka_2.13-3.4.0 # 啟動ZooKeeper bin/zookeeper-server-start.sh config/zookeeper.properties # 啟動Kafka bin/kafka-server-start.sh config/server.properties 集群安裝本質(zhì)上就是多節(jié)點配置。每個Broker要修改config/server.properties里的幾個關(guān)鍵參數(shù)broker.id集群內(nèi)唯一、listeners監(jiān)聽地址、log.dirs日志目錄、zookeeper.connect指向ZooKeeper集群。三節(jié)點的集群配置大致是這樣node1: broker.id0listenersPLAINTEXT://192.168.1.10:9092node2: broker.id1listenersPLAINTEXT://192.168.1.11:9092node3: broker.id2listenersPLAINTEXT://192.168.1.12:9092ZooKeeper地址都寫成zookeeper集群的地址列表比如192.168.1.1:2181,192.168.1.2:2181,192.168.1.3:2181。如果是離線環(huán)境Kafka集群離線安裝也不復(fù)雜——就是把已經(jīng)下載好的tar包和依賴包通過內(nèi)網(wǎng)傳輸?shù)侥繕藱C器安裝步驟和在線一致。關(guān)鍵在于三臺機器的時鐘要同步建議配置NTP。集群配置完成后用kafka-topics.sh創(chuàng)建topic時指定replication-factor數(shù)據(jù)才會在多個broker間復(fù)制。3.3 生產(chǎn)與消費命令實操Kafka的命令行是排查問題的利器熟練掌握能省很多時間。創(chuàng)建主題bin/kafka-topics.sh --create \ --bootstrap-server localhost:9092 \ --replication-factor 1 --partitions 3 \ --topic order-topic生產(chǎn)消息測試bin/kafka-console-producer.sh --broker-list localhost:9092 --topic order-topic消費消息bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 \ --topic order-topic --from-beginning這條消費命令有一個參數(shù)經(jīng)常被忽略--from-beginning。它的含義是從最早的Offset開始消費。如果你想讓消費者從指定時間點開始消費可以加--offset 指定Offset位置或者用--partition加--offset組合。熱搜詞里提到的kafka消費命令指定消費時間實際做法是用kafka-consumer-groups.sh重置偏移量bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 \ --group my-group --topic order-topic \ --reset-offsets --to-datetime 2024-01-01T00:00:00.000 --execute這條命令很實用當年排查線上數(shù)據(jù)異常時就是用這個把消費者組的Offset重置到出問題之前的某個時間點讓消費者重新消費那段歷史消息。3.4 Kafka可視化工具與消息延遲排查Kafka是出了名的難以可視化的中間件不像RabbitMQ自帶一個漂亮的管理臺。很多剛接觸Kafka的人都會搜kafka可視化工具、kafka連接工具、kafka圖形界面。這里我推薦兩個Kafka Tool現(xiàn)在叫Offset Explorer和Kafka UI。前者是桌面客戶端圖形化查看Topic、Partition、Consumer Group的Offset情況適合日常排查后者是Web界面支持集群管理、消息查看和動態(tài)創(chuàng)建Topic適合團隊共用。關(guān)于Kafka消息延遲高的問題幾乎每個團隊都會遇到。我排查這類問題的經(jīng)驗是按鏈路逐個檢查先看生產(chǎn)者端發(fā)送耗時是不是發(fā)送時同步等待過久如果批量發(fā)送參數(shù)設(shè)置不合理會影響性能。再看消費者端處理速度是不是單條消息處理邏輯太慢或者消費者線程數(shù)太低。重點看兩個指標Consumer Group的Lag積壓量和每個分區(qū)的處理耗時。如果Lag持續(xù)增長說明消費速度趕不上生產(chǎn)速度。處理人最多的方案是加消費者實例增加單個消費者的線程數(shù)或者優(yōu)化消費邏輯的DB訪問比如把單條插入改成批量插入。還有一點很容易被忽略如果某些消息處理邏輯里有外部API調(diào)用而外部服務(wù)響應(yīng)慢會直接拖垮整個消費者的消費速度。這種情況建議把外部調(diào)用改成異步或做本地緩存。4. RocketMQ國產(chǎn)電商級消息中間件部署、控制臺到高級特性全解4.1 RocketMQ的核心模型與工作原理RocketMQ的架構(gòu)和Kafka很相似核心概念包括NameServer、Broker、Topic、Consumer Group。它和Kafka最大的不同是引入了NameServer來實現(xiàn)路由管理替代了ZooKeeper。NameServer是一個輕量級的注冊中心Broker啟動后向所有NameServer注冊自己的地址信息生產(chǎn)者和消費者通過NameServer獲取Broker地址。RocketMQ的工作流程可以理解成生產(chǎn)者連接NameServer拉取Topic的路由信息把消息發(fā)往對應(yīng)的BrokerBroker存儲消息并同步到從節(jié)點如果配置了主從消費者同樣先從NameServer獲取路由信息再從Broker拉取消息。多臺NameServer之間不互相通信每臺NameServer都保存全量的路由信息所以部署時哪怕掛了一臺NameServer集群依然可用。4.2 Docker Compose部署RocketMQ與控制臺RocketMQ的部署在三個隊列里算是偏繁瑣的因為它包含NameServer、Broker、Console三個組件。手動一臺臺搭建非常痛苦我強烈建議用Docker Compose一鍵搞定。新建一個docker-compose.yml文件參考配置如下version: 3.8 services: namesrv: image: apache/rocketmq:5.1.4 container_name: rocketmq-namesrv ports: - 9876:9876 command: sh mqnamesrv broker: image: apache/rocketmq:5.1.4 container_name: rocketmq-broker depends_on: - namesrv ports: - 10909:10909 - 10911:10911 - 10912:10912 environment: - NAMESRV_ADDRnamesrv:9876 volumes: - ./broker.conf:/home/rocketmq/rocketmq-5.1.4/conf/broker.conf command: sh mqbroker -c /home/rocketmq/rocketmq-5.1.4/conf/broker.conf console: image: apacherocketmq/rocketmq-dashboard:latest container_name: rocketmq-console depends_on: - namesrv ports: - 8080:8080 environment: - JAVA_OPTS-Drocketmq.namesrv.addrnamesrv:9876broker.conf文件至少需要配置這幾項否則生產(chǎn)環(huán)境會出問題brokerClusterNameDefaultCluster brokerNamebroker-a brokerId0 deleteWhen04 fileReservedTime48 brokerRoleASYNC_MASTER flushDiskTypeASYNC_FLUSH # 如果broker和代碼不在同一臺機器必須配置這個地址 brokerIP1你的服務(wù)器公網(wǎng)IP或內(nèi)網(wǎng)IP autoCreateTopicEnabletrue很多人部署完RocketMQ后生產(chǎn)消息報錯業(yè)務(wù)測試怎么都通不過絕大多數(shù)都是因為brokerIP1沒有配置導(dǎo)致客戶端連不上broker。這是RocketMQ安裝里最常見的坑之一。執(zhí)行docker-compose up -d后訪問http://localhost:8080 就能看到控制臺可以查看Topic列表、消費進度、消息軌跡等。4.3 延遲消息、批量消費與事務(wù)消息RocketMQ的延遲消息支持比RabbitMQ原生得多。發(fā)送延遲消息不需要搞死信隊列直接指定delayLevel即可Message msg new Message(order-topic, order.pay.timeout, 訂單超時關(guān)閉.getBytes()); // delayLevel5 表示延遲1分鐘 msg.setDelayTimeLevel(5); SendResult sendResult producer.send(msg);RocketMQ預(yù)定義了18個延遲級別1s、5s、10s、30s、1m、2m、3m、4m、5m、6m、7m、8m、9m、10m、20m、30m、1h、2h分別對應(yīng)delayLevel的1到18。這個是固定配置不支持任意時間。如果項目需要自定義延遲時間得自己實現(xiàn)。批量消費是RocketMQ在效率方面的一個優(yōu)勢。消費端可以設(shè)置一次拉取的消息條數(shù)consumer.setConsumeMessageBatchMaxSize(10);配合批量處理能顯著減少網(wǎng)絡(luò)開銷和數(shù)據(jù)庫連接消耗。我在高吞吐業(yè)務(wù)里用過消費TPS提升非常明顯。注意批量消費時是按List傳入你要正確處理List里的每一條消息某一條處理失敗會影響一批。事務(wù)消息是RocketMQ最引以為傲的特性。它的原理是兩階段提交先發(fā)送半消息Half Message這條消息對消費者不可見然后執(zhí)行本地事務(wù)根據(jù)本地事務(wù)結(jié)果執(zhí)行commit或rollback。如果本地事務(wù)執(zhí)行后出現(xiàn)了超時RocketMQ會回調(diào)你注冊的檢查方法根據(jù)本地事務(wù)的狀態(tài)來確認最終是提交還是回滾。這個特性能完美解決本地數(shù)據(jù)庫操作和發(fā)消息不一致的問題。比如訂單創(chuàng)建成功后要發(fā)一條優(yōu)惠券消息如果先插數(shù)據(jù)庫再發(fā)消息可能消息發(fā)送失敗導(dǎo)致用戶收不到券如果先發(fā)消息再操作數(shù)據(jù)庫可能數(shù)據(jù)庫操作失敗但消息已經(jīng)發(fā)出去了。用事務(wù)消息可以保證數(shù)據(jù)庫訂單沒創(chuàng)建成功消息一定不會發(fā)出去。4.4 RocketMQ集群模式與生產(chǎn)環(huán)境注意事項RocketMQ的集群模式主要分單主、多主、主從等幾種。單主節(jié)點適合測試環(huán)境生產(chǎn)環(huán)境至少要做主從。最常用的生產(chǎn)方案是多主多從異步復(fù)制兼顧了吞吐量和數(shù)據(jù)安全。集群部署時每個Broker節(jié)點配置不同的brokerName和brokerIdbrokerId為0的代表Master大于0的代表Slave。比如有兩組brokerbroker-a: brokerNamebroker-a, brokerId0broker-a-slave: brokerNamebroker-a, brokerId1broker-b: brokerNamebroker-b, brokerId0broker-b-slave: brokerNamebroker-b, brokerId1生產(chǎn)環(huán)境下還要注意幾個細節(jié)autoCreateTopicEnable建議在生產(chǎn)設(shè)為false避免誤創(chuàng)建大量無意義的TopicfileReservedTime決定消息文件保留多少天超過會定期刪除deleteWhen表示凌晨幾點執(zhí)行清理flushDiskType建議生產(chǎn)環(huán)境用SYNC_FLUSH保證消息寫入磁盤成功才返回成功雖然性能有損耗但可靠行更高。5. 三大隊列的對比總結(jié)、面試高頻考點與最終選型建議5.1 功能維度橫向?qū)Ρ任野讶齻€隊列的核心特性整理成一個表方便你對比查看。對比維度KafkaRabbitMQRocketMQ語言Java/ScalaErlangJava吞吐量極高百萬級/秒中等萬級/秒高十萬級/秒延遲毫秒級微秒級毫秒級消息順序分區(qū)內(nèi)有序單隊列有序隊列內(nèi)有序延遲消息不支持原生通過死信實現(xiàn)原生支持18個級別事務(wù)消息不支持不支持支持死信隊列需自己實現(xiàn)原生支持原生支持管理界面無官方需第三方自帶Web控制臺官方Dashboard成熟度極高極高高國內(nèi)電商廣泛使用適用場景日志、大數(shù)據(jù)、流處理業(yè)務(wù)系統(tǒng)、靈活路由電商、金融、業(yè)務(wù)量大5.2 面試高頻考點重復(fù)消費、順序消息、消息堆積面試題里三大隊列經(jīng)常被放在一起對比但核心考點其實是幾個通用的消息中間件問題。搞清楚這幾個問題不管用哪個隊列都能應(yīng)對自如。第一個是消息隊列重復(fù)消費問題。這個我在前面已經(jīng)提過解決思路核心是消費者冪等。面試官更想聽的不只是用Redis去重而是你能不能講清楚重復(fù)消費產(chǎn)生的根本原因——消息隊列的At Least Once語義下網(wǎng)絡(luò)分區(qū)、消費者宕機、Ack超時都可能導(dǎo)致消息重發(fā)。解決思路可以分層數(shù)據(jù)庫唯一約束、Redis分布式鎖配合業(yè)務(wù)鍵、甚至業(yè)務(wù)邏輯本身就設(shè)計成天然冪等。第二個是順序消息怎么保證。Kafka的做法是讓同一業(yè)務(wù)key的消息進入同一個Partition消費者單線程消費該Partition這樣在分區(qū)內(nèi)保持順序。RabbitMQ單隊列天然有序但引入多個消費者并發(fā)消費后順序會亂需要用一致性哈希把同一業(yè)務(wù)的key路由到同一個隊列。RocketMQ提供了普通順序消息和嚴格順序消息通過MessageQueueSelector把同一業(yè)務(wù)的key發(fā)送到同一個隊列。第三個是消息堆積如何處理。核心是先保證不丟消息再提高消費速度。具體做法臨時擴容消費者實例數(shù)增加單個消費者內(nèi)部的并發(fā)線程或者優(yōu)化消費邏輯。如果積壓太嚴重Kafka可以新建一個Topic將積壓的消息轉(zhuǎn)發(fā)到新Topic用更多的消費者并行處理。RocketMQ和RabbitMQ也可以參考類似思路本質(zhì)是把一條長隊列拆成多條短隊列并行消費。還有一個高頻考點是消息丟失問題結(jié)合我前面的內(nèi)容從生產(chǎn)者、broker、消費者三個環(huán)節(jié)分別分析即可。生產(chǎn)者確認機制、broker持久化、消費者手動Ack每個環(huán)節(jié)都有對應(yīng)方案。5.3 基于實際項目的選型建議聊完對比和技術(shù)細節(jié)最后說說我個人在實際項目中的選型心得。如果你在做一個中小型業(yè)務(wù)系統(tǒng)團隊不大也沒有復(fù)雜的消息需求RabbitMQ是最穩(wěn)的選擇。它的學(xué)習(xí)曲線平緩、文檔完善、部署簡單出問題也好排查網(wǎng)上答案一搜一大把。如果你所在公司有大數(shù)據(jù)平臺需要把業(yè)務(wù)數(shù)據(jù)同步到數(shù)倉或日志系統(tǒng)或者要做流計算Kafka幾乎是唯一選項。Kafka的生態(tài)太強了Flink、Spark Streaming這些流處理框架都和它深度集成。如果你在做電商、金融、支付這類高一致性要求的業(yè)務(wù)系統(tǒng)且團隊以Java為主RocketMQ值得認真考慮。事務(wù)消息在真實業(yè)務(wù)里非常實用能省去大量手工處理本地事務(wù)和消息不一致的代碼。部署方面我的建議是所有消息隊列都先用Docker或Docker Compose在測試環(huán)境跑通確認無誤后再考慮生產(chǎn)環(huán)境的物理機或K8s部署。生產(chǎn)環(huán)境務(wù)必要做集群、監(jiān)控和告警這三個隊列都有對應(yīng)的監(jiān)控手段RabbitMQ看管理臺的隊列堆積和消費速率Kafka看Consumer Group的Lag和broker的存活狀態(tài)RocketMQ看控制臺的消費進度和消息軌跡。6. 寫在最后我的實戰(zhàn)心得與排障技巧從我這些年折騰三個隊列的經(jīng)驗來看消息隊列本身不難難的是把消息隊列用得穩(wěn)。很多人剛開始用的時候只關(guān)心怎么把消息發(fā)出去、怎么收下來等上了生產(chǎn)環(huán)境遇到消息丟失、重復(fù)消費、順序錯亂才開始頭疼。所以我最后針對三個隊列各分享一個容易被人忽略的實戰(zhàn)技巧。RabbitMQ這個技巧是關(guān)于連接管理的。生產(chǎn)環(huán)境一定要用連接池管理Connection不要每次發(fā)消息都新建連接。Connection的創(chuàng)建是重操作頻繁創(chuàng)建會打滿文件描述符最終導(dǎo)致連接被拒絕。Channel也是類似同一個線程可以復(fù)用同一個Channel。Kafka的實戰(zhàn)技巧是關(guān)于Consumer的。消費者啟動后要注意設(shè)置一個合理的max.poll.interval.ms默認值是5分鐘。如果你的單條消息處理時間超過5分鐘消費者會被判定為假死觸發(fā)rebalance消息會被其他消費者重新消費極容易引發(fā)重復(fù)消費。遇到過好幾次莫名重復(fù)消費的線上事故排查到最后都是這個參數(shù)的問題。RocketMQ的實戰(zhàn)技巧是關(guān)于消息軌跡的。如果線上消息莫名其妙就沒了先在控制臺的消息軌跡里查一下消息的完整生命周期看是生產(chǎn)端沒發(fā)出去、broker丟失還是消費端拉到了但處理失敗。RocketMQ的軌跡功能非常完善定位問題效率很高。不要一上來就去翻服務(wù)日志那樣太慢。最后再講一個所有消息隊列都適用的排查思路消息隊列的問題本質(zhì)上是鏈路問題。排查時一定不要只看單個節(jié)點要從生產(chǎn)者、broker、消費者三段同時看哪一段有瓶頸數(shù)據(jù)會說話的。把消息隊列的指標監(jiān)控做起來比什么大牛排查技巧都管用。