1 MQ面試

1.1 問題引入

為什么使用消息隊列宵凌？
消息隊列有什么優(yōu)點和缺點？
Kafka契邀、ActiveMQ摆寄、RabbitMQ、RocketMQ 都有什么區(qū)別坯门，以及適合哪些場景微饥？

面試官心理分析
其實面試官主要是想看看：

1. 你知不知道你們系統(tǒng)里為什么要用消息隊列這個東西？
   不少候選人古戴，說自己項目里用了 Redis欠橘、MQ，但是其實他并不知道自己為什么要用這個東西现恼。其實說白了肃续，就是為了用而用，或者是別人設(shè)計的架構(gòu)叉袍，他從頭到尾都沒思考過始锚。
   沒有對自己的架構(gòu)問過為什么的人，一定是平時沒有思考的人喳逛，面試官對這類候選人印象通常很不好瞧捌。因為面試官擔(dān)心你進了團隊之后只會木頭木腦的干呆活兒，不會自己思考润文。
2. 你既然用了消息隊列這個東西姐呐，你知不知道用了有什么好處&壞處？
   你要是沒考慮過這個典蝌，那你盲目弄個 MQ 進系統(tǒng)里曙砂，后面出了問題你是不是就自己溜了給公司留坑？你要是沒考慮過引入一個技術(shù)可能存在的弊端和風(fēng)險骏掀，面試官把這類候選人招進來了鸠澈，基本可能就是挖坑型選手。就怕你干 1 年挖一堆坑截驮，自己跳槽了笑陈，給公司留下無窮后患。
3. 既然你用了 MQ侧纯，可能是某一種 MQ新锈，那么你當時做沒做過調(diào)研？
   別傻乎乎的自己拍腦袋看個人喜好就瞎用了一個 MQ眶熬，比如 Kafka妹笆，甚至都從沒調(diào)研過業(yè)界流行的 MQ 到底有哪幾種。每一個 MQ 的優(yōu)點和缺點是什么娜氏。每一個 MQ 沒有絕對的好壞拳缠，但是就是看用在哪個場景可以揚長避短，利用其優(yōu)勢贸弥，規(guī)避其劣勢窟坐。
   如果是一個不考慮技術(shù)選型的候選人招進了團隊，leader 交給他一個任務(wù)，去設(shè)計個什么系統(tǒng)哲鸳，他在里面用一些技術(shù)臣疑，可能都沒考慮過選型，最后選的技術(shù)可能并不一定合適徙菠，一樣是留坑讯沈。

1.2 面試題剖析

1.2.1 為什么使用消息隊列

其實就是問問你消息隊列都有哪些使用場景，然后你項目里具體是什么場景婿奔，說說你在這個場景里用消息隊列是什么缺狠？

面試官問你這個問題，期望的一個回答是說萍摊，你們公司有個什么業(yè)務(wù)場景挤茄，這個業(yè)務(wù)場景有個什么技術(shù)挑戰(zhàn)，如果不用 MQ 可能會很麻煩冰木，但是現(xiàn)在用了 MQ 之后帶給了你很多的好處穷劈。

先說一下消息隊列常見的使用場景吧，其實場景有很多片酝，但是比較核心的有 3 個：解耦囚衔、異步、削峰

1.2.1.1 解耦

看這么個場景雕沿。A 系統(tǒng)發(fā)送數(shù)據(jù)到 BCD 三個系統(tǒng)练湿，通過接口調(diào)用發(fā)送。如果 E 系統(tǒng)也要這個數(shù)據(jù)呢审轮？那如果 C 系統(tǒng)現(xiàn)在不需要了呢肥哎？A 系統(tǒng)負責(zé)人幾乎崩潰……

在這里插入圖片描述

在這個場景中，A 系統(tǒng)跟其它各種亂七八糟的系統(tǒng)嚴重耦合疾渣，A 系統(tǒng)產(chǎn)生一條比較關(guān)鍵的數(shù)據(jù)篡诽，很多系統(tǒng)都需要 A 系統(tǒng)將這個數(shù)據(jù)發(fā)送過來。A 系統(tǒng)要時時刻刻考慮 BCDE 四個系統(tǒng)如果掛了該咋辦榴捡？要不要重發(fā)杈女，要不要把消息存起來？

如果使用 MQ吊圾，A 系統(tǒng)產(chǎn)生一條數(shù)據(jù)达椰，發(fā)送到 MQ 里面去，哪個系統(tǒng)需要數(shù)據(jù)自己去 MQ 里面消費项乒。如果新系統(tǒng)需要數(shù)據(jù)啰劲，直接從 MQ 里消費即可；如果某個系統(tǒng)不需要這條數(shù)據(jù)了檀何，就取消對 MQ 消息的消費即可蝇裤。這樣下來廷支，A 系統(tǒng)壓根兒不需要去考慮要給誰發(fā)送數(shù)據(jù)，不需要維護這個代碼栓辜，也不需要考慮人家是否調(diào)用成功恋拍、失敗超時等情況。

在這里插入圖片描述

總結(jié)：通過一個 MQ啃憎，Pub/Sub 發(fā)布訂閱消息這么一個模型芝囤，A 系統(tǒng)就跟其它系統(tǒng)徹底解耦了似炎。

面試技巧：需要去考慮一下你負責(zé)的系統(tǒng)中是否有類似的場景辛萍，就是一個系統(tǒng)或者一個模塊，調(diào)用了多個系統(tǒng)或者模塊羡藐，互相之間的調(diào)用很復(fù)雜贩毕，維護起來很麻煩。但是其實這個調(diào)用是不需要直接同步調(diào)用接口的仆嗦，如果用 MQ 給它異步化解耦辉阶，也是可以的，你就需要去考慮在你的項目里瘩扼，是不是可以運用這個 MQ 去進行系統(tǒng)的解耦

1.2.1.2 異步

再來看一個場景谆甜，A 系統(tǒng)接收一個請求，需要在自己本地寫庫集绰，還需要在 BCD 三個系統(tǒng)寫庫规辱，自己本地寫庫要 3ms，BCD 三個系統(tǒng)分別寫庫要 300ms栽燕、450ms罕袋、200ms。最終請求總延時是 3 + 300 + 450 + 200 = 953ms碍岔，接近 1s浴讯，用戶感覺搞個什么東西，慢死了慢死了蔼啦。用戶通過瀏覽器發(fā)起請求榆纽，等待個 1s，這幾乎是不可接受的捏肢。

在這里插入圖片描述

一般互聯(lián)網(wǎng)類的企業(yè)奈籽，對于用戶直接的操作，一般要求是每個請求都必須在 200 ms 以內(nèi)完成猛计，對用戶幾乎是無感知的唠摹。

如果使用 MQ，那么 A 系統(tǒng)連續(xù)發(fā)送 3 條消息到 MQ 隊列中奉瘤，假如耗時 5ms勾拉，A 系統(tǒng)從接受一個請求到返回響應(yīng)給用戶煮甥，總時長是 3 + 5 = 8ms，對于用戶而言藕赞，其實感覺上就是點個按鈕成肘，8ms 以后就直接返回了

在這里插入圖片描述

1.2.1.3 削峰

每天 0:00 到 12:00斧蜕，A 系統(tǒng)風(fēng)平浪靜，每秒并發(fā)請求數(shù)量就 50 個洒闸。結(jié)果每次一到 12:00 ~ 13:00 ，每秒并發(fā)請求數(shù)量突然會暴增到 5k+ 條均芽。但是系統(tǒng)是直接基于 MySQL的，大量的請求涌入 MySQL深纲，每秒鐘對 MySQL 執(zhí)行約 5k 條 SQL。

一般的 MySQL劲妙，扛到每秒 2k 個請求就差不多了湃鹊，如果每秒請求到 5k 的話币呵，可能就直接把 MySQL 給打死了富雅，導(dǎo)致系統(tǒng)崩潰肛搬，用戶也就沒法再使用系統(tǒng)了温赔。

但是高峰期一過，到了下午的時候啤贩，就成了低峰期痹屹，可能也就 1w 的用戶同時在網(wǎng)站上操作志衍，每秒中的請求數(shù)量可能也就 50 個請求，對整個系統(tǒng)幾乎沒有任何的壓力培廓。

在這里插入圖片描述

在這里插入圖片描述

這個短暫的高峰期積壓是 ok 的厅贪，因為高峰期過了之后养涮，每秒鐘就 50 個請求進 MQ眉抬，但是 A 系統(tǒng)依然會按照每秒 2k 個請求的速度在處理蜀变。所以說库北，只要高峰期一過寒瓦，A 系統(tǒng)就會快速將積壓的消息給解決掉杂腰。

1.2.1.4 消息總線

所謂總線喂很，就是像主板里的數(shù)據(jù)總線一樣， 具有數(shù)據(jù)的傳遞和交互能力凌摄，各方不直接通信望伦，使用總線作為標準通信接口屯伞。

比如在彩票訂單的生命周期里劣摇，經(jīng)過創(chuàng)建末融，拆分子訂單勾习，出票，算獎等諸多環(huán)節(jié)乾颁。每一個環(huán)節(jié)都需要不同的服務(wù)處理英岭，每個系統(tǒng)都有自己獨立的表诅妹，業(yè)務(wù)功能也相對獨立吭狡。假如每個應(yīng)用都去修改訂單主表的信息赵刑，那就會相當混亂了。
因此牵现，可以搭建一個調(diào)度中心服務(wù)邀桑，調(diào)度中心維護訂單的信息壁畸，但它不與子服務(wù)通訊捏萍，而是通過消息隊列和出票網(wǎng)關(guān)令杈，算獎服務(wù)等系統(tǒng)傳遞和交換信息逗噩。

image.png

消息總線這種架構(gòu)設(shè)計捶障，可以讓系統(tǒng)更加解耦项炼，同時也可以讓每個系統(tǒng)各司其職芥挣。

1.2.1.5 延時任務(wù)

用戶在美團 APP 下單，假如沒有立即支付空另，進入訂單詳情會顯示倒計時扼菠，如果超過支付時間循榆，訂單就會被自動取消秧饮。
非常優(yōu)雅的方式是：使用消息隊列的延時消息盗尸。

訂單服務(wù)生成訂單后泼各，發(fā)送一條延時消息到消息隊列扣蜻。消息隊列在消息到達支付過期時間時莽使，將消息投遞給消費者吮旅，消費者收到消息之后庇勃，判斷訂單狀態(tài)是否為已支付责嚷，假如未支付罕拂，則執(zhí)行取消訂單的邏輯爆班。

image.png

RocketMQ 4.X 生產(chǎn)者發(fā)送延遲消息代碼如下：

Message msg = new Message();
msg.setTopic("TopicA");
msg.setTags("Tag");
msg.setBody("this is a delay message".getBytes());
//設(shè)置延遲level為5柿菩，對應(yīng)延遲1分鐘
msg.setDelayTimeLevel(5);
producer.send(msg);

RocketMQ 4.X 版本默認支持 18 個 level 的延遲消息枢舶， 通過 broker 端的 messageDelayLevel 配置項確定的凉泄。

messageDelayLevel=1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h

RocketMQ 5.X 版本支持任意時刻延遲消息胀糜，客戶端在構(gòu)造消息時提供了 3 個 API 來指定延遲時間或定時時間僚纷。

Message message = new Message(TOPIC，("Hello scheduled message " + i).getBytes(StandardCharsets.UTF_8));
// 延遲 10s 后投遞
message.setDelayTimeSec(10);
// 延遲10000ms后投遞
message.setDelayTimeMs(10_000L);
// 定時投遞陡蝇，定時時間為當前時間+10000ms
message.setDeliverTimeMs(System.currentTimeMillis() + 10_000L);
//發(fā)送消
SendResult result = producer.send(message);

點擊了解SpringBoot 整合MQ

1.2.1.6 廣播消費

廣播消費是指每條消息推送給集群內(nèi)所有的消費者登夫，保證消息至少被每個消費者消費一次恼策。

image.png

廣播消費主要用于兩種場景：消息推送和緩存同步涣楷。

1.2.1.6.1 消息推送

下圖是專車的司機端推送機制狮斗，用戶下單之后折砸，訂單系統(tǒng)生成專車訂單睦授，派單系統(tǒng)會根據(jù)相關(guān)算法將訂單派給某司機去枷，司機端就會收到派單推送消息沉填。

image.png

推送服務(wù)是一個 TCP 服務(wù)（自定義協(xié)議）翼闹，同時也是一個消費者服務(wù)猎荠，消息模式是廣播消費关摇。

司機打開司機端 APP 后输虱，APP 會通過負載均衡和推送服務(wù)創(chuàng)建長連接宪睹，推送服務(wù)會保存 TCP 連接引用 （比如司機編號和 TCP channel 的引用）。

派單服務(wù)是生產(chǎn)者罪帖，將派單數(shù)據(jù)發(fā)送到 MetaQ , 每個推送服務(wù)都會消費到該消息整袁，推送服務(wù)判斷本地內(nèi)存中是否存在該司機的 TCP channel 葬项， 若存在民珍，則通過 TCP 連接將數(shù)據(jù)推送給司機端嚷量。

1.2.1.6.2 緩存同步

高并發(fā)場景下蝶溶，很多應(yīng)用使用本地緩存抖所，提升系統(tǒng)性能 暴匠。

本地緩存可以是 HashMap 每窖、ConcurrentHashMap 窒典，也可以是緩存框架 Guava Cache 或者 Caffeine cache 瀑志。

image.png

如上圖凤覆，應(yīng)用A啟動后，作為一個 RocketMQ 消費者裁蚁，消息模式設(shè)置為廣播消費。為了提升接口性能刮吧，每個應(yīng)用節(jié)點都會將字典表加載到本地緩存里。
當字典表數(shù)據(jù)變更時致讥，可以通過業(yè)務(wù)系統(tǒng)發(fā)送一條消息到 RocketMQ 垢袱，每個應(yīng)用節(jié)點都會消費消息请契，刷新本地緩存。

1.2.1.7 分布式事務(wù)

以電商交易場景為例夏醉，用戶支付訂單這一核心操作的同時會涉及到下游物流發(fā)貨爽锥、積分變更、購物車狀態(tài)清空等多個子系統(tǒng)的變更畔柔。

image.png

1.2.1.7.1 傳統(tǒng)XA事務(wù)方案：性能不足

為了保證上述四個分支的執(zhí)行結(jié)果一致性氯夷，典型方案是基于 XA 協(xié)議的分布式事務(wù)系統(tǒng)來實現(xiàn)。將四個調(diào)用分支封裝成包含四個獨立事務(wù)分支的大事務(wù)释树。基于 XA 分布式事務(wù)的方案可以滿足業(yè)務(wù)處理結(jié)果的正確性奢啥，但最大的缺點是多分支環(huán)境下資源鎖定范圍大秸仙，并發(fā)度低，隨著下游分支的增加桩盲，系統(tǒng)性能會越來越差寂纪。

1.2.1.7.2 基于普通消息方案：一致性保障困難

image.png

該方案中消息下游分支和訂單系統(tǒng)變更的主分支很容易出現(xiàn)不一致的現(xiàn)象，例如：

• 消息發(fā)送成功赌结，訂單沒有執(zhí)行成功捞蛋，需要回滾整個事務(wù)。
• 訂單執(zhí)行成功柬姚，消息沒有發(fā)送成功拟杉，需要額外補償才能發(fā)現(xiàn)不一致。
• 消息發(fā)送超時未知量承，此時無法判斷需要回滾訂單還是提交訂單變更搬设。

1.2.1.7.3 基于 RocketMQ 分布式事務(wù)消息：支持最終一致性

上述普通消息方案中穴店，普通消息和訂單事務(wù)無法保證一致的原因，本質(zhì)上是由于普通消息無法像單機數(shù)據(jù)庫事務(wù)一樣拿穴，具備提交泣洞、回滾和統(tǒng)一協(xié)調(diào)的能力。
而基于 RocketMQ 實現(xiàn)的分布式事務(wù)消息功能默色，在普通消息基礎(chǔ)上球凰，支持二階段的提交能力。將二階段提交和本地事務(wù)綁定腿宰，實現(xiàn)全局提交結(jié)果的一致性呕诉。

交互流程如下圖所示：

image.png

• 生產(chǎn)者將消息發(fā)送至 Broker 。
• Broker 將消息持久化成功之后酗失，向生產(chǎn)者返回 Ack 確認消息已經(jīng)發(fā)送成功义钉，此時消息被標記為"暫不能投遞"，這種狀態(tài)下的消息即為半事務(wù)消息规肴。
• 生產(chǎn)者開始執(zhí)行本地事務(wù)邏輯捶闸。
• 生產(chǎn)者根據(jù)本地事務(wù)執(zhí)行結(jié)果向服務(wù)端提交二次確認結(jié)果（ Commit 或是 Rollback ），Broker 收到確認結(jié)果后處理邏輯如下：
  二次確認結(jié)果為 Commit ：Broker 將半事務(wù)消息標記為可投遞拖刃，并投遞給消費者删壮。
  二次確認結(jié)果為 Rollback ：Broker 將回滾事務(wù)，不會將半事務(wù)消息投遞給消費者兑牡。
• 在斷網(wǎng)或者是生產(chǎn)者應(yīng)用重啟的特殊情況下央碟，若 Broker 未收到發(fā)送者提交的二次確認結(jié)果，或 Broker 收到的二次確認結(jié)果為 Unknown 未知狀態(tài)均函，經(jīng)過固定時間后亿虽，服務(wù)端將對消息生產(chǎn)者即生產(chǎn)者集群中任一生產(chǎn)者實例發(fā)起消息回查。
  • 生產(chǎn)者收到消息回查后苞也，需要檢查對應(yīng)消息的本地事務(wù)執(zhí)行的最終結(jié)果洛勉。
  • 生產(chǎn)者根據(jù)檢查到的本地事務(wù)的最終狀態(tài)再次提交二次確認，服務(wù)端仍按照步驟4對半事務(wù)消息進行處理如迟。

1.2.1.8 數(shù)據(jù)中轉(zhuǎn)樞紐

近10多年來收毫，諸如 KV 存儲（HBase）、搜索（ElasticSearch）殷勘、流式處理（Storm此再、Spark、Samza）玲销、時序數(shù)據(jù)庫（OpenTSDB）等專用系統(tǒng)應(yīng)運而生输拇。這些系統(tǒng)是為單一的目標而產(chǎn)生的，因其簡單性使得在商業(yè)硬件上構(gòu)建分布式系統(tǒng)變得更加容易且性價比更高贤斜。
通常淳附，同一份數(shù)據(jù)集需要被注入到多個專用系統(tǒng)內(nèi)议慰。

例如，當應(yīng)用日志用于離線日志分析時奴曙，搜索單個日志記錄同樣不可或缺，而構(gòu)建各自獨立的工作流來采集每種類型的數(shù)據(jù)再導(dǎo)入到各自的專用系統(tǒng)顯然不切實際草讶，利用消息隊列 Kafka 作為數(shù)據(jù)中轉(zhuǎn)樞紐洽糟，同份數(shù)據(jù)可以被導(dǎo)入到不同專用系統(tǒng)中。
日志同步主要有三個關(guān)鍵部分：日志采集客戶端堕战，Kafka 消息隊列以及后端的日志處理應(yīng)用坤溃。

• 日志采集客戶端，負責(zé)用戶各類應(yīng)用服務(wù)的日志數(shù)據(jù)采集嘱丢，以消息方式將日志“批量”“異步”發(fā)送Kafka客戶端薪介。Kafka客戶端批量提交和壓縮消息，對應(yīng)用服務(wù)的性能影響非常小越驻。
• Kafka 將日志存儲在消息文件中汁政，提供持久化。

• 日志處理應(yīng)用缀旁，如 Logstash记劈，訂閱并消費Kafka中的日志消息，最終供文件搜索服務(wù)檢索日志并巍，或者由 Kafka 將消息傳遞給 Hadoop 等其他大數(shù)據(jù)應(yīng)用系統(tǒng)化存儲與分析目木。

  
  
  image.png

1.2.2 消息隊列有什么優(yōu)缺點

優(yōu)點上面已經(jīng)說了，就是在特殊場景下有其對應(yīng)的好處懊渡，解耦刽射、異步、削峰剃执。
缺點有以下幾個：

1. 系統(tǒng)可用性降低
   系統(tǒng)引入的外部依賴越多誓禁，越容易掛掉。本來你就是 A 系統(tǒng)調(diào)用 BCD 三個系統(tǒng)的接口就好了忠蝗，人 ABCD 四個系統(tǒng)好好的现横，沒啥問題，你偏加個 MQ 進來阁最，萬一 MQ 掛了咋整戒祠，MQ 一掛，整套系統(tǒng)崩潰的速种，不就完了姜盈？
2. 系統(tǒng)復(fù)雜度提高
   硬生生加個 MQ 進來，你怎么保證消息沒有重復(fù)消費配阵？怎么處理消息丟失的情況馏颂？怎么保證消息傳遞的順序性示血？
3. 一致性問題
   A 系統(tǒng)處理完了直接返回成功了，人都以為你這個請求就成功了救拉；但是問題是难审，要是 BCD 三個系統(tǒng)那里，BD 兩個系統(tǒng)寫庫成功了亿絮，結(jié)果 C 系統(tǒng)寫庫失敗了告喊，咋整？你這數(shù)據(jù)就不一致了派昧。

所以消息隊列實際是一種非常復(fù)雜的架構(gòu)黔姜，引入它有很多好處，但是也得針對它帶來的壞處做各種額外的技術(shù)方案和架構(gòu)來規(guī)避掉蒂萎，做好之后秆吵，會發(fā)現(xiàn)，系統(tǒng)復(fù)雜度提升了一個數(shù)量級五慈，也許是復(fù)雜了 10 倍纳寂。但是關(guān)鍵時刻，用豺撑，還是得用的烈疚。

1.2.3 Kafka、ActiveMQ聪轿、RabbitMQ爷肝、RocketMQ 有什么優(yōu)缺點

綜上请垛，各種對比之后，有如下建議：
一般的業(yè)務(wù)系統(tǒng)要引入 MQ洽议，最早大家都用 ActiveMQ宗收，但是現(xiàn)在確實大家用的不多了，沒經(jīng)過大規(guī)模吞吐量場景的驗證亚兄，社區(qū)也不是很活躍混稽，所以大家還是算了吧，我個人不推薦用這個了审胚；
后來大家開始用 RabbitMQ匈勋，但是確實erlang 語言阻止了大量的 Java 工程師去深入研究和掌控它，對公司而言膳叨，幾乎處于不可控的狀態(tài)洽洁，但是確實人家是開源的，比較穩(wěn)定的支持菲嘴，活躍度也高饿自；
不過現(xiàn)在確實越來越多的公司，會去用 RocketMQ龄坪，確實很不錯（阿里出品）昭雌，但社區(qū)可能有突然黃掉的風(fēng)險，對自己公司技術(shù)實力有絕對自信的悉默，推薦用 RocketMQ城豁，否則回去老老實實用 RabbitMQ 吧，人家有活躍的開源社區(qū)抄课，絕對不會黃唱星。

所以中小型公司雳旅，技術(shù)實力較為一般，技術(shù)挑戰(zhàn)不是特別高间聊，用 RabbitMQ 是不錯的選擇攒盈；大型公司，基礎(chǔ)架構(gòu)研發(fā)實力較強哎榴，用 RocketMQ 是很好的選擇型豁。

如果是大數(shù)據(jù)領(lǐng)域的實時計算、日志采集等場景尚蝌，用 Kafka 是業(yè)內(nèi)標準的迎变，絕對沒問題，社區(qū)活躍度很高飘言，絕對不會黃衣形，何況幾乎是全世界這個領(lǐng)域的事實性規(guī)范。

轉(zhuǎn)載于：https://mp.weixin.qq.com/s/iZj5NzjtxmHNXSrX16bgQA

1.2.4 RocketMQ和Kafka的區(qū)別是什么

1.2.4.1 優(yōu)缺點

Kafka的優(yōu)缺點：

• 優(yōu)點：首先姿鸿，Kafka的最大優(yōu)勢就在于它的高吞吐量谆吴，在普通機器4CPU8G的配置下，一臺機器可以抗住十幾萬的QPS苛预，這一點還是相當優(yōu)越的句狼。Kafka支持集群部署，如果部分機器宕機不可用热某，則不影響Kafka的正常使用腻菇。
• 缺點：Kafka有可能會造成數(shù)據(jù)丟失，因為它在收到消息的時候苫拍，并不是直接寫到物理磁盤的芜繁，而是先寫入到磁盤緩沖區(qū)里面的。Kafka功能比較的單一 主要的就是支持收發(fā)消息绒极，高級功能基本沒有骏令，就會造成適用場景受限。

RocketMQ是阿里巴巴開源的消息中間件垄提，優(yōu)缺點：

• 優(yōu)點：支持功能比較多榔袋，比如延遲隊列、消息事務(wù)等等铡俐，吞吐量也高凰兑，單機吞吐量達到 10 萬級，支持大規(guī)模集群部署审丘，線性擴展方便吏够，Java語言開發(fā)，滿足了國內(nèi)絕大部分公司技術(shù)棧
• 缺點：性能相比 kafka 是弱一點，因為 kafka 用到了 sendfile 的零拷貝技術(shù)锅知，而 RocketMQ 主要是用 mmap+write 來實現(xiàn)零拷貝播急。

1.2.4.2 kafka 為什么性能比 RocketMQ 好

1.2.4.2.1 kafka 順序?qū)懭?/h5>

說到高性能存儲，很多人會覺得磁盤讀寫慢得像蝸牛爬售睹。但 Kafka 可不是隨便寫寫桩警，它是典型的順序?qū)懭?/code>。
簡單說昌妹，Kafka 把數(shù)據(jù)像往一張卷子上寫答案一樣捶枢，按順序?qū)懺诖疟P上，而不是像考場上抄筆記那樣跳著寫飞崖。這種順序?qū)懖僮骼檬澹瑢Υ疟P來說性能是非常高的，因為磁盤的機械臂不用亂跑固歪，只需要寫寫寫长已，效率是很高的

1.2.4.2.2 kafka 零拷貝

RocketMQ 使用的是 mmap 零拷貝技術(shù)，而 kafka 使用的是 sendfile昼牛。kafka 以更少的拷貝次數(shù)以及系統(tǒng)內(nèi)核切換次數(shù)，獲得了更高的性能康聂。但問題又來了贰健，為什么 RocketMQ 不使用 sendfile？
我們來看下 sendfile 函數(shù)長啥樣恬汁。

ssize_t sendfile(int out_fd, int in_fd, off_t* offset, size_t count);
// num = sendfile(xxx);

再來看下 mmap 函數(shù)長啥樣伶椿。

void *mmap(void *addr, size_t length, int prot, int flags,
           int fd, off_t offset);
// buf = mmap(xxx)

注釋里寫的是兩個函數(shù)的用法，mmap 返回的是數(shù)據(jù)的具體內(nèi)容氓侧，應(yīng)用層能獲取到消息內(nèi)容并進行一些邏輯處理脊另。而 sendfile 返回的則是發(fā)送成功了幾個字節(jié)數(shù)，具體發(fā)了什么內(nèi)容约巷，應(yīng)用層根本不知道偎痛。而 RocketMQ 的一些功能，卻需要了解具體這個消息內(nèi)容独郎，方便二次投遞等踩麦，比如將消費失敗的消息重新投遞到死信隊列中，如果 RocketMQ 使用 sendfile氓癌，那根本沒機會獲取到消息內(nèi)容長什么樣子谓谦，也就沒辦法實現(xiàn)一些好用的功能了。

1.2.4.2.3 kafka 分區(qū)和副本

Kafka 另一個亮點就是分區(qū)（Partitioning）贪婉，數(shù)據(jù)存儲和處理按分區(qū)分布在多個節(jié)點上反粥。就像是公司開了多個窗口辦業(yè)務(wù)，每個窗口處理不同的事情，效率自然蹭蹭上漲才顿。

# Kafka 的分區(qū)配置
num.partitions=6
default.replication.factor=3

• 分區(qū)數(shù)（num.partitions）：這里設(shè)置了 6 個分區(qū)莫湘，數(shù)據(jù)會被切分成 6 份，分散到多個 Broker 上并行處理娜膘。
• 副本（replication.factor）：每個分區(qū)有 3 份副本逊脯，保證高可用的同時，也能在讀操作時分擔(dān)壓力竣贪。

一個簡單的場景是军洼，消費端可以并發(fā)地從多個分區(qū)消費數(shù)據(jù)，這大大提高了處理能力

1.2.4.2.3 kafka 其他優(yōu)化

除了上面三個優(yōu)化演怎，Kafka 還做了一堆優(yōu)化匕争，比如：

• 批量處理（Batching）：Kafka 會把小消息合并成一個大塊，減少網(wǎng)絡(luò)傳輸次數(shù)
• 壓縮（Compression）：Kafka 支持消息壓縮爷耀，減少數(shù)據(jù)體積甘桑，提高傳輸效率。像 Gzip 和 Snappy 這種算法都支持
• 日志段設(shè)計（Log Segmentation）：數(shù)據(jù)寫入時歹叮，Kafka 會自動把日志文件切分成多個小段跑杭，方便管理和清理，提升性能的同時咆耿，也防止單個文件太大不好用德谅。

1.2.4.3 kafka&RocketMQ怎么選擇呢

如果我們業(yè)務(wù)只是收發(fā)消息這種單一類型的需求，而且可以允許小部分數(shù)據(jù)丟失的可能性萨螺，但是又要求極高的吞吐量和高性能的話窄做，就直接選Kafka就行了，就好比我們公司想要收集和傳輸用戶行為日志以及其他相關(guān)日志的處理慰技，就選用的Kafka中間件椭盏。
如果公司的需要通過 mq 來實現(xiàn)一些業(yè)務(wù)需求，比如延遲隊列吻商、消息事務(wù)等掏颊，公司技術(shù)棧主要是Java語言的話，就直接一步到位選擇RocketMQ艾帐，這樣會省很多事情蚯舱。