峰值超2億/秒，Kafka在美團(tuán)數(shù)據(jù)平臺(tái)的實(shí)踐
導(dǎo)讀：本文將介紹Kafka在美團(tuán)數(shù)據(jù)平臺(tái)的實(shí)踐，主要內(nèi)容包括：① Kafka在美團(tuán)數(shù)據(jù)平臺(tái)的發(fā)展現(xiàn)狀和面臨的挑戰(zhàn)，主要是海量數(shù)據(jù)下如何保證讀寫(xiě)延遲的問(wèn)題，以及大規(guī)模的集群管理與優(yōu)化；② 面對(duì)上述挑戰(zhàn)，美團(tuán)所做的優(yōu)化實(shí)踐；③ 未來(lái)美團(tuán)數(shù)據(jù)平臺(tái)Kafka的優(yōu)化方向。
1. 現(xiàn)狀
首先了解一下Kafka在美團(tuán)數(shù)據(jù)平臺(tái)的現(xiàn)狀。
如圖1-1所示，藍(lán)色部分描述了Kafka在數(shù)據(jù)平臺(tái)定位為數(shù)據(jù)存儲(chǔ)層。主要的職責(zé)是做數(shù)據(jù)的緩存和分發(fā)，它會(huì)將收集到的binlog日志分發(fā)到不同的數(shù)據(jù)系統(tǒng)里，這些日志來(lái)源于業(yè)務(wù)日志、用戶(hù)行為日志以及業(yè)務(wù)的數(shù)據(jù)庫(kù)。這里的數(shù)據(jù)系統(tǒng)包括通過(guò)ODS入倉(cāng)提供離線計(jì)算使用、直接供實(shí)時(shí)計(jì)算使用、通過(guò)DataLink同步到日志中心，以及OLAP做分析使用。
Kafka在美團(tuán)的集群規(guī)?？傮w機(jī)器數(shù)已經(jīng)超過(guò)了7500臺(tái)，單集群的最大機(jī)器數(shù)也已經(jīng)到了1500臺(tái)。數(shù)據(jù)規(guī)模上，天級(jí)消息量已經(jīng)超過(guò)了21P，天級(jí)的消息條數(shù)達(dá)到了11.3萬(wàn)億，天級(jí)消息量峰值也達(dá)到了2.46億/秒。
隨著集群規(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)可以概括為兩部分：
第一部分是慢節(jié)點(diǎn)影響讀寫(xiě)，這里慢節(jié)點(diǎn)參考了HDFS的一個(gè)概念，具體定義指的是讀寫(xiě)延遲tp99大于300ms的broker。影響慢節(jié)點(diǎn)的原因有三個(gè)，第一個(gè)是集群負(fù)載不均衡會(huì)導(dǎo)致局部熱點(diǎn)，就是整個(gè)集群的磁盤(pán)空間很充?；蛘遡outil很低，但部分磁盤(pán)即將寫(xiě)滿(mǎn)或者ioutil打滿(mǎn)；第二個(gè)是pagecache容量不足會(huì)導(dǎo)致磁盤(pán)IO瓶頸。比如說(shuō)，80GB的pagecache在170MB/s的寫(xiě)入量下僅能緩存8分鐘的數(shù)據(jù)量。那么如果消費(fèi)的數(shù)據(jù)是8分鐘前的數(shù)據(jù)，就有可能觸發(fā)磁盤(pán)讀；第三個(gè)是consumer線程模型缺陷會(huì)導(dǎo)致延時(shí)指標(biāo)的失真。例如當(dāng)消費(fèi)的分區(qū)處于同一broker時(shí)，tp90可能小于100ms，但是當(dāng)他們處于不同broker時(shí)，tp90可能會(huì)大于100ms。
第二部分是大規(guī)模集群運(yùn)維的復(fù)雜性，具體表現(xiàn)有四個(gè)方面，一是不同topic之間會(huì)相互影響，某些或某個(gè)topic的流量突增，或者某些消費(fèi)者的回溯讀會(huì)影響整體集群的穩(wěn)定性；二是Kafka原生的broker粒度的指標(biāo)不夠健全，問(wèn)題的根因分析變得很困難；三是故障的感知無(wú)法做到及時(shí)，故障處理成本很高；四是Rack級(jí)別的故障會(huì)造成部分分區(qū)不可用。
接下來(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資源隔離等，下面具體來(lái)看一下各種優(yōu)化方案是如何實(shí)現(xiàn)的。
1.?概覽
圖2-1 Kafka概覽圖
如圖2-1，這張圖是針對(duì)讀寫(xiě)延遲碰到的問(wèn)題，以及對(duì)應(yīng)優(yōu)化方案的一個(gè)概覽圖。我們把整個(gè)受影響的因素分為應(yīng)用層和系統(tǒng)層。
應(yīng)用層，主要表現(xiàn)在系統(tǒng)設(shè)計(jì)的不合理導(dǎo)致，包括消費(fèi)者端的單線程模型存在缺陷導(dǎo)致運(yùn)維指標(biāo)失真，并且單consumer消費(fèi)的分區(qū)數(shù)是不受限制的，當(dāng)消費(fèi)的分區(qū)數(shù)增多的時(shí)候可能會(huì)引起回溯讀，因?yàn)橄M(fèi)能力不足就無(wú)法跟上實(shí)時(shí)最新的數(shù)據(jù)；其次是broker端，broker端主要表現(xiàn)在負(fù)載不均衡上，具體表現(xiàn)是磁盤(pán)使用率不均衡方面。
我們針對(duì)此做了磁盤(pán)均衡，但磁盤(pán)均衡需要使用分區(qū)遷移，分區(qū)遷移又引入了一些新的問(wèn)題，包括遷移只能按批提交，這存在長(zhǎng)尾問(wèn)題，以及遷移fetcher和實(shí)時(shí)拉取fetcher存在資源競(jìng)爭(zhēng)，分區(qū)遷移的fetcher會(huì)影響實(shí)時(shí)消費(fèi)。
系統(tǒng)層，主要包括三個(gè)方面，一是pagecache的容量不足會(huì)導(dǎo)致磁盤(pán)讀寫(xiě)，磁盤(pán)讀寫(xiě)的性能顯著慢于內(nèi)存，而且容量不足時(shí)還會(huì)導(dǎo)致pagecache污染，pagecache污染后，磁盤(pán)讀和回溯讀會(huì)影響實(shí)時(shí)讀；另一方面，Kafka目前使用的disk主要是HDD，HDD是比較符合順序讀寫(xiě)的場(chǎng)景。但是對(duì)于隨機(jī)讀寫(xiě)的場(chǎng)景，它的性能是不足的；最后由于CPU的資源競(jìng)爭(zhēng)，在美團(tuán)這邊為了提高資源的利用率，IO密集型的服務(wù)（比如Kafka）會(huì)和CPU密集型的服務(wù)（比如實(shí)時(shí)作業(yè)）混布，混布其實(shí)是存在資源競(jìng)爭(zhēng)的，也會(huì)影響讀寫(xiě)的延遲。
針對(duì)剛才提到的應(yīng)用層和系統(tǒng)層存在的各種問(wèn)題，我們這邊分層的去解決。對(duì)于應(yīng)用層提到的每一點(diǎn)問(wèn)題都會(huì)有針對(duì)性的解決方案，比如說(shuō)限流、流水線加速、資源隔離等。針對(duì)系統(tǒng)層存在的問(wèn)題，我們做了cgroup的優(yōu)化以及物理核的隔離來(lái)保證當(dāng)CPU實(shí)時(shí)計(jì)算的飆升時(shí)不會(huì)影響讀寫(xiě)延遲。
2.?應(yīng)用層
① 磁盤(pán)均衡
圖2-2 Kafka應(yīng)用層磁盤(pán)均衡
下面介紹一下讀寫(xiě)延遲在應(yīng)用層遇到到的問(wèn)題，磁盤(pán)熱點(diǎn)導(dǎo)致磁盤(pán)利用率不均衡，它會(huì)帶來(lái)兩個(gè)問(wèn)題：
磁盤(pán)實(shí)時(shí)讀寫(xiě)延遲變高，比如說(shuō)tp99超過(guò)300ms就已經(jīng)造成慢節(jié)點(diǎn)了；
集群整體利用率不足，雖然集群容量非常充裕，但是部分磁盤(pán)已經(jīng)寫(xiě)滿(mǎn)，這個(gè)時(shí)候甚至?xí)?dǎo)致某些分區(qū)暫時(shí)中斷服務(wù)。
針對(duì)這兩個(gè)問(wèn)題我們做了基于空閑磁盤(pán)優(yōu)先這樣一個(gè)分區(qū)遷移計(jì)算計(jì)劃，整個(gè)計(jì)劃分為5個(gè)點(diǎn)。如圖2-2 所示，首先會(huì)有一個(gè)組件叫rebalancer，rebalancer通過(guò)目標(biāo)的使用率和Kafka monitor組件不斷從Kafka broker集群上報(bào)上來(lái)的當(dāng)前磁盤(pán)的使用狀況這兩類(lèi)指標(biāo)持續(xù)生成具體的分區(qū)遷移計(jì)劃，執(zhí)行遷移計(jì)劃并檢查進(jìn)度；然后rebalancer會(huì)向zookeeper的reassign節(jié)點(diǎn)提交剛才生成的遷移計(jì)劃，Kafka的controller收到這個(gè)reassign事件之后會(huì)向整個(gè)Kafka broker集群提交reassign事件，然后Kafka broker集群讓整體磁盤(pán)利用率趨于均衡值這樣一個(gè)目標(biāo)執(zhí)行磁盤(pán)遷移計(jì)劃。
如圖2-2所示，對(duì)于所有的disk，三個(gè)分區(qū)屬于一個(gè)相對(duì)均衡的狀態(tài)，那么如果有一個(gè)四個(gè)分區(qū)的disk，就會(huì)把其中一個(gè)分區(qū)遷移到另外兩個(gè)分區(qū)的disk上，最終盡可能地保證整體磁盤(pán)利用率是均衡的。但是Kafka的分區(qū)遷移只能是按組提交的，在執(zhí)行分區(qū)遷移過(guò)程中碰到了許多新的問(wèn)題，下面會(huì)繼續(xù)介紹這些問(wèn)題是怎么解決的。
分區(qū)遷移存在一個(gè)遷移效率不足的問(wèn)題，因?yàn)槭前唇M提交的，在上一批沒(méi)有完成之前，下一批無(wú)法開(kāi)始提交，這樣就會(huì)導(dǎo)致整體遷移進(jìn)度受阻，進(jìn)而對(duì)讀寫(xiě)請(qǐng)求造成影響。
針對(duì)遷移效率問(wèn)題以及帶來(lái)的它帶來(lái)的影響，我們主要做了三點(diǎn)改進(jìn)：第一點(diǎn)是做流水線加速，流水線加速能夠保證長(zhǎng)尾分區(qū)不影響整體遷移進(jìn)度；第二點(diǎn)是遷移取消，在原生Kafka版本中，當(dāng)一個(gè)分區(qū)遷移被提交后，是無(wú)法中斷的，只能等他遷移完成，那么如果他在影響一個(gè)實(shí)時(shí)讀寫(xiě)請(qǐng)求的時(shí)候，如果它遲遲不能完成，可能另一個(gè)實(shí)時(shí)讀寫(xiě)的請(qǐng)求一直都會(huì)受到影響；第三點(diǎn)是做fetcher隔離，Kafka在做分區(qū)遷移的時(shí)候會(huì)利用follower通過(guò)最近讀去拉數(shù)據(jù)同步，當(dāng)發(fā)起最近讀的遷移請(qǐng)求和某一個(gè)實(shí)時(shí)寫(xiě)請(qǐng)求共享同一個(gè)fetcher的時(shí)候，遷移分區(qū)的讀請(qǐng)求會(huì)影響實(shí)時(shí)分區(qū)的讀請(qǐng)求，后面會(huì)進(jìn)一步詳細(xì)描述具體的問(wèn)題和對(duì)應(yīng)的解決方案。
② 遷移優(yōu)化
優(yōu)化一，流水線加速
圖2-3 流水線加速
針對(duì)長(zhǎng)尾分區(qū)問(wèn)題，我們主要是做了流水線加速，如圖2-3所示，箭頭以上原生Kafka版本只支持按組提交，比如說(shuō)一批提交了四個(gè)分區(qū)，當(dāng)tp4這個(gè)分區(qū)一直卡著無(wú)法完成的時(shí)候，后續(xù)所有分區(qū)都無(wú)法繼續(xù)進(jìn)行。采用流水線加速之后，即使tp4這個(gè)分區(qū)還沒(méi)有完成，當(dāng)其它三個(gè)分區(qū)已經(jīng)完成的時(shí)候，后續(xù)就可以繼續(xù)提交新的分區(qū)?？梢钥闯鲈谙嗤臅r(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 遷移取消
如圖2-4所示，箭頭左側(cè)描述了因?yàn)檫w移影響的三種線上類(lèi)型。第一種是因?yàn)檫w移會(huì)觸發(fā)最舊讀，同步大量的數(shù)據(jù)，在這個(gè)過(guò)程中會(huì)首先將數(shù)據(jù)回刷到pagecache上，那么可能會(huì)污染pagecache，進(jìn)而導(dǎo)致某個(gè)實(shí)時(shí)讀的分區(qū)發(fā)生cache miss，就會(huì)導(dǎo)致實(shí)時(shí)讀觸發(fā)磁盤(pán)度進(jìn)而影響讀寫(xiě)請(qǐng)求；第二類(lèi)和第三類(lèi)分別描述的是當(dāng)存在某些異常節(jié)點(diǎn)導(dǎo)致遷移hang住的時(shí)候，想對(duì)topic做某些操作，比如對(duì)topic擴(kuò)容，例如在午高峰時(shí)由于流量上漲想對(duì)topic擴(kuò)容，實(shí)際上這個(gè)時(shí)候擴(kuò)容是無(wú)法完成的。因?yàn)樵贙afka遷移過(guò)程中這些操作都被限制住。第三個(gè)和第二個(gè)有些類(lèi)似，它的主要問(wèn)題是當(dāng)目標(biāo)節(jié)點(diǎn)掛了，這個(gè)時(shí)候topic擴(kuò)容也是無(wú)法完成的，用戶(hù)可能一直忍受讀寫(xiě)請(qǐng)求受影響，直到遷移完成。針對(duì)這種場(chǎng)景，線上無(wú)法忍受由于長(zhǎng)時(shí)間遷移導(dǎo)致讀寫(xiě)延遲變高的。
針對(duì)上面提到的各種問(wèn)題，我們支持了一個(gè)功能叫遷移取消。當(dāng)遇到這類(lèi)問(wèn)題時(shí)，管理員可以調(diào)用遷移取消命令，中斷正在遷移的分區(qū)，針對(duì)第一種場(chǎng)景，pagecache就不會(huì)被污染，實(shí)時(shí)讀得以保證；在二、三類(lèi)場(chǎng)景中，因?yàn)檫w移取消，擴(kuò)容得以完成。
遷移取消必須要?jiǎng)h除那些還沒(méi)有完成的分區(qū)，大量的刪除會(huì)導(dǎo)致磁盤(pán)IO，稱(chēng)為性能瓶頸進(jìn)而影響讀寫(xiě)，因此在這里我們針對(duì)遷移取消做了平滑刪除，避免因大量刪除影響性能問(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)題我們做的策略叫fetcher隔離。也就是說(shuō)所有isr的follower共享fetcher，所有非isr的follower共享fetcher，這樣就能保證所有isr中的實(shí)時(shí)讀不會(huì)被非isr的回溯讀所影響。
③ Consumer異步化
首先來(lái)了解一下Kafka-broker分階段延時(shí)統(tǒng)計(jì)模型，當(dāng)一個(gè)Kafka的producer或consumer請(qǐng)求進(jìn)入到Kafka-broker時(shí)，首先由processor將請(qǐng)求寫(xiě)入RequestQueue里面，然后RequestHandler就會(huì)從RequestQueue源源不斷地去拉取請(qǐng)求進(jìn)行處理，在RequestQueue中的等待時(shí)間是RequestQueueTime，RequestHandler具體的執(zhí)行時(shí)間為L(zhǎng)ocalTime，當(dāng)RequestHandler執(zhí)行完畢后會(huì)將請(qǐng)求扔到DelayedPurgatory組件中，這個(gè)實(shí)際上就是一個(gè)延時(shí)隊(duì)列。這個(gè)延時(shí)隊(duì)列當(dāng)觸發(fā)某一個(gè)延時(shí)條件完成了以后會(huì)把請(qǐng)求塞到ResponseQueue中，在DelayedPurgatory隊(duì)列持續(xù)的時(shí)間為RemoteTime，processor會(huì)不斷的從ResponseQueue中將數(shù)據(jù)拉取出來(lái)發(fā)往客戶(hù)端，標(biāo)紅的ResponseTime是可能會(huì)被客戶(hù)端影響的，因?yàn)槿绻蛻?hù)端接收能力不足，那么ResponseTime就會(huì)一直持續(xù)增加，從Kafka-broker角度，每一次請(qǐng)求總的延遲叫RequestTotalTime包含了剛才所有流程分階段計(jì)時(shí)總和。
圖2-7?Consumer異步化
主要問(wèn)題是因?yàn)镵afka原生consumer基于NIO的單線程模型存在缺陷。如圖2-7所示，在phase1，user首先在調(diào)用poll請(qǐng)求時(shí)，當(dāng)本地?zé)o數(shù)據(jù)時(shí)，同時(shí)向broker1、broker2和broker3發(fā)送請(qǐng)求，實(shí)際上broker1的數(shù)據(jù)先回來(lái)了，Kafka Client立即將數(shù)據(jù)寫(xiě)入CompleteQueue，這個(gè)時(shí)候立即返回，不會(huì)再拉取broker2和broker3的數(shù)據(jù)，此時(shí)user線程會(huì)直接從CompleteQueue中讀取數(shù)據(jù)，然后直接返回。此時(shí)broker2和broker3服務(wù)端可能已經(jīng)處理好，數(shù)據(jù)已經(jīng)準(zhǔn)備就緒。user線程會(huì)繼續(xù)調(diào)用poll，訪問(wèn)下一批請(qǐng)求，可是因?yàn)镃ompleteQueue依然存在broker1上次拉取的數(shù)據(jù)，這時(shí)user線程直接返回了，這樣就會(huì)導(dǎo)致broker2和broker3中已就緒的數(shù)據(jù)一直得不到拉取。如圖中phase2，因?yàn)閱尉€程模型存在缺陷導(dǎo)致waitFetch這部分時(shí)長(zhǎng)變大，導(dǎo)致Kafka-broker延時(shí)指標(biāo)不斷升高。
針對(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)層
① Raid卡加速
圖2-9 Raid卡加速
眾所周知，Kafka的寫(xiě)入借助了Zero Copy技術(shù)將數(shù)據(jù)直接寫(xiě)入pagecache，但是隨著隨機(jī)讀寫(xiě)并發(fā)量的提升，隨機(jī)寫(xiě)導(dǎo)致的性能不足問(wèn)題就會(huì)顯現(xiàn)出來(lái)。表現(xiàn)是隨機(jī)寫(xiě)入的延時(shí)會(huì)顯著升高，針對(duì)這個(gè)問(wèn)題我們引入了Raid卡。Raid卡有一個(gè)好處是自帶緩存，而且Raid卡使用的是Raid-0模式，并沒(méi)有冗余，與pagecache類(lèi)似，在這一層會(huì)繼續(xù)做merge，把數(shù)據(jù)merge成更大的block寫(xiě)入disk。更加充分利用順序?qū)慔DD的帶寬，借助Raid卡保證了隨機(jī)寫(xiě)的性能是比較穩(wěn)定的。
② cgroup隔離優(yōu)化
圖2-10 cgroup隔離
在介紹cgroup的隔離優(yōu)化之前需要提到的背景是，為了提高資源利用率，美團(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 混合層SSD新緩存架構(gòu)
首先來(lái)了解一下Kafka的數(shù)據(jù)消費(fèi)模型，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污染，自己讀寫(xiě)延遲變慢同時(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-12 SSD新緩存架構(gòu)方案選型
針對(duì)這個(gè)問(wèn)題，我們這邊在做方案選型時(shí)有兩種方案，
方案一，讀磁盤(pán)時(shí)不回寫(xiě)pagecache，比如使用DirectIO，不過(guò)Java并不支持；
方案二，在內(nèi)存和HDD之間引入中間層，比如SDD，如圖2-12所示，隨著讀取并發(fā)的增加，SSD的性能并不會(huì)顯著降低，非常適合我們的使用場(chǎng)景。
圖2-13 SSD新緩存架構(gòu)決策
針對(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)題是局部性原理并不滿(mǎ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-14 SSD新緩存架構(gòu)具體實(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-15 SSD新緩存架構(gòu)細(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)求的處理，向SSD寫(xiě)入數(shù)據(jù)也是需要限速的，因?yàn)镾SD的使用壽命是有限的。
了解了讀寫(xiě)延遲優(yōu)化之后，下面來(lái)看一下Kafka在美團(tuán)數(shù)據(jù)平臺(tái)是如何保證大規(guī)模集群的穩(wěn)定性的。
1.?隔離優(yōu)化
圖3-1 隔離優(yōu)化
由于Kafka服務(wù)于多個(gè)業(yè)務(wù)，這些業(yè)務(wù)的topic混布在一起的話很有可能造成不同業(yè)務(wù)的不同topic之間相互影響。例如broker如果和controller混布在一起，當(dāng)broker負(fù)載明顯變高的時(shí)候，會(huì)導(dǎo)致controller無(wú)法及時(shí)處理請(qǐng)求，從而可能會(huì)造成整個(gè)集群發(fā)生故障，因?yàn)樵獢?shù)據(jù)的變更請(qǐng)求無(wú)法發(fā)送出去。
針對(duì)這些相互影響的問(wèn)題，我們從業(yè)務(wù)、角色和優(yōu)先級(jí)三個(gè)維度來(lái)做隔離優(yōu)化。
第一點(diǎn)是業(yè)務(wù)隔離，如圖3-1所示，每一個(gè)大的業(yè)務(wù)會(huì)有一個(gè)獨(dú)立的kafka集群，比如外賣(mài)、團(tuán)購(gòu)、優(yōu)選；
第二點(diǎn)是分角色隔離，這里Kafka的broker和controller以及他們依賴(lài)的組件zookeeper是部署在不同機(jī)器上的，避免之間相互影響；
第三點(diǎn)是可以分優(yōu)先級(jí)，有的業(yè)務(wù)可能它的topic可用性等級(jí)特別高，那么我們就可以給他劃分為VIP集群，給他更多的資源冗余去保證可用性。
2.?全鏈路監(jiān)控
圖3-2 全鏈路優(yōu)化
隨著集群規(guī)模的增大分區(qū)數(shù)變多，讀寫(xiě)的客戶(hù)端也會(huì)變多，Kafka當(dāng)前提供的broker端粒度的延時(shí)指標(biāo)在很多情況下無(wú)法真實(shí)反映某些客戶(hù)端是否慢，還有一類(lèi)問(wèn)題是當(dāng)集群發(fā)生故障時(shí)，如何能及時(shí)得到感知和處理。
針對(duì)這兩個(gè)問(wèn)題，我們做了全鏈路監(jiān)控這樣一個(gè)項(xiàng)目。把Kafka核心組件以及指標(biāo)全部收集起來(lái)做了一個(gè)全鏈路的追蹤，通過(guò)分析上報(bào)上來(lái)的日志和指標(biāo)，我們就可以建立細(xì)粒度的日志大盤(pán)。當(dāng)某一個(gè)讀寫(xiě)請(qǐng)求變慢時(shí)，我們通過(guò)日志大盤(pán)很容易就知道他具體是慢在哪個(gè)環(huán)節(jié)。日志和指標(biāo)的解析服務(wù)可以自動(dòng)實(shí)時(shí)感知故障還有一些慢節(jié)點(diǎn)，這兩類(lèi)故障有一部分我們可以做到自動(dòng)處理，我們會(huì)把他通過(guò)事件的方式通知到Kafka manager，然后Kafka manager會(huì)根據(jù)這個(gè)事件自動(dòng)去處理這些故障。還有一類(lèi)故障是無(wú)法得到自動(dòng)處理的，比如說(shuō)僵尸節(jié)點(diǎn)，僵尸節(jié)點(diǎn)指的是zookeeper的臨時(shí)節(jié)點(diǎn)還沒(méi)有掉線，但是這個(gè)節(jié)點(diǎn)不管是controller也好還是客戶(hù)端也好，都已經(jīng)無(wú)法訪問(wèn)了，訪問(wèn)就會(huì)報(bào)錯(cuò)或者超時(shí)，這一類(lèi)故障需要人工介入處理，會(huì)直接發(fā)給具體的管理員。
3.?服務(wù)生命周期管理
圖3-3 服務(wù)生命周期管理
首先介紹一下當(dāng)集群規(guī)模增大以后存在的一系列問(wèn)題。之前版本的Kafka也有一套自動(dòng)化運(yùn)維的系統(tǒng)，但是它存在一些問(wèn)題，首先是狀態(tài)語(yǔ)義存在歧義，無(wú)法真實(shí)反映系統(tǒng)狀態(tài)，往往需要借助日志和指標(biāo)去找到真實(shí)系統(tǒng)是否健康或者異常；然后是狀態(tài)不全面，異常case需人工介入處理，誤操作風(fēng)險(xiǎn)極大。
基于這兩點(diǎn)問(wèn)題，我們引入了生命周期管理機(jī)制，保證狀態(tài)能真實(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-4 TOR容災(zāi)-挑戰(zhàn)
最后一個(gè)集群管理優(yōu)化是TOR容災(zāi)。隨著集群規(guī)模的變大，Rack級(jí)別的故障變得平凡起來(lái)，而我們是無(wú)法容忍Rack級(jí)別的故障的，因?yàn)镽ack級(jí)別的故障可能會(huì)導(dǎo)致分區(qū)不可用，原因是分區(qū)的多副本在同一個(gè)rack下，特別是在流存儲(chǔ)環(huán)境下，當(dāng)某些分區(qū)不可用時(shí)，它會(huì)導(dǎo)致收集側(cè)的擁堵，影響其他topic的收集上報(bào)。并且當(dāng)實(shí)時(shí)作業(yè)的某個(gè)分區(qū)出現(xiàn)異常時(shí)，它會(huì)影響整個(gè)鏈路。
如圖3-4所示，當(dāng)rack1發(fā)生故障時(shí)，TopicPartition1是完全不可用的，因?yàn)樗膬蓚€(gè)副本都在rack1上，TopicPartition2也是不可用的，雖然他有三個(gè)副本，但是他的兩個(gè)副本都已經(jīng)不可用了。
圖3-5 TOR容災(zāi)-改進(jìn)
針對(duì)Rack級(jí)別的故障，我們做了TOR容災(zāi)。改進(jìn)了副本的分配算法，保證同一個(gè)分區(qū)的不同副本不在同一個(gè)rack下，如圖3-5所示，即使rack1整個(gè)發(fā)生故障，也能保證所有分區(qū)是可用的。
最后介紹一下美團(tuán)數(shù)據(jù)平臺(tái)的Kafka未來(lái)可以做哪些優(yōu)化：首先我們會(huì)繼續(xù)去做Kafka的高可用建設(shè)，比如說(shuō)客戶(hù)端主動(dòng)去做一些故障節(jié)點(diǎn)的避讓?zhuān)?wù)端通過(guò)多隊(duì)列的方式去隔離一些異常請(qǐng)求，避免它們之間相互影響。另外，高可靠方面會(huì)去做quorum write多數(shù)派寫(xiě)優(yōu)化，因?yàn)镵afka的ack等于1時(shí)是需要寫(xiě)入所有副本的。我們還會(huì)去做流批一體的存儲(chǔ)架構(gòu)，比如Kafka on HDFS。