在上篇文章《rocketmq 是什么》中，我們了解到 RocketMQ 的架構(gòu)其實(shí)參考了 kafka 的設(shè)計(jì)思想，同時(shí)又在 kafka 的基礎(chǔ)上做了一些調(diào)整?？雌饋?，RocketMQ 好像各方面都比 kafka 更能打。

圖片

但 kafka 卻一直沒被淘汰，說明 RocketMQ 必然是有著不如 kafka 的地方。是啥呢？ 性能，嚴(yán)格來說是吞吐量。阿里中間件團(tuán)隊(duì)對它們做過壓測，同樣條件下，kafka 比 RocketMQ 快 50%左右。但即使這樣，RocketMQ 依然能每秒處理 10w 量級的數(shù)據(jù)，依舊非常能打。你不能說 RocketMQ 弱，只能說 Kafka 性能太強(qiáng)了。

不過這就很奇怪了，為什么 RocketMQ 參考了 kafka 的架構(gòu)，卻不能跟 kafka 保持一樣的性能呢？在回答這個(gè)問題之前，我們來聊下什么是零拷貝。

零拷貝是什么

我們知道，消息隊(duì)列的消息為了防止進(jìn)程崩潰后丟失，一般不會放內(nèi)存里，而是放磁盤上。那么問題就來了，消息從消息隊(duì)列的磁盤，發(fā)送到消費(fèi)者，過程是怎么樣的呢？

消息的發(fā)送過程

操作系統(tǒng)分為用戶空間和內(nèi)核空間。程序處于用戶空間，而磁盤屬于硬件，操作系統(tǒng)本質(zhì)上是程序和硬件設(shè)備的一個(gè)中間層。程序需要通過操作系統(tǒng)去調(diào)用硬件能力。

圖片

如果用戶想要將數(shù)據(jù)從磁盤發(fā)送到網(wǎng)絡(luò)。那么就會發(fā)生下面這幾件事：程序會發(fā)起系統(tǒng)調(diào)用read()，嘗試讀取磁盤數(shù)據(jù)，

? 磁盤數(shù)據(jù)從設(shè)備拷貝到內(nèi)核空間的緩沖區(qū)。

? 再從內(nèi)核空間的緩沖區(qū)拷貝到用戶空間。

程序再發(fā)起系統(tǒng)調(diào)用write()，將讀到的數(shù)據(jù)發(fā)到網(wǎng)絡(luò)：

? 數(shù)據(jù)從用戶空間拷貝到 socket 發(fā)送緩沖區(qū)

? 再從 socket 發(fā)送緩沖區(qū)拷貝到網(wǎng)卡。

最終數(shù)據(jù)就會經(jīng)過網(wǎng)絡(luò)到達(dá)消費(fèi)者。

圖片

整個(gè)過程，本機(jī)內(nèi)發(fā)生了 2 次系統(tǒng)調(diào)用，對應(yīng) 4 次用戶空間和內(nèi)核空間的切換，以及 4 次數(shù)據(jù)拷貝。

圖片

一頓操作猛如虎，結(jié)果就是同樣一份數(shù)據(jù)來回拷貝。有沒有辦法優(yōu)化呢？有，它就是零拷貝技術(shù)，常見的方案有兩種，分別是 mmap 和 sendfile。我們來看下它們是什么。

mmap 是什么

mmap 是操作系統(tǒng)內(nèi)核提供的一個(gè)方法，可以將內(nèi)核空間的緩沖區(qū)映射到用戶空間。

圖片

用了它，整個(gè)發(fā)送流程就有了一些變化。程序發(fā)起系統(tǒng)調(diào)用mmap()，嘗試讀取磁盤數(shù)據(jù)，具體情況如下：

? 磁盤數(shù)據(jù)從設(shè)備拷貝到內(nèi)核空間的緩沖區(qū)。

? 內(nèi)核空間的緩沖區(qū)映射到用戶空間，這里不需要拷貝。

程序再發(fā)起系統(tǒng)調(diào)用write()，將讀到的數(shù)據(jù)發(fā)到網(wǎng)絡(luò)：

? 數(shù)據(jù)從內(nèi)核空間緩沖區(qū)拷貝到 socket 發(fā)送緩沖區(qū)。

? 再從 socket 發(fā)送緩沖區(qū)拷貝到網(wǎng)卡。

圖片

整個(gè)過程，發(fā)生了 2 次系統(tǒng)調(diào)用，對應(yīng) 4 次用戶空間和內(nèi)核空間的切換，以及 3 次數(shù)據(jù)拷貝，對比之前，省下一次內(nèi)核空間到用戶空間的拷貝。

圖片

看到這里大家估計(jì)也蒙了，不是說零拷貝嗎？怎么還有 3 次拷貝。mmap 作為一種零拷貝技術(shù)，指的是用戶空間到內(nèi)核空間這個(gè)過程不需要拷貝，而不是指數(shù)據(jù)從磁盤到發(fā)送到網(wǎng)卡這個(gè)過程零拷貝。

圖片

確實(shí)省了一點(diǎn)，但不多。有沒有更徹底的零拷貝？有，用 sendfile.

sendfile 是什么

sendfile，也是內(nèi)核提供的一個(gè)方法，從名字可以看出，就是用來發(fā)送文件數(shù)據(jù)的。程序發(fā)起系統(tǒng)調(diào)用sendfile()，內(nèi)核會嘗試讀取磁盤數(shù)據(jù)然后發(fā)送，具體情況如下：

? 磁盤數(shù)據(jù)從設(shè)備拷貝到內(nèi)核空間的緩沖區(qū)。

? 內(nèi)核空間緩沖區(qū)里的數(shù)據(jù)可以直接拷貝到網(wǎng)卡。

圖片

整個(gè)過程，發(fā)生了 1 次系統(tǒng)調(diào)用，對應(yīng) 2 次用戶空間和內(nèi)核空間的切換，以及 2 次數(shù)據(jù)拷貝。這時(shí)候問題很多的小明就有意見了，說好的零拷貝怎么還有 2 次拷貝？

圖片

其實(shí)，這里的零拷貝指的是零 CPU拷貝。也就是說 sendfile 場景下，需要的兩次拷貝，都不是 CPU 直接參與的拷貝，而是其他硬件設(shè)備技術(shù)做的拷貝，不耽誤我們 CPU 跑程序。

kafka 為什么性能比 RocketMQ 好

聊完兩種零拷貝技術(shù)，我們回過頭來看下 kafka 為什么性能比 RocketMQ 好。這是因?yàn)?nbsp;RocketMQ 使用的是 mmap 零拷貝技術(shù)，而 kafka 使用的是 sendfile。kafka 以更少的拷貝次數(shù)以及系統(tǒng)內(nèi)核切換次數(shù)，獲得了更高的性能。但問題又來了，為什么 RocketMQ 不使用 sendfile？參考 kafka 抄個(gè)作業(yè)也不難??？我們來看下 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)

注釋里寫的是兩個(gè)函數(shù)的用法，mmap 返回的是數(shù)據(jù)的具體內(nèi)容，應(yīng)用層能獲取到消息內(nèi)容并進(jìn)行一些邏輯處理。

圖片

而 sendfile 返回的則是發(fā)送成功了幾個(gè)字節(jié)數(shù)，具體發(fā)了什么內(nèi)容，應(yīng)用層根本不知道。

圖片

而 RocketMQ 的一些功能，卻需要了解具體這個(gè)消息內(nèi)容，方便二次投遞等，比如將消費(fèi)失敗的消息重新投遞到死信隊(duì)列中，如果 RocketMQ 使用 sendfile，那根本沒機(jī)會獲取到消息內(nèi)容長什么樣子，也就沒辦法實(shí)現(xiàn)一些好用的功能了。

圖片

而 kafka 卻沒有這些功能特性，追求極致性能，正好可以使用 sendfile。

除了零拷貝以外，kafka 高性能的原因還有很多，比如什么批處理，數(shù)據(jù)壓縮啥的，但那些優(yōu)化手段 rocketMQ 也都能借鑒一波，唯獨(dú)這個(gè)零拷貝，那是毫無辦法。

圖片

所以還是那句話，沒有一種架構(gòu)是完美的，一種架構(gòu)往往用于適配某些場景，你很難做到既要又要還要。當(dāng)場景不同，我們就需要做一些定制化改造，通過犧牲一部分能力去換取另一部分能力。做架構(gòu)，做到最后都是在做折中。是不是感覺升華了。

kafka 和 RocketMQ 怎么選？

這時(shí)候大家估計(jì)還是想知道 kafka 和 RocketMQ 到底該怎么選，用哪個(gè)。官方點(diǎn)的回答是"這個(gè)要看場景的"。說了等于沒說。這不是我的風(fēng)格。我的標(biāo)準(zhǔn)只有一個(gè)，如果是大數(shù)據(jù)場景，比如你能頻繁聽到 spark，flink 這些關(guān)鍵詞的時(shí)候，那就用 kafka。除此之外，如果公司組件支持，盡量用 RocketMQ。

現(xiàn)在大家通了嗎？