作者：海源、仕祿、肖恩、鴻洛、啟帆、胡榮、李杰等

Kafka在美團(tuán)數(shù)據(jù)平臺(tái)承擔(dān)著統(tǒng)一的數(shù)據(jù)緩存和分發(fā)的角色，隨著數(shù)據(jù)量的增長(zhǎng)，集群規(guī)模的擴(kuò)大，Kafka面臨的挑戰(zhàn)也愈發(fā)嚴(yán)峻。本文分享了美團(tuán)Kafka面臨的實(shí)際挑戰(zhàn)，以及美團(tuán)針對(duì)性的一些優(yōu)化工作，希望能給從事相關(guān)開(kāi)發(fā)工作的同學(xué)帶來(lái)幫助或啟發(fā)。

一、現(xiàn)狀和挑戰(zhàn)

1、現(xiàn)狀

Kafka是一個(gè)開(kāi)源的流處理平臺(tái)，我們首先了解一下Kafka在美團(tuán)數(shù)據(jù)平臺(tái)的現(xiàn)狀。

圖1-1 Kafka在美團(tuán)數(shù)據(jù)平臺(tái)的現(xiàn)狀

如圖1-1所示，藍(lán)色部分描述了Kafka在數(shù)據(jù)平臺(tái)定位為流存儲(chǔ)層。主要的職責(zé)是做數(shù)據(jù)的緩存和分發(fā)，它會(huì)將收集到的日志分發(fā)到不同的數(shù)據(jù)系統(tǒng)里，這些日志來(lái)源于系統(tǒng)日志、客戶端日志以及業(yè)務(wù)數(shù)據(jù)庫(kù)。下游的數(shù)據(jù)消費(fèi)系統(tǒng)包括通過(guò)ODS入倉(cāng)提供離線計(jì)算使用、直接供實(shí)時(shí)計(jì)算使用、通過(guò)DataLink同步到日志中心，以及做OLAP分析使用。

Kafka在美團(tuán)的集群規(guī)?？傮w機(jī)器數(shù)已經(jīng)超過(guò)了15000+臺(tái)，單集群的最大機(jī)器數(shù)也已經(jīng)到了2000+臺(tái)。在數(shù)據(jù)規(guī)模上，天級(jí)消息量已經(jīng)超過(guò)了30+P，天級(jí)消息量峰值也達(dá)到了4+億/秒。不過(guò)隨著集群規(guī)模的增大，數(shù)據(jù)量的增長(zhǎng)，Kafka面臨的挑戰(zhàn)也愈發(fā)嚴(yán)峻，下面講一下具體的挑戰(zhàn)都有哪些。

2、挑戰(zhàn)

圖1-2 Kafka在美團(tuán)數(shù)據(jù)平臺(tái)面臨的挑戰(zhàn)

如圖1-2所示，具體的挑戰(zhàn)可以概括為兩部分：

1）慢節(jié)點(diǎn)影響讀寫(xiě)，這里慢節(jié)點(diǎn)參考了HDFS的一個(gè)概念，具體定義指的是讀寫(xiě)延遲TP99大于300ms的Broker。造成慢節(jié)點(diǎn)的原因有三個(gè)：

集群負(fù)載不均衡會(huì)導(dǎo)致局部熱點(diǎn)，就是整個(gè)集群的磁盤(pán)空間很充?；蛘遡outil很低，但部分磁盤(pán)即將寫(xiě)滿或者ioutil打滿。

• PageCache容量，比如說(shuō)，80GB的PageCache在170MB/s的寫(xiě)入量下僅能緩存8分鐘的數(shù)據(jù)量。那么如果消費(fèi)的數(shù)據(jù)是8分鐘前的數(shù)據(jù)，就有可能觸發(fā)慢速的磁盤(pán)訪問(wèn)。
• Consumer客戶端的線程模型缺陷會(huì)導(dǎo)致端到端延時(shí)指標(biāo)失真。例如當(dāng)Consumer消費(fèi)的多個(gè)分區(qū)處于同一Broker時(shí)，TP90可能小于100ms，但是當(dāng)多個(gè)分區(qū)處于不同Broker時(shí)，TP90可能會(huì)大于1000ms。

2）大規(guī)模集群管理的復(fù)雜性，具體表現(xiàn)有4類(lèi)問(wèn)題：

• 不同Topic之間會(huì)相互影響，個(gè)別Topic的流量突增，或者個(gè)別消費(fèi)者的回溯讀會(huì)影響整體集群的穩(wěn)定性。
• Kafka原生的Broker粒度指標(biāo)不夠健全，導(dǎo)致問(wèn)題定位和根因分析困難。
• 故障感知不及時(shí)，處理成本較高。
• Rack級(jí)別的故障會(huì)造成部分分區(qū)不可用。

二、讀寫(xiě)延遲優(yōu)化

接下來(lái)我們先介紹一下針對(duì)讀寫(xiě)延遲問(wèn)題，美團(tuán)數(shù)據(jù)平臺(tái)做了哪些優(yōu)化。首先從宏觀層面，我們將受影響因素分為應(yīng)用層和系統(tǒng)層，然后詳細(xì)介紹應(yīng)用層和系統(tǒng)層存在的問(wèn)題，并給出對(duì)應(yīng)的解決方案，包括流水線加速、Fetcher隔離、遷移取消和Cgroup資源隔離等，下面具體介紹各種優(yōu)化方案的實(shí)現(xiàn)。

1、概覽

圖2-1 Kafka讀寫(xiě)延遲優(yōu)化概覽

圖2-1是針對(duì)讀寫(xiě)延遲碰到的問(wèn)題以及對(duì)應(yīng)優(yōu)化方案的概覽圖。我們把受影響的因素分為應(yīng)用層和系統(tǒng)層。

應(yīng)用層主要包括3類(lèi)問(wèn)題：

1）Broker端負(fù)載不均衡，例如磁盤(pán)使用率不均衡、ioutil不均衡等問(wèn)題。個(gè)別磁盤(pán)負(fù)載升高影響整個(gè)Broker的請(qǐng)求受到影響。

2）Broker的數(shù)據(jù)遷移存在效率問(wèn)題和資源競(jìng)爭(zhēng)問(wèn)題。具體來(lái)講，包括以下3個(gè)層面：

• 遷移只能按批次串行提交，每個(gè)批次可能存在少量分區(qū)遷移緩慢，無(wú)法提交下個(gè)批次，導(dǎo)致遷移效率受影響。
• 遷移一般在夜間執(zhí)行，如果遷移拖到了午高峰還未完成，可能會(huì)顯著影響讀寫(xiě)請(qǐng)求。
• 遷移請(qǐng)求和實(shí)時(shí)拉取存在共用Fetcher線程的問(wèn)題導(dǎo)致分區(qū)遷移請(qǐng)求可能會(huì)影響實(shí)時(shí)消費(fèi)請(qǐng)求。

3）Consumer端單線程模型存在缺陷導(dǎo)致運(yùn)維指標(biāo)失真，并且單Consumer消費(fèi)的分區(qū)數(shù)不受限制，消費(fèi)能力不足就無(wú)法跟上實(shí)時(shí)最新的數(shù)據(jù)，當(dāng)消費(fèi)的分區(qū)數(shù)增多時(shí)可能會(huì)引起回溯讀。

系統(tǒng)層也主要包括3類(lèi)問(wèn)題：

1）PageCache污染。Kafka利用內(nèi)核層提供的ZeroCopy技術(shù)提升性能，但是內(nèi)核層無(wú)法區(qū)分實(shí)時(shí)讀寫(xiě)請(qǐng)求和回溯讀請(qǐng)求，導(dǎo)致磁盤(pán)讀可能污染PageCache，影響實(shí)時(shí)讀寫(xiě)。

2）HDD在隨機(jī)讀寫(xiě)負(fù)載下性能差。HDD對(duì)于順序讀寫(xiě)友好，但是面對(duì)混合負(fù)載場(chǎng)景下的隨機(jī)讀寫(xiě)，性能顯著下降。

3）CPU和內(nèi)存等系統(tǒng)資源在混部場(chǎng)景下的資源競(jìng)爭(zhēng)問(wèn)題。在美團(tuán)大數(shù)據(jù)平臺(tái)，為了提高資源的利用率，IO密集型的服務(wù)（比如Kafka）會(huì)和CPU密集型的服務(wù)（比如實(shí)時(shí)計(jì)算作業(yè)）混布，混布存在資源競(jìng)爭(zhēng)，影響讀寫(xiě)延遲。

以上提到的問(wèn)題，我們采取了針對(duì)性的策略。比如應(yīng)用層的磁盤(pán)均衡、遷移流水線加速、支持遷移取消和Consumer異步化等。系統(tǒng)層的Raid卡加速、Cgroup隔離優(yōu)化等。此外，針對(duì)HDD隨機(jī)讀寫(xiě)性能不足的問(wèn)題，我們還設(shè)計(jì)并實(shí)現(xiàn)了基于SSD的緩存架構(gòu)。

2、應(yīng)用層

1）磁盤(pán)均衡

圖2-2 Kafka應(yīng)用層磁盤(pán)均衡

磁盤(pán)熱點(diǎn)導(dǎo)致兩個(gè)問(wèn)題：

• 實(shí)時(shí)讀寫(xiě)延遲變高，比如說(shuō)TP99請(qǐng)求處理時(shí)間超過(guò)300ms可能會(huì)導(dǎo)致實(shí)時(shí)作業(yè)發(fā)生消費(fèi)延遲問(wèn)題，數(shù)據(jù)收集擁堵問(wèn)題等。
• 集群整體利用率不足，雖然集群容量非常充裕，但是部分磁盤(pán)已經(jīng)寫(xiě)滿，這個(gè)時(shí)候甚至?xí)?dǎo)致某些分區(qū)停止服務(wù)。

針對(duì)這兩個(gè)問(wèn)題，我們采用了基于空閑磁盤(pán)優(yōu)先的分區(qū)遷移計(jì)劃，整個(gè)計(jì)劃分為3步，由組件Rebalancer統(tǒng)籌管理：

• 生成遷移計(jì)劃。Rebalancer通過(guò)目標(biāo)磁盤(pán)使用率和當(dāng)前磁盤(pán)使用率（通過(guò)Kafka Monitor上報(bào)）持續(xù)生成具體的分區(qū)遷移計(jì)劃。
• 提交遷移計(jì)劃。Rebalancer向Zookeeper的Reassign節(jié)點(diǎn)提交剛才生成的遷移計(jì)劃，Kafka的Controller收到這個(gè)Reassign事件之后會(huì)向整個(gè)Kafka Broker集群提交Reassign事件。
• 檢查遷移計(jì)劃。Kafka Broker負(fù)責(zé)具體執(zhí)行數(shù)據(jù)遷移任務(wù)，Rebalancer負(fù)責(zé)檢查任務(wù)進(jìn)展。

如圖2-2所示，每塊Disk持有3個(gè)分區(qū)是一個(gè)相對(duì)均衡的狀態(tài)，如果部分Disk持有4個(gè)分區(qū)，比如Broker1-Disk1和Broker4-Disk4；部分Disk持有2個(gè)分區(qū)，比如Broker2-Disk2，Broker3-Disk3，Reblanacer就會(huì)將Broker1-Disk1和Broker4-Disk4上多余的分區(qū)分別遷移到Broker2-Disk2和Broker3-Disk3，最終盡可能地保證整體磁盤(pán)利用率均衡。

2）遷移優(yōu)化

雖然基于空閑磁盤(pán)優(yōu)先的分區(qū)遷移實(shí)現(xiàn)了磁盤(pán)均衡，但是遷移本身仍然存在效率問(wèn)題和資源競(jìng)爭(zhēng)問(wèn)題。接下來(lái)，我們會(huì)詳細(xì)描述我們采取的針對(duì)性策略。

• 采取流水線加速策略優(yōu)化遷移緩慢引起的遷移效率問(wèn)題。
• 支持遷移取消解決長(zhǎng)尾分區(qū)遷移緩慢引起的讀寫(xiě)請(qǐng)求受影響問(wèn)題。
• 采取Fetcher隔離緩解數(shù)據(jù)遷移請(qǐng)求和實(shí)時(shí)讀寫(xiě)請(qǐng)求共用Fetcher線程的問(wèn)題。
• 優(yōu)化一：流水線加速

圖2-3 流水線加速

如圖2-3所示，箭頭以上原生Kafka版本只支持按批提交，比如說(shuō)一批提交了四個(gè)分區(qū)，當(dāng)TP4這個(gè)分區(qū)一直卡著無(wú)法完成的時(shí)候，后續(xù)所有分區(qū)都無(wú)法繼續(xù)進(jìn)行。采用流水線加速之后，即使TP4這個(gè)分區(qū)還沒(méi)有完成，可以繼續(xù)提交新的分區(qū)。在相同的時(shí)間內(nèi)，原有的方案受阻于TP4沒(méi)有完成，后續(xù)所有分區(qū)都沒(méi)辦法完成，在新的方案中，TP4分區(qū)已經(jīng)遷移到TP11分區(qū)了。圖中虛線代表了一個(gè)無(wú)序的時(shí)間窗口，主要用于控制并發(fā)，目的是為了和原有的按組提交的個(gè)數(shù)保持一致，避免過(guò)多的遷移影響讀寫(xiě)請(qǐng)求服務(wù)。

• 優(yōu)化二：遷移取消

圖2-4-1 遷移問(wèn)題

如圖2-4-1所示，箭頭左側(cè)描述了因?yàn)檫w移影響的三種線上類(lèi)型。第一種是因?yàn)檫w移會(huì)觸發(fā)最舊讀，同步大量的數(shù)據(jù)，在這個(gè)過(guò)程中會(huì)首先將數(shù)據(jù)回刷到PageCache上引起PageCache污染，導(dǎo)致某個(gè)實(shí)時(shí)讀的分區(qū)發(fā)生Cache Miss，觸發(fā)磁盤(pán)度進(jìn)而影響讀寫(xiě)請(qǐng)求；第二種是當(dāng)存在某些異常節(jié)點(diǎn)導(dǎo)致遷移Hang住時(shí)，部分運(yùn)維操作無(wú)法執(zhí)行，比如流量上漲觸發(fā)的Topic自動(dòng)擴(kuò)分區(qū)。因?yàn)樵贙afka遷移過(guò)程中這類(lèi)運(yùn)維操作被禁止執(zhí)行。第三種和第二種類(lèi)似，它的主要問(wèn)題是當(dāng)目標(biāo)節(jié)點(diǎn)Crash，Topic擴(kuò)分區(qū)也無(wú)法完成，用戶可能一直忍受讀寫(xiě)請(qǐng)求受影響。

圖2-4-2 遷移取消

針對(duì)上面提到的3種問(wèn)題，我們支持了遷移取消功能。管理員可以調(diào)用遷移取消命令，中斷正在遷移的分區(qū)，針對(duì)第一種場(chǎng)景，PageCache就不會(huì)被污染，實(shí)時(shí)讀得以保證；在第二、三種場(chǎng)景中，因?yàn)檫w移取消，擴(kuò)分區(qū)得以完成。遷移取消會(huì)刪除未完成遷移的分區(qū)，刪除可能會(huì)導(dǎo)致磁盤(pán)IO出現(xiàn)瓶頸影響讀寫(xiě)，因此我們通過(guò)支持平滑刪除避免大量刪除引起的性能問(wèn)題。

• 優(yōu)化三：Fetcher隔離

圖2-5 Fetcher隔離

如圖2-5，綠色代表實(shí)時(shí)讀，紅色代表延時(shí)讀。當(dāng)某一個(gè)Follower的實(shí)時(shí)讀和延時(shí)讀共享同一個(gè)Fetcher時(shí)，延時(shí)讀會(huì)影響實(shí)時(shí)讀。因?yàn)槊恳淮窝訒r(shí)讀的數(shù)據(jù)量是顯著大于實(shí)時(shí)讀的，而且延時(shí)讀容易觸發(fā)磁盤(pán)讀，可能數(shù)據(jù)已經(jīng)不在PageCache中了，顯著地拖慢了Fetcher的拉取效率。

針對(duì)這種問(wèn)題，我們實(shí)施的策略叫Fetcher隔離。也就是說(shuō)所有ISR的Follower共享Fetcher，所有非ISR的Follower共享Fetcher，這樣就能保證所有ISR中的實(shí)時(shí)讀不會(huì)被非ISR的回溯讀所影響。

3）Consumer異步化

圖2-6 Kafka-Broker分階段延時(shí)統(tǒng)計(jì)模型

在講述Consumer異步化前，需要解釋下圖2-6展示的Kafka-Broker分階段延時(shí)統(tǒng)計(jì)模型。Kafka-Broker端是一個(gè)典型的事件驅(qū)動(dòng)架構(gòu)，各組件通過(guò)隊(duì)列通信。請(qǐng)求在不同組件流轉(zhuǎn)時(shí)，會(huì)依次記錄時(shí)間戳，最終就可以統(tǒng)計(jì)出請(qǐng)求在不同階段的執(zhí)行耗時(shí)。

具體來(lái)說(shuō)，當(dāng)一個(gè)Kafka的Producer或Consumer請(qǐng)求進(jìn)入到Kafka-Broker時(shí)，Processor組件將請(qǐng)求寫(xiě)入RequestQueue，RequestHandler從RequestQueue拉取請(qǐng)求進(jìn)行處理，在RequestQueue中的等待時(shí)間是RequestQueueTime，RequestHandler具體的執(zhí)行時(shí)間是LocalTime。當(dāng)RequestHandler執(zhí)行完畢后會(huì)將請(qǐng)求傳遞給DelayedPurgatory組件中，該組件是一個(gè)延時(shí)隊(duì)列。

當(dāng)觸發(fā)某一個(gè)延時(shí)條件完成了以后會(huì)把請(qǐng)求寫(xiě)到ResponseQueue中，在DelayedPurgatory隊(duì)列持續(xù)的時(shí)間為RemoteTime，Processor會(huì)不斷的從ResponseQueue中將數(shù)據(jù)拉取出來(lái)發(fā)往客戶端，標(biāo)紅的ResponseTime是可能會(huì)被客戶端影響的，因?yàn)槿绻蛻舳私邮漳芰Σ蛔?，那么ResponseTime就會(huì)一直持續(xù)增加。從Kafka-Broker的視角，每一次請(qǐng)求總的耗時(shí)RequestTotalTime，包含了剛才所有流程分階段計(jì)時(shí)總和。

圖2-7 Consumer異步化

ResponseTime持續(xù)增加的主要問(wèn)題是因?yàn)镵afka原生Consumer基于NIO的單線程模型存在缺陷。如圖2-7所示，在Phase1，User首先發(fā)起Poll請(qǐng)求，Kafka-Client會(huì)同時(shí)向Broker1、Broker2和Broker3發(fā)送請(qǐng)求，Broker1的數(shù)據(jù)先就緒時(shí)，Kafka Client將數(shù)據(jù)寫(xiě)入CompleteQueue，并立即返回，而不是繼續(xù)拉取Broker2和Broker3的數(shù)據(jù)。后續(xù)的Poll請(qǐng)求會(huì)直接從CompleteQueue中讀取數(shù)據(jù)，然后直接返回，直到CompleteQueue被清空。在CompleteQueue被清空之前，即使Broker2和Broker3的端的數(shù)據(jù)已經(jīng)就緒，也不會(huì)得到及時(shí)拉取。

如圖中Phase2，因?yàn)閱尉€程模型存在缺陷導(dǎo)致WaitFetch這部分時(shí)長(zhǎng)變大，導(dǎo)致Kafka-Broker的RespnseTime延時(shí)指標(biāo)不斷升高，帶來(lái)的問(wèn)題是無(wú)法對(duì)服務(wù)端的處理瓶頸進(jìn)行精準(zhǔn)的監(jiān)控與細(xì)分。

圖2-8 引入異步拉取線程

針對(duì)這個(gè)問(wèn)題，我們的改進(jìn)是引入異步拉取線程。異步拉取線程會(huì)及時(shí)地拉取就緒的數(shù)據(jù)，避免服務(wù)端延時(shí)指標(biāo)受影響，而且原生Kafka并沒(méi)有限制同時(shí)拉取的分區(qū)數(shù)，我們?cè)谶@里做了限速，避免GC和OOM的發(fā)生。異步線程在后臺(tái)持續(xù)不斷地拉取數(shù)據(jù)并放到CompleteQueue中。

3、系統(tǒng)層

1）Raid卡加速

圖2-9 Raid卡加速

HDD存在隨機(jī)寫(xiě)性能不足的問(wèn)題，表現(xiàn)為延時(shí)升高，吞吐降低。針對(duì)這個(gè)問(wèn)題我們引入了Raid卡加速。Raid卡自帶緩存，與PageCache類(lèi)似，在Raid這一層會(huì)把數(shù)據(jù)Merge成更大的Block寫(xiě)入Disk，更加充分利用順序?qū)慔DD的帶寬，借助Raid卡保證了隨機(jī)寫(xiě)性能。

2）Cgroup隔離優(yōu)化

圖2-10 Cgroup隔離

為了提高資源利用率，美團(tuán)數(shù)據(jù)平臺(tái)將IO密集型應(yīng)用和CPU密集型應(yīng)用混合部署。IO密集型應(yīng)用在這里指的就是Kafka，CPU密集型應(yīng)用在這里指的是Flink和Storm。但是原有的隔離策略存在兩個(gè)問(wèn)題：首先是物理核本身會(huì)存在資源競(jìng)爭(zhēng)，在同一個(gè)物理核下，共享的L1Cache和L2Cache都存在競(jìng)爭(zhēng)，當(dāng)實(shí)時(shí)平臺(tái)CPU飆升時(shí)會(huì)導(dǎo)致Kafka讀寫(xiě)延時(shí)受到影響；其次，Kafka的HT跨NUMA，增加內(nèi)存訪問(wèn)耗時(shí)，如圖2-10所示，跨NUMA節(jié)點(diǎn)是通過(guò)QPI去做遠(yuǎn)程訪問(wèn)，而這個(gè)遠(yuǎn)程訪問(wèn)的耗時(shí)是40ns。

針對(duì)這兩個(gè)問(wèn)題，我們改進(jìn)了隔離策略，針對(duì)物理核的資源競(jìng)爭(zhēng)，我們新的混布策略保證Kafka獨(dú)占物理核，也就是說(shuō)在新的隔離策略中，不存在同一個(gè)物理核被Kafka和Flink同時(shí)使用；然后是保證Kafka的所有超線程處于同一側(cè)的NUMA，避免Kafka跨NUMA帶來(lái)的訪問(wèn)延時(shí)。通過(guò)新的隔離策略，Kafka的讀寫(xiě)延時(shí)不再受Flink CPU飆升的影響。

4、混合層-SSD新緩存架構(gòu)

圖2-11 Page污染引起的性能問(wèn)題

1）背景和挑戰(zhàn)

Kafka利用操作系統(tǒng)提供的ZeroCopy技術(shù)處理數(shù)據(jù)讀取請(qǐng)求，PageCache容量充裕時(shí)數(shù)據(jù)直接從PageCache拷貝到網(wǎng)卡，有效降低了讀取延時(shí)。但是實(shí)際上，PageCache的容量往往是不足的，因?yàn)樗粫?huì)超過(guò)一個(gè)機(jī)器的內(nèi)存。容量不足時(shí)，ZeroCopy就會(huì)觸發(fā)磁盤(pán)讀，磁盤(pán)讀不僅顯著變慢，還會(huì)污染PageCache影響其他讀寫(xiě)。

如圖2-11中左半部分所示，當(dāng)一個(gè)延遲消費(fèi)者去拉取數(shù)據(jù)時(shí)，發(fā)現(xiàn)PageCache中沒(méi)有它想要的數(shù)據(jù)，這個(gè)時(shí)候就會(huì)觸發(fā)磁盤(pán)讀。磁盤(pán)讀后會(huì)將數(shù)據(jù)回寫(xiě)到PageCache，導(dǎo)致PageCache污染，延遲消費(fèi)者消費(fèi)延遲變慢的同時(shí)也會(huì)導(dǎo)致另一個(gè)實(shí)時(shí)消費(fèi)受影響。因?yàn)閷?duì)于實(shí)時(shí)消費(fèi)而言，它一直讀的是最新的數(shù)據(jù)，最新的數(shù)據(jù)按正常來(lái)說(shuō)時(shí)不應(yīng)該觸發(fā)磁盤(pán)讀的。

2）選型和決策

針對(duì)這個(gè)問(wèn)題，我們這邊在做方案選型時(shí)提供了兩種方案：

• 方案一，讀磁盤(pán)時(shí)不回寫(xiě)PageCache，比如使用DirectIO，不過(guò)Java并不支持；
• 方案二，在內(nèi)存和HDD之間引入中間層，比如SSD。眾所周知，SSD和HDD相比具備良好的隨機(jī)讀寫(xiě)能力，非常適合我們的使用場(chǎng)景。針對(duì)SSD的方案我們也有兩種選型：

方案一：可以基于操作系統(tǒng)的內(nèi)核實(shí)現(xiàn)，這種方案SSD與HDD存儲(chǔ)空間按照固定大小分塊，并且SSD與HDD建立映射關(guān)系，同時(shí)會(huì)基于數(shù)據(jù)局部性原理，Cache Miss后數(shù)據(jù)會(huì)按LRU和LFU替換SSD中部分?jǐn)?shù)據(jù)，業(yè)界典型方案包括OpenCAS和FlashCache。其優(yōu)勢(shì)是數(shù)據(jù)路由對(duì)應(yīng)用層透明，對(duì)應(yīng)用代碼改動(dòng)量小，并且社區(qū)活躍可用性好；但是問(wèn)題在于局部性原理并不滿足Kafka的讀寫(xiě)特性，而且緩存空間污染問(wèn)題并未得到根本解決，因?yàn)樗鼤?huì)根據(jù)LRU和LFU去替換SSD中的部分?jǐn)?shù)據(jù)。

方案二：基于Kafka的應(yīng)用層去實(shí)現(xiàn)，具體就是Kafka的數(shù)據(jù)按照時(shí)間維度存儲(chǔ)在不同設(shè)備上，對(duì)于近實(shí)時(shí)數(shù)據(jù)直接放在SSD上，針對(duì)較為久遠(yuǎn)的數(shù)據(jù)直接放在HDD上，然后Leader直接根據(jù)Offset從對(duì)應(yīng)設(shè)備讀取數(shù)據(jù)。這種方案的優(yōu)勢(shì)是它的緩存策略充分考慮了Kafka的讀寫(xiě)特性，確保近實(shí)時(shí)的數(shù)據(jù)消費(fèi)請(qǐng)求全部落在SSD上，保證這部分請(qǐng)求處理的低延遲，同時(shí)從HDD讀取的數(shù)據(jù)不回刷到SSD防止緩存污染，同時(shí)由于每個(gè)日志段都有唯一明確的狀態(tài)，因此每次請(qǐng)求目的明確，不存在因Cache Miss帶來(lái)的額外性能開(kāi)銷(xiāo)。同時(shí)劣勢(shì)也很明顯，需要在Server端代碼上進(jìn)行改進(jìn)，涉及的開(kāi)發(fā)以及測(cè)試的工作量較大。

圖2-13 KafkaSSD新緩存架構(gòu)

3）具體實(shí)現(xiàn)

下面來(lái)介紹一下SSD新緩存架構(gòu)的具體實(shí)現(xiàn)。

• 首先新的緩存架構(gòu)會(huì)將Log內(nèi)的多個(gè)Segment按時(shí)間維度存儲(chǔ)在不同的存儲(chǔ)設(shè)備上。

如圖2-14中的紅圈1，新緩存架構(gòu)數(shù)據(jù)會(huì)有三種典型狀態(tài)，一種叫Only Cache，指的是數(shù)據(jù)剛寫(xiě)進(jìn)SSD，還未同步到HDD上；第2個(gè)是Cached，指數(shù)據(jù)既同步到了HDD也有一部分緩存在SSD上；第三種類(lèi)型叫WithoutCache，指的是同步到了HDD但是SSD中已經(jīng)沒(méi)有緩存了。

• 然后后臺(tái)異步線程持續(xù)地將SSD數(shù)據(jù)同步到HDD上。
• 隨著SSD的持續(xù)寫(xiě)入，當(dāng)存儲(chǔ)空間達(dá)到閾值后，會(huì)按時(shí)間順序刪除距當(dāng)前時(shí)間最久的數(shù)據(jù)，因?yàn)镾SD的數(shù)據(jù)空間有限。
• 副本可根據(jù)可用性要求靈活開(kāi)啟是否寫(xiě)入SSD。
• 從HDD讀取的數(shù)據(jù)是不會(huì)回刷到SSD上的，防止緩存污染。

圖2-14 SSD新緩存架構(gòu)細(xì)節(jié)優(yōu)化

4）細(xì)節(jié)優(yōu)化

介紹了具體實(shí)現(xiàn)之后，再來(lái)看一下細(xì)節(jié)優(yōu)化。

• 首先是關(guān)于日志段同步，就是剛才說(shuō)到的Segment，只同步Inactive的日志段，Inactive指的是現(xiàn)在并沒(méi)有在寫(xiě)的日志段，低成本解決數(shù)據(jù)一致性問(wèn)題。
• 其次是做同步限速優(yōu)化，在SSD向HDD同步時(shí)是需要限速的，同時(shí)保護(hù)了兩種設(shè)備，不會(huì)影響其他IO請(qǐng)求的處理。

三、大規(guī)模集群管理優(yōu)化

1、隔離策略

美團(tuán)大數(shù)據(jù)平臺(tái)的Kafka服務(wù)于多個(gè)業(yè)務(wù)，這些業(yè)務(wù)的Topic混布在一起的話，很有可能造成不同業(yè)務(wù)的不同Topic之間相互影響。此外，如果Controller節(jié)點(diǎn)同時(shí)承擔(dān)數(shù)據(jù)讀寫(xiě)請(qǐng)求，當(dāng)負(fù)載明顯變高時(shí)，Controller可能無(wú)法及時(shí)控制類(lèi)請(qǐng)求，例如元數(shù)據(jù)變更請(qǐng)求，最終可能會(huì)造成整個(gè)集群發(fā)生故障。

針對(duì)這些相互影響的問(wèn)題，我們從業(yè)務(wù)、角色和優(yōu)先級(jí)三個(gè)維度來(lái)做隔離優(yōu)化。

圖3-1 隔離優(yōu)化

• 第一點(diǎn)是業(yè)務(wù)隔離，如圖3-1所示，每一個(gè)大的業(yè)務(wù)會(huì)有一個(gè)獨(dú)立的Kafka集群，比如外賣(mài)、到店、優(yōu)選。
• 第二點(diǎn)是分角色隔離，這里Kafka的Broker和Controller以及它們依賴(lài)的組件Zookeeper是部署在不同機(jī)器上的，避免之間相互影響。
• 第三點(diǎn)是分優(yōu)先級(jí)，有的業(yè)務(wù)Topic可用性等級(jí)特別高，那么我們就可以給它劃分到VIP集群，給它更多的資源冗余去保證其可用性。

2、全鏈路監(jiān)控

隨著集群規(guī)模增長(zhǎng)，集群管理碰到了一系列問(wèn)題，主要包括兩方面：

1）Broker端延時(shí)指標(biāo)無(wú)法及時(shí)反應(yīng)用戶問(wèn)題。

• 隨著請(qǐng)求量的增長(zhǎng)，Kafka當(dāng)前提供的Broker端粒度的TP99甚至TP999延時(shí)指標(biāo)都可能無(wú)法反應(yīng)長(zhǎng)尾延時(shí)。
• Broker端的延時(shí)指標(biāo)不是端到端指標(biāo)，可能無(wú)法反應(yīng)用戶的真實(shí)問(wèn)題。

2）故障感知和處理不及時(shí)。

圖3-2 全鏈路監(jiān)控

針對(duì)這兩個(gè)問(wèn)題，我們采取的策略是全鏈路監(jiān)控。全鏈路監(jiān)控收集和監(jiān)控Kafka核心組件的指標(biāo)和日志。全鏈路監(jiān)控架構(gòu)如圖3-2所示。當(dāng)某一個(gè)客戶端讀寫(xiě)請(qǐng)求變慢時(shí)，我們通過(guò)全鏈路監(jiān)控可以快速定位到具體慢在哪個(gè)環(huán)節(jié)，全鏈路指標(biāo)監(jiān)控如圖3-3所示。

圖3-3 全鏈路指標(biāo)監(jiān)控

圖3-4是一個(gè)根據(jù)全鏈路指標(biāo)定位請(qǐng)求瓶頸的示例，可以看出服務(wù)端RemoteTime占比最高，這說(shuō)明耗時(shí)主要花費(fèi)在數(shù)據(jù)復(fù)制。日志和指標(biāo)的解析服務(wù)可以自動(dòng)實(shí)時(shí)感知故障和慢節(jié)點(diǎn)，大部分的故障（內(nèi)存、磁盤(pán)、Raid卡以及網(wǎng)卡等）和慢節(jié)點(diǎn)都已經(jīng)支持自動(dòng)化處理，還有一類(lèi)故障是計(jì)劃外的故障，比如分區(qū)多個(gè)副本掛掉導(dǎo)致的不可用，遷移Hang住以及非預(yù)期的錯(cuò)誤日志等，需要人工介入處理。

圖3-4 全鏈路監(jiān)控指標(biāo)示例

3、服務(wù)生命周期管理

圖3-5 服務(wù)生命周期管理

美團(tuán)線上Kafka的服務(wù)器規(guī)模在萬(wàn)級(jí)別，隨著服務(wù)規(guī)模的增長(zhǎng)，我們對(duì)服務(wù)和機(jī)器本身的管理，也在不斷迭代。我們的自動(dòng)化運(yùn)維系統(tǒng)能夠處理大部分的機(jī)器故障和服務(wù)慢節(jié)點(diǎn)，但對(duì)于機(jī)器和服務(wù)本身的管理是割裂的，導(dǎo)致存在兩類(lèi)問(wèn)題：

• 狀態(tài)語(yǔ)義存在歧義，無(wú)法真實(shí)反映系統(tǒng)狀態(tài)，往往需要借助日志和指標(biāo)去找到真實(shí)系統(tǒng)是否健康或者異常。
• 狀態(tài)不全面，異常Case需人工介入處理，誤操作風(fēng)險(xiǎn)極大。

為了解決這兩類(lèi)問(wèn)題，我們引入了生命周期管理機(jī)制，確保能夠真實(shí)反映系統(tǒng)狀態(tài)。生命周期管理指的是從服務(wù)開(kāi)始運(yùn)行到機(jī)器報(bào)廢停止服務(wù)的全流程管理，并且做到了服務(wù)狀態(tài)和機(jī)器狀態(tài)聯(lián)動(dòng)，無(wú)需人工同步變更。而且新的生命周期管理機(jī)制的狀態(tài)變更由特定的自動(dòng)化運(yùn)維觸發(fā)，禁止人工變更。

4、TOR容災(zāi)

圖3-6 TOR容災(zāi)挑戰(zhàn)

我們從工程實(shí)現(xiàn)的角度，歸納總結(jié)了當(dāng)前主流圖神經(jīng)網(wǎng)絡(luò)模型的基本范式，實(shí)現(xiàn)一套通用框架，以期涵蓋多種GNN模型。以下按照?qǐng)D的類(lèi)型（同質(zhì)圖、異質(zhì)圖和動(dòng)態(tài)圖）分別討論。

圖3-7 TOR容災(zāi)

TOR容災(zāi)保證同一個(gè)分區(qū)的不同副本不在同一個(gè)Rack下，如圖3-7所示，即使Rack1整個(gè)發(fā)生故障，也能保證所有分區(qū)可用。

四、未來(lái)展望

過(guò)去一段時(shí)間，我們圍繞降低服務(wù)端的讀寫(xiě)延遲做了大量的優(yōu)化，但是在服務(wù)高可用方面，依然有一些工作需要完成。未來(lái)一段時(shí)間，我們會(huì)將重心放在提升魯棒性和通過(guò)各種粒度的隔離機(jī)制縮小故障域。比如，讓客戶端主動(dòng)對(duì)一些故障節(jié)點(diǎn)進(jìn)行避讓?zhuān)诜?wù)端通過(guò)多隊(duì)列的方式隔離異常請(qǐng)求，支持服務(wù)端熱下盤(pán)，網(wǎng)絡(luò)層主動(dòng)反壓與限流等等。

另外，隨著美團(tuán)實(shí)時(shí)計(jì)算業(yè)務(wù)整體的發(fā)展，實(shí)時(shí)計(jì)算引擎（典型如Flink）和流存儲(chǔ)引擎（典型如Kafka）混合部署的模式越來(lái)越難以滿足業(yè)務(wù)的需求。因此，我們需要在保持當(dāng)前成本不變的情況下對(duì)Kafka進(jìn)行獨(dú)立部署。這就意味著需要用更少的機(jī)器（在我們的業(yè)務(wù)模式下，用原來(lái)1/4的機(jī)器）來(lái)承載不變的業(yè)務(wù)流量。如何在保障服務(wù)穩(wěn)定的情況下，用更少的機(jī)器扛起業(yè)務(wù)請(qǐng)求，也是我們面臨的挑戰(zhàn)之一。

最后，隨著云原生趨勢(shì)的來(lái)臨，我們也在探索流存儲(chǔ)服務(wù)的上云之路。