作者：海源、仕祿、肖恩等

Kafka在美團(tuán)數(shù)據(jù)平臺(tái)承擔(dān)著統(tǒng)一的數(shù)據(jù)緩存和分發(fā)的角色，隨著數(shù)據(jù)量的增長，集群規(guī)模的擴(kuò)大，Kafka面臨的挑戰(zhàn)也愈發(fā)嚴(yán)峻。

1. 現(xiàn)狀和挑戰(zhàn)

1.1 現(xiàn)狀

Kafka是一個(gè)開源的流處理平臺(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)里，這些日志來源于系統(tǒng)日志、客戶端日志以及業(yè)務(wù)數(shù)據(jù)庫。下游的數(shù)據(jù)消費(fèi)系統(tǒng)包括通過ODS入倉提供離線計(jì)算使用、直接供實(shí)時(shí)計(jì)算使用、通過DataLink同步到日志中心，以及做OLAP分析使用。

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

1.2 挑戰(zhàn)

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

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

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

1. 集群負(fù)載不均衡會(huì)導(dǎo)致局部熱點(diǎn)，就是整個(gè)集群的磁盤空間很充裕或者ioutil很低，但部分磁盤即將寫滿或者ioutil打滿。
2. PageCache容量，比如說，80GB的PageCache在170MB/s的寫入量下僅能緩存8分鐘的數(shù)據(jù)量。那么如果消費(fèi)的數(shù)據(jù)是8分鐘前的數(shù)據(jù)，就有可能觸發(fā)慢速的磁盤訪問。
3. 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。

第二部分是大規(guī)模集群管理的復(fù)雜性，具體表現(xiàn)有4類問題：

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

2. 讀寫延遲優(yōu)化

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

2.1 概覽

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

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

應(yīng)用層主要包括3類問題：

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

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

• 遷移只能按批次串行提交，每個(gè)批次可能存在少量分區(qū)遷移緩慢，無法提交下個(gè)批次，導(dǎo)致遷移效率受影響。
• 遷移一般在夜間執(zhí)行，如果遷移拖到了午高峰還未完成，可能會(huì)顯著影響讀寫請(qǐng)求。
• 遷移請(qǐng)求和實(shí)時(shí)拉取存在共用Fetcher線程的問題導(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)能力不足就無法跟上實(shí)時(shí)最新的數(shù)據(jù)，當(dāng)消費(fèi)的分區(qū)數(shù)增多時(shí)可能會(huì)引起回溯讀。

系統(tǒng)層也主要包括3類問題：

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

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

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

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

2.2 應(yīng)用層

① 磁盤均衡

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

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

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

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

1. 生成遷移計(jì)劃。Rebalancer通過目標(biāo)磁盤使用率和當(dāng)前磁盤使用率（通過Kafka Monitor上報(bào)）持續(xù)生成具體的分區(qū)遷移計(jì)劃。
2. 提交遷移計(jì)劃。Rebalancer向Zookeeper的Reassign節(jié)點(diǎn)提交剛才生成的遷移計(jì)劃，Kafka的Controller收到這個(gè)Reassign事件之后會(huì)向整個(gè)Kafka Broker集群提交Reassign事件。
3. 檢查遷移計(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，最終盡可能地保證整體磁盤利用率均衡。

② 遷移優(yōu)化

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

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

優(yōu)化一，流水線加速

圖2-3 流水線加速

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

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

圖2-4-1 遷移問題

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

圖2-4-2 遷移取消

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

優(yōu)化三，F(xiàn)etcher隔離

圖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ā)磁盤讀，可能數(shù)據(jù)已經(jīng)不在PageCache中了，顯著地拖慢了Fetcher的拉取效率。針對(duì)這種問題，我們實(shí)施的策略叫Fetcher隔離。也就是說所有ISR的Follower共享Fetcher，所有非ISR的Follower共享Fetcher，這樣就能保證所有ISR中的實(shí)時(shí)讀不會(huì)被非ISR的回溯讀所影響。

③ 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)，各組件通過隊(duì)列通信。請(qǐng)求在不同組件流轉(zhuǎn)時(shí)，會(huì)依次記錄時(shí)間戳，最終就可以統(tǒng)計(jì)出請(qǐng)求在不同階段的執(zhí)行耗時(shí)。

具體來說，當(dāng)一個(gè)Kafka的Producer或Consumer請(qǐng)求進(jìn)入到Kafka-Broker時(shí)，Processor組件將請(qǐng)求寫入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)求寫到ResponseQueue中，在DelayedPurgatory隊(duì)列持續(xù)的時(shí)間為RemoteTime，Processor會(huì)不斷的從ResponseQueue中將數(shù)據(jù)拉取出來發(fā)往客戶端，標(biāo)紅的ResponseTime是可能會(huì)被客戶端影響的，因?yàn)槿绻蛻舳私邮漳芰Σ蛔悖敲碦esponseTime就會(huì)一直持續(xù)增加。從Kafka-Broker的視角，每一次請(qǐng)求總的耗時(shí)時(shí)RequestTotalTime，包含了剛才所有流程分階段計(jì)時(shí)總和。

圖2-7 Consumer異步化

ResponseTime持續(xù)增加的主要問題是因?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ù)寫入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í)長變大，導(dǎo)致Kafka-Broker的RespnseTime延時(shí)指標(biāo)不斷升高，帶來的問題是無法對(duì)服務(wù)端的處理瓶頸進(jìn)行精準(zhǔn)的監(jiān)控與細(xì)分。

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

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

2.3 系統(tǒng)層

① Raid卡加速

圖2-9 Raid卡加速

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

② 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è)問題：首先是物理核本身會(huì)存在資源競爭，在同一個(gè)物理核下，共享的L1Cache和L2Cache都存在競爭，當(dāng)實(shí)時(shí)平臺(tái)CPU飆升時(shí)會(huì)導(dǎo)致Kafka讀寫延時(shí)受到影響；其次，Kafka的HT跨NUMA，增加內(nèi)存訪問耗時(shí)，如圖2-10所示，跨NUMA節(jié)點(diǎn)是通過QPI去做遠(yuǎn)程訪問，而這個(gè)遠(yuǎn)程訪問的耗時(shí)是40ns。

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

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

圖2-11 Page污染引起的性能問題

背景和挑戰(zhàn)

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

如圖2-11中左半部分所示，當(dāng)一個(gè)延遲消費(fèi)者去拉取數(shù)據(jù)時(shí)，發(fā)現(xiàn)PageCache中沒有它想要的數(shù)據(jù)，這個(gè)時(shí)候就會(huì)觸發(fā)磁盤讀。磁盤讀后會(huì)將數(shù)據(jù)回寫到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ù)按正常來說時(shí)不應(yīng)該觸發(fā)磁盤讀的。

選型和決策

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

方案一，讀磁盤時(shí)不回寫PageCache，比如使用DirectIO，不過Java并不支持；

方案二，在內(nèi)存和HDD之間引入中間層，比如SSD。眾所周知，SSD和HDD相比具備良好的隨機(jī)讀寫能力，非常適合我們的使用場景。針對(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ù)據(jù)路由對(duì)應(yīng)用層透明，對(duì)應(yīng)用代碼改動(dòng)量小，并且社區(qū)活躍可用性好；但是問題在于局部性原理并不滿足Kafka的讀寫特性，而且緩存空間污染問題并未得到根本解決，因?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)勢是它的緩存策略充分考慮了Kafka的讀寫特性，確保近實(shí)時(shí)的數(shù)據(jù)消費(fèi)請(qǐng)求全部落在SSD上，保證這部分請(qǐng)求處理的低延遲，同時(shí)從HDD讀取的數(shù)據(jù)不回刷到SSD防止緩存污染，同時(shí)由于每個(gè)日志段都有唯一明確的狀態(tài)，因此每次請(qǐng)求目的明確，不存在因Cache Miss帶來的額外性能開銷。同時(shí)劣勢也很明顯，需要在Server端代碼上進(jìn)行改進(jìn)，涉及的開發(fā)以及測試的工作量較大。

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

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

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

1. 首先新的緩存架構(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ù)剛寫進(jìn)SSD，還未同步到HDD上；第2個(gè)是Cached，指數(shù)據(jù)既同步到了HDD也有一部分緩存在SSD上；第三種類型叫WithoutCache，指的是同步到了HDD但是SSD中已經(jīng)沒有緩存了。
2. 然后后臺(tái)異步線程持續(xù)地將SSD數(shù)據(jù)同步到HDD上。
3. 隨著SSD的持續(xù)寫入，當(dāng)存儲(chǔ)空間達(dá)到閾值后，會(huì)按時(shí)間順序刪除距當(dāng)前時(shí)間最久的數(shù)據(jù)，因?yàn)镾SD的數(shù)據(jù)空間有限。
4. 副本可根據(jù)可用性要求靈活開啟是否寫入SSD。
5. 從HDD讀取的數(shù)據(jù)是不會(huì)回刷到SSD上的，防止緩存污染。

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

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

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

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

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

3.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ù)讀寫請(qǐng)求，當(dāng)負(fù)載明顯變高時(shí)，Controller可能無法及時(shí)控制類請(qǐng)求，例如元數(shù)據(jù)變更請(qǐng)求，最終可能會(huì)造成整個(gè)集群發(fā)生故障。針對(duì)這些相互影響的問題，我們從業(yè)務(wù)、角色和優(yōu)先級(jí)三個(gè)維度來做隔離優(yōu)化。

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

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

3.2 全鏈路監(jiān)控

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

• Broker端延時(shí)指標(biāo)無法及時(shí)反應(yīng)用戶問題。

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

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

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

針對(duì)這兩個(gè)問題，我們采取的策略是全鏈路監(jiān)控。全鏈路監(jiān)控收集和監(jiān)控Kafka核心組件的指標(biāo)和日志。全鏈路監(jiān)控架構(gòu)如圖3-2所示。當(dāng)某一個(gè)客戶端讀寫請(qǐng)求變慢時(shí)，我們通過全鏈路監(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占比最高，這說明耗時(shí)主要花費(fèi)在數(shù)據(jù)復(fù)制。日志和指標(biāo)的解析服務(wù)可以自動(dòng)實(shí)時(shí)感知故障和慢節(jié)點(diǎn)，大部分的故障（內(nèi)存、磁盤、Raid卡以及網(wǎng)卡等）和慢節(jié)點(diǎn)都已經(jīng)支持自動(dòng)化處理，還有一類故障是計(jì)劃外的故障，比如分區(qū)多個(gè)副本掛掉導(dǎo)致的不可用，遷移Hang住以及非預(yù)期的錯(cuò)誤日志等，需要人工介入處理。

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

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

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

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

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

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

3.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的類型（同質(zhì)圖、異質(zhì)圖和動(dòng)態(tài)圖）分別討論。

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

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

4 未來展望

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

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

5 作者簡介

海源、仕祿、肖恩、鴻洛、啟帆、胡榮、李杰等，均來自美團(tuán)數(shù)據(jù)科學(xué)與平臺(tái)部。