作者：火山引擎云原生計(jì)算研發(fā)工程師｜雷麗媛

上文我們了解了在字節(jié)跳動內(nèi)部業(yè)務(wù)快速增長的推動下，經(jīng)典消息隊(duì)列 Kafka 的劣勢開始逐漸暴露，在彈性、規(guī)模、成本及運(yùn)維方面都無法滿足業(yè)務(wù)需求。因此字節(jié)消息隊(duì)列團(tuán)隊(duì)研發(fā)了計(jì)算存儲分離的云原生消息引擎 BMQ，在極速擴(kuò)縮容及吞吐上都有非常好的表現(xiàn)。本文將繼續(xù)從整體技術(shù)架構(gòu)開始，介紹字節(jié)自研的云原生消息引擎的分層架構(gòu)在數(shù)據(jù)存儲模型、運(yùn)維等角度的優(yōu)勢及挑戰(zhàn)。

回顧：一文了解字節(jié)跳動消息隊(duì)列演進(jìn)之路

云原生消息引擎 BMQ 架構(gòu)

從整體來看，BMQ 與 Kafka 架構(gòu)最大的不同在于 BMQ 是存算分離的架構(gòu)，相較于 Kafka 將數(shù)據(jù)存儲在本地磁盤，BMQ 將數(shù)據(jù)存儲在了分布式的存儲系統(tǒng)。在 BMQ 內(nèi)部，主要有四個模塊：Proxy，Broker，Coordinator 和 Controller。我們依次來看一下這些模塊的主要工作：

• Proxy 負(fù)責(zé)接收所有用戶的請求，對于生產(chǎn)請求，Proxy 會將其轉(zhuǎn)發(fā)給對應(yīng)的 Broker；對于消費(fèi)者相關(guān)的請求，例如 commit offset，join group 等，Proxy 會將其轉(zhuǎn)發(fā)給對應(yīng)的 Coordinator；對于讀請求 Proxy 會直接處理，并將結(jié)果返回給客戶端。

• BMQ 的 Broker 與 Kafka 的 Broker 略有不同，它主要負(fù)責(zé)寫入請求的處理，其余請求交給了 Proxy 和 Coordinator 處理。

• Coordinator 與 Kafka 版本最大的差別在于我們將其從 Broker 中獨(dú)立，作為單獨(dú)的進(jìn)程提供服務(wù)。這樣的好處是讀寫流量與消費(fèi)者協(xié)調(diào)的資源可以完全隔離，不會互相影響。另外 Coordinator 可以獨(dú)立擴(kuò)縮容，以應(yīng)對不同集群的情況。

• Controller 承擔(dān)組件心跳管理、負(fù)載均衡、故障檢測及控制命令接入的工作。因?yàn)?BMQ 將數(shù)據(jù)放在分布式存儲系統(tǒng)上，因此無需管理數(shù)據(jù)副本，相較于 Kafka 省去了 ISR 相關(guān)的管理。Controller 可以更加專注地關(guān)注集群整體流量均衡及故障檢測。

在 BMQ 中用戶所有請求都會由 Proxy 接入，因此 BMQ 的 Metadata 中的 ‘Broker’ 信息實(shí)際上填寫的是 BMQ 中 Proxy 的信息，客戶端根據(jù) Metadata 請求將生產(chǎn)和消費(fèi)等請求發(fā)送到對應(yīng)的 Proxy，再由 Proxy 處理或轉(zhuǎn)發(fā)。這樣的架構(gòu)有助于 BMQ 做更多的容錯工作。例如在 Broker 重啟時，Proxy 可以感知到相關(guān)錯誤并進(jìn)行退避重試，避免將異常直接暴露給客戶端；此外我們可以監(jiān)控 Proxy 在訪問其他組件時產(chǎn)生的錯誤，進(jìn)行一些自動的故障診斷，并將故障節(jié)點(diǎn)自動隔離，避免對用戶產(chǎn)生影響。

分層架構(gòu)的優(yōu)勢

分層架構(gòu)的優(yōu)勢是顯而易見的，BMQ 作為計(jì)算層無狀態(tài)，可以實(shí)現(xiàn)秒級的擴(kuò)縮容或故障機(jī)替換。在故障場景下，例如交換機(jī)故障或機(jī)房故障，可以秒級將流量調(diào)度到健康節(jié)點(diǎn)恢復(fù)服務(wù)。

數(shù)據(jù)存儲模型

在分層之后數(shù)據(jù)存儲模型上的優(yōu)勢，主要體現(xiàn)在 BMQ 中，一個 Partition 的數(shù)據(jù)會和 Kafka 一樣被切分為若干個 Segment，Kafka 中的這些 Segment 都會被存儲在同一塊磁盤上，而在 BMQ 中，因?yàn)閿?shù)據(jù)存儲在分布式存儲中，每一個 Segment 也都被存儲在存儲池中不同的磁盤上。從上圖中可以明顯看出，BMQ 的存儲模型很好的解決了熱點(diǎn)問題。即使 Partition 間數(shù)據(jù)大小或訪問吞吐差別很大，被切割成 Segment 后都能均勻地分散在存儲池中。

? 接下來我們通過一個例子進(jìn)一步感受池化存儲的優(yōu)勢。

在 Kafka 的使用中，我們經(jīng)常會有回溯數(shù)據(jù)的需求，以上圖中的數(shù)據(jù)分布為例，例如業(yè)務(wù)有需求回溯 Partition 1 全部的數(shù)據(jù)，高吞吐的 IO 會影響磁盤的性能，在 Kafka 存儲模型中與 Partition 1 Leader 同在一塊磁盤的 Partition 3 Follower 就會受到影響，使得 Partition 3 處于 Under Replica 的狀態(tài)。這個狀態(tài)會持續(xù)到用戶將 Partition 全部數(shù)據(jù)回溯完成。

而在 BMQ 的存儲模型中，Partition 1 的數(shù)據(jù)分散在不同磁盤上，熱點(diǎn)會隨著用戶的回溯進(jìn)程轉(zhuǎn)移，不會持續(xù)影響同一塊磁盤。且對于回溯訪問的磁盤，僅有已經(jīng)存儲在該磁盤的其他 Segment 剛好被用戶消費(fèi)時，或有新的 Segment 要寫入該磁盤的時候會受影響。此外我們也可以通過一些策略避免寫入有熱點(diǎn)訪問的磁盤來降低熱點(diǎn)訪問對新寫入的影響。總結(jié)來看，Kafka 存儲模型下，熱點(diǎn)訪問對同磁盤其他訪問的影響大、持續(xù)長、且優(yōu)化空間不大；而 BMQ 的池化存儲模型中，熱點(diǎn)影響范圍小、持續(xù)時間短，并且可以通過一些策略優(yōu)化進(jìn)一步降低影響。

運(yùn)維及故障影響

從運(yùn)維角度來看，BMQ 的存儲模型也有非常大的優(yōu)勢。無論重啟、替換、擴(kuò)容還是縮容，Kafka 都需要數(shù)據(jù)拷貝。以擴(kuò)容為例，新擴(kuò)容的 Broker 需要作為 Partition 的 follower，將數(shù)據(jù)從 leader 所在 Broker 拷貝至本地，全部拷貝完成后新 Broker 才可以晉升為 leader 提供服務(wù)。而矛盾的地方在于，當(dāng)業(yè)務(wù)流量上漲急需擴(kuò)容時，Broker 已經(jīng)沒有多余的帶寬來支持拷貝數(shù)據(jù)了。而 BMQ 所依賴的分布式存儲系統(tǒng)則沒有這個問題，同樣以擴(kuò)容為例，新擴(kuò)充進(jìn)來的存儲節(jié)點(diǎn)可以立即提供讀寫服務(wù)，無需做額外的數(shù)據(jù)拷貝，不會對原有存儲造成額外壓力。而在替換和縮容場景，分布式存儲依然需要一些數(shù)據(jù)拷貝來補(bǔ)齊副本，但對業(yè)務(wù)影響會小很多。因?yàn)閿?shù)據(jù)存儲是分散的，因此拷貝的 IO 也會分散在多臺存儲上。

從故障影響角度分析，以兩副本的配置為例，在 Kafka 場景下，任意兩臺 Broker 宕機(jī)都會造成某個 Partition 無法讀寫，且數(shù)據(jù)全部丟失。在 BMQ 的存儲模型下，任意兩臺存儲節(jié)點(diǎn)的異常都不會影響新寫入的數(shù)據(jù)，因?yàn)橹灰婊畹拇鎯?jié)點(diǎn)可以支持寫入流量，新寫入的數(shù)據(jù)就可以選擇剩余健康的存儲節(jié)點(diǎn)寫入。對于已經(jīng)存入的數(shù)據(jù)，兩臺存儲節(jié)點(diǎn)宕機(jī)會導(dǎo)致同時存在這兩臺機(jī)器上的 Segment 無法讀取，若這個 Segment 是最近寫入的尚未被消費(fèi)的，則會影響這部分?jǐn)?shù)據(jù)的消費(fèi)，但若這個 Segment 剛好是一個歷史數(shù)據(jù)，沒有消費(fèi)者需要，那就不會對業(yè)務(wù)產(chǎn)生實(shí)際影響。

分層架構(gòu)的挑戰(zhàn)

上面我們討論了分層架構(gòu)帶來的優(yōu)勢，下面要來分析下挑戰(zhàn)以及 BMQ 的解決方案。分層存儲之后 BMQ 訪問數(shù)據(jù)的代價增加了，訪問存儲在分布式系統(tǒng)上的數(shù)據(jù)延時會比直接讀取本地磁盤稍高，并且我們也需要考慮對分布式存儲系統(tǒng)元信息及存儲節(jié)點(diǎn)的壓力情況。下面我們來分別看一下 BMQ 在生產(chǎn)和消費(fèi)這兩條鏈路上是如何克服這些困難的。

生產(chǎn)

首先介紹一下 BMQ 數(shù)據(jù)寫入的流程。上文介紹過 Broker 是主要負(fù)責(zé)數(shù)據(jù)寫入的節(jié)點(diǎn)，由 Controller 負(fù)責(zé)將 Partition 分配到各個 Broker 上。因?yàn)?Kafka 協(xié)議中 Partition 內(nèi)部的數(shù)據(jù)是有序的，因此每個 Partition 只會在唯一一個 Broker 上調(diào)度。Controller 調(diào)度的時候也會綜合考慮 Broker 的負(fù)載及 Partition 的流量等因素，最終做到 Broker 之間的負(fù)載均衡。

如上圖所示，當(dāng)一個 Partition 被調(diào)度到 Broker 上之后，便開始了它的生命周期。首先 Partition 會進(jìn)行 Recover，即從上一個 Checkpoint 恢復(fù)數(shù)據(jù)，并將最終結(jié)果保存，這樣做是避免因意外宕機(jī)導(dǎo)致用戶已經(jīng)寫入成功的數(shù)據(jù)丟失。之后 Partition 便會創(chuàng)建一個新的 Segment 開始寫入數(shù)據(jù)，期間會寫入索引等信息。當(dāng)文件長度到達(dá)配置長度，或者文件寫入持續(xù)到達(dá)配置時間后會被關(guān)閉，存儲相關(guān)元信息，并開啟一個新的 Segment 寫入。依次循環(huán)，直到 Controller 將 Partition 從這個 Broker 調(diào)度走，或發(fā)生異常 Partition 退出。

我們可以看到在狀態(tài)集中有一個 Failover 節(jié)點(diǎn)，這個節(jié)點(diǎn)是 BMQ 降低分布式存儲延時毛刺的關(guān)鍵。每一次寫入 BMQ 會先將數(shù)據(jù)放入一個 Inflight Buffer 中，之后通過異步調(diào)用分布式存儲的 Flush 接口持久化數(shù)據(jù)。若 Flush 在預(yù)期時間內(nèi)返回成功，那么 Inflight Buffer 數(shù)據(jù)中的數(shù)據(jù)會被清除，同時返回給用戶寫入成功的回應(yīng)。但若因?yàn)榫W(wǎng)絡(luò)或者慢節(jié)點(diǎn)問題導(dǎo)致寫入超時，那么 Broker 會直接創(chuàng)建一個新的 Segment 文件，將 Inflight Buffer 中的數(shù)據(jù)直接寫入新的文件，并在后臺異步將之前的 Segment 文件關(guān)閉。對于異步關(guān)閉的這個文件，元信息只會包含成功返回的數(shù)據(jù)長度，最后超時的部分則不會被記錄，這樣即使超時數(shù)據(jù)最終確實(shí)寫入了分布式存儲，也不會被用戶讀取造成數(shù)據(jù)重復(fù)，這一整個過程就是我們說的 Failover。

為什么通過切一個文件就能解決這個問題呢？這也與存儲模型有關(guān)。Kafka 因?yàn)橐粋€ Partition 數(shù)據(jù)均被存儲在一塊磁盤上，那么若是因?yàn)榇疟P異常引起的延時抖動，無論如何切換文件都是不能解決的。但是在 BMQ 中，每個 Segment 都是一個文件，而每個文件的多個副本都會隨機(jī)地分布在整個存儲池中。那么若存儲池中有少數(shù)慢節(jié)點(diǎn)，隨機(jī)切換一個節(jié)點(diǎn)大概率可以繞過故障的節(jié)點(diǎn)。因此，在慢節(jié)點(diǎn)問題及偶發(fā)的磁盤熱點(diǎn)問題上，BMQ 可以更加靈活地規(guī)避，降低這些問題對用戶的影響。

當(dāng)然，BMQ 的分層架構(gòu)對于底層的分布式存儲系統(tǒng)也提出了較高的要求。火山引擎上分布式存儲系統(tǒng)由 C++ 實(shí)現(xiàn)，是一個高性能的分布式文件系統(tǒng)。能夠提供 5w QPS 寫入及 15w QPS 讀取的元信息訪問能力；寫入訪問延時 p99 約在 10 毫秒左右，讀取延時 p99 為亞毫秒級別；并且單集群可以承載 50 億文件。同時在數(shù)據(jù)寫入方面對寫入延時也做了很多優(yōu)化，包括慢節(jié)點(diǎn)的檢測和規(guī)避、利用 NVMe 加速的多介質(zhì)存儲功能等。

消費(fèi)

當(dāng)一個消費(fèi)請求到達(dá) Kafka Broker，Broker 會查看當(dāng)前是否有足夠多的已寫入數(shù)據(jù)返回給消費(fèi)者，如果條件滿足則會讀取數(shù)據(jù)并返回。這個流程非常簡單清晰，但這個流程不能直接照搬到 BMQ，因?yàn)?BMQ 底層是分布式存儲系統(tǒng)，如果對于每個請求都直接從存儲層讀取數(shù)據(jù)，那么對于分布式存儲系統(tǒng)的元信息和數(shù)據(jù)節(jié)點(diǎn)都是極大地壓力，并且延時也會變得非常高。因此直接處理消費(fèi)請求的 BMQ Proxy 針對讀流程設(shè)計(jì)了多個緩存機(jī)制。

第一個緩存系統(tǒng)非常直觀，我們稱之為 Message Cache。顧名思義，這個緩存存儲的是消息數(shù)據(jù)。Message Cache 會將每個 Partition 末尾的一部分?jǐn)?shù)據(jù)從遠(yuǎn)端讀取回來，并緩存在內(nèi)存中，以供消費(fèi)者讀取。若這個 Partition 有多個消費(fèi)組，那么理想情況下，他們只會產(chǎn)生一次分布式文件系統(tǒng)的實(shí)際數(shù)據(jù)讀取，其余請求均會從 Proxy 內(nèi)存中直接獲取數(shù)據(jù)。不同于 Kafka 依賴于 Page Cache，BMQ 的 Message Cache 擁有豐富的淘汰策略以應(yīng)對不同的生產(chǎn)消費(fèi)場景，使得緩存命中率更高。

當(dāng)然，不是所有的請求都能夠完美的命中 Message Cache，一些消費(fèi)者會因?yàn)橄M(fèi)資源不足或業(yè)務(wù)需求消費(fèi)一些較老的數(shù)據(jù)，而這部分?jǐn)?shù)據(jù)無法被 Message Cache 覆蓋。如果在這種請求發(fā)生時 Proxy 直接讀取分布式存儲系統(tǒng)則會對其造成一次元數(shù)據(jù)的訪問，當(dāng)請求變多時分布式存儲系統(tǒng)的元數(shù)據(jù)節(jié)點(diǎn)將不堪重負(fù)。因此 Proxy 設(shè)計(jì)來 File Cache 來應(yīng)對這種情況。Proxy 會緩存某個 Segment 的文件句柄，即這個 Segment 所對應(yīng)文件的文件句柄。因?yàn)?Kafka 的消費(fèi)場景下，用戶大多數(shù)情況都是順序消費(fèi)，因此一個消費(fèi)請求這一次所訪問的文件很大概率是上一次請求訪問過的文件。線上實(shí)踐效果來看，File Cache 可以幫助我們減少 70% 對后端存儲的元信息訪問請求。

在 BMQ 擁有優(yōu)越的消費(fèi)性能上也需要強(qiáng)大的分布式存儲系統(tǒng)的加持。除了上一節(jié)提到的高性能的元數(shù)據(jù)節(jié)點(diǎn)，也需要存儲系統(tǒng)支持讀取的慢節(jié)點(diǎn)檢測，即如果當(dāng)前讀取的節(jié)點(diǎn)延時較高，Client 端會自動切換另外一個節(jié)點(diǎn)讀取。再加上 NVMe 分層存儲的加速，BMQ 可以以較低延時達(dá)到非常理想的消費(fèi)吞吐。

總結(jié)與展望

總體來看，分層架構(gòu)給 BMQ 帶來了極大的性能收益及可運(yùn)維性的提升，同時也給我們帶了來很多的挑戰(zhàn)。BMQ 也通過不停的探索和優(yōu)化，成功克服了這些困難，很好的支撐了業(yè)務(wù)的發(fā)展。在線上實(shí)踐中，目前我們承接了 TB/s 級別的入流及數(shù)十 TB/s 級別的的峰值吞吐，其中最大 Topic 峰值達(dá)到數(shù)百 GB/s 入流和 TB/s 級別的出流吞吐。

當(dāng)然，我們也在思考如何在各種場景下持續(xù)優(yōu)化云原生消息引擎能力為用戶帶來更加極致的使用體驗(yàn)。對于一些特定的場景，探索將 Proxy 和 Broker 融合，在降低部署成本的同時提供更加極致的讀寫延時體驗(yàn)。未來，我們也將持續(xù)優(yōu)化自動檢測能力，使它更智能、更準(zhǔn)確判斷故障的同時更快地隔離異常節(jié)點(diǎn)，縮短影響時間，持續(xù)為 BMQ 的穩(wěn)定性保駕護(hù)航。此外我們也在探索更加極致的彈性能力，在保障租戶吞吐能力的同時，可以根據(jù)流量潮汐自動擴(kuò)縮容實(shí)例，實(shí)現(xiàn)極致地降本增效。后續(xù)，我們還會介紹更多技術(shù)能力，敬請期待。

火山引擎云原生消息引擎 BMQ 基于云原生全托管服務(wù)，支持靈活動態(tài)的擴(kuò)縮容和流批一體化計(jì)算，能夠有效地處理大數(shù)據(jù)量級的實(shí)時流數(shù)據(jù)，幫助用戶構(gòu)建數(shù)據(jù)處理的“中樞神經(jīng)系統(tǒng)”，廣泛應(yīng)用于日志收集、數(shù)據(jù)聚合、離線數(shù)據(jù)分析等業(yè)務(wù)場景。文章來源地址http://www.zghlxwxcb.cn/news/detail-830342.html

到了這里，關(guān)于字節(jié)跳動新一代云原生消息隊(duì)列實(shí)踐的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！