峰值超2億/秒，Kafka在美團資料平臺的實踐

導讀：本文將介紹Kafka在美團資料平臺的實踐，主要內容包括：① Kafka在美團資料平臺的發展現狀和麵臨的挑戰，主要是海量資料下如何保證讀寫延遲的問題，以及大規模的叢集管理與最佳化；② 面對上述挑戰，美團所做的最佳化實踐；③ 未來美團資料平臺Kafka的最佳化方向。

1. 現狀

首先了解一下Kafka在美團資料平臺的現狀。

如圖1-1所示，藍色部分描述了Kafka在資料平臺定位為資料儲存層。主要的職責是做資料的快取和分發，它會將收集到的binlog日誌分發到不同的資料系統裡，這些日誌來源於業務日誌、使用者行為日誌以及業務的資料庫。這裡的資料系統包括透過ODS入倉提供離線計算使用、直接供實時計算使用、透過DataLink同步到日誌中心，以及OLAP做分析使用。

Kafka在美團的叢集規模總體機器數已經超過了7500臺，單叢集的最大機器數也已經到了1500臺。資料規模上，天級訊息量已經超過了21P，天級的訊息條數達到了11.3萬億，天級訊息量峰值也達到了2.46億/秒。

隨著叢集規模的增大，資料量的增長，Kafka面臨的挑戰也是愈發的嚴峻。下面看一下具體的挑戰有哪些。

2. 挑戰

圖1-2 Kafka在美團資料平臺面臨的挑戰

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

第一部分是慢節點影響讀寫，這裡慢節點參考了HDFS的一個概念，具體定義指的是讀寫延遲tp99大於300ms的broker。影響慢節點的原因有三個，第一個是叢集負載不均衡會導致區域性熱點，就是整個叢集的磁碟空間很充裕或者ioutil很低，但部分磁碟即將寫滿或者ioutil打滿；第二個是pagecache容量不足會導致磁碟IO瓶頸。比如說，80GB的pagecache在170MB/s的寫入量下僅能快取8分鐘的資料量。那麼如果消費的資料是8分鐘前的資料，就有可能觸發磁碟讀；第三個是consumer執行緒模型缺陷會導致延時指標的失真。例如當消費的分割槽處於同一broker時，tp90可能小於100ms，但是當他們處於不同broker時，tp90可能會大於100ms。

第二部分是大規模叢集運維的複雜性，具體表現有四個方面，一是不同topic之間會相互影響，某些或某個topic的流量突增，或者某些消費者的回溯讀會影響整體叢集的穩定性；二是Kafka原生的broker粒度的指標不夠健全，問題的根因分析變得很困難；三是故障的感知無法做到及時，故障處理成本很高；四是Rack級別的故障會造成部分分割槽不可用。

接下來介紹一下針對讀寫延遲問題，美團的資料平臺做了哪些最佳化。首先從宏觀上將受影響因素分為應用層和系統層，然後詳細介紹應用層和系統層存在的問題，並給出對應的解決方案，包括流水線加速、fetcher隔離、遷移取消和cgroup資源隔離等，下面具體來看一下各種最佳化方案是如何實現的。

1. 概覽

圖2-1 Kafka概覽圖

如圖2-1，這張圖是針對讀寫延遲碰到的問題，以及對應最佳化方案的一個概覽圖。我們把整個受影響的因素分為應用層和系統層。

應用層，主要表現在系統設計的不合理導致，包括消費者端的單執行緒模型存在缺陷導致運維指標失真，並且單consumer消費的分割槽數是不受限制的，當消費的分割槽數增多的時候可能會引起回溯讀，因為消費能力不足就無法跟上實時最新的資料；其次是broker端，broker端主要表現在負載不均衡上，具體表現是磁碟使用率不均衡方面。

我們針對此做了磁碟均衡，但磁碟均衡需要使用分割槽遷移，分割槽遷移又引入了一些新的問題，包括遷移只能按批提交，這存在長尾問題，以及遷移fetcher和實時拉取fetcher存在資源競爭，分割槽遷移的fetcher會影響實時消費。

系統層，主要包括三個方面，一是pagecache的容量不足會導致磁碟讀寫，磁碟讀寫的效能顯著慢於記憶體，而且容量不足時還會導致pagecache汙染，pagecache汙染後，磁碟讀和回溯讀會影響實時讀；另一方面，Kafka目前使用的disk主要是HDD，HDD是比較符合順序讀寫的場景。但是對於隨機讀寫的場景，它的效能是不足的；最後由於CPU的資源競爭，在美團這邊為了提高資源的利用率，IO密集型的服務（比如Kafka）會和CPU密集型的服務（比如實時作業）混布，混布其實是存在資源競爭的，也會影響讀寫的延遲。

針對剛才提到的應用層和系統層存在的各種問題，我們這邊分層的去解決。對於應用層提到的每一點問題都會有針對性的解決方案，比如說限流、流水線加速、資源隔離等。針對系統層存在的問題，我們做了cgroup的最佳化以及物理核的隔離來保證當CPU實時計算的飆升時不會影響讀寫延遲。

2. 應用層

① 磁碟均衡

圖2-2 Kafka應用層磁碟均衡

下面介紹一下讀寫延遲在應用層遇到到的問題，磁碟熱點導致磁碟利用率不均衡，它會帶來兩個問題：

• 磁碟實時讀寫延遲變高，比如說tp99超過300ms就已經造成慢節點了；

• 叢集整體利用率不足，雖然叢集容量非常充裕，但是部分磁碟已經寫滿，這個時候甚至會導致某些分割槽暫時中斷服務。

針對這兩個問題我們做了基於空閒磁碟優先這樣一個分割槽遷移計算計劃，整個計劃分為5個點。如圖2-2 所示，首先會有一個元件叫rebalancer，rebalancer透過目標的使用率和Kafka monitor元件不斷從Kafka broker叢集上報上來的當前磁碟的使用狀況這兩類指標持續生成具體的分割槽遷移計劃，執行遷移計劃並檢查進度；然後rebalancer會向zookeeper的reassign節點提交剛才生成的遷移計劃，Kafka的controller收到這個reassign事件之後會向整個Kafka broker叢集提交reassign事件，然後Kafka broker叢集讓整體磁碟利用率趨於均衡值這樣一個目標執行磁碟遷移計劃。

如圖2-2所示，對於所有的disk，三個分割槽屬於一個相對均衡的狀態，那麼如果有一個四個分割槽的disk，就會把其中一個分割槽遷移到另外兩個分割槽的disk上，最終儘可能地保證整體磁碟利用率是均衡的。但是Kafka的分割槽遷移只能是按組提交的，在執行分割槽遷移過程中碰到了許多新的問題，下面會繼續介紹這些問題是怎麼解決的。

分割槽遷移存在一個遷移效率不足的問題，因為是按組提交的，在上一批沒有完成之前，下一批無法開始提交，這樣就會導致整體遷移進度受阻，進而對讀寫請求造成影響。

針對遷移效率問題以及帶來的它帶來的影響，我們主要做了三點改進：第一點是做流水線加速，流水線加速能夠保證長尾分割槽不影響整體遷移進度；第二點是遷移取消，在原生Kafka版本中，當一個分割槽遷移被提交後，是無法中斷的，只能等他遷移完成，那麼如果他在影響一個實時讀寫請求的時候，如果它遲遲不能完成，可能另一個實時讀寫的請求一直都會受到影響；第三點是做fetcher隔離，Kafka在做分割槽遷移的時候會利用follower透過最近讀去拉資料同步，當發起最近讀的遷移請求和某一個實時寫請求共享同一個fetcher的時候，遷移分割槽的讀請求會影響實時分割槽的讀請求，後面會進一步詳細描述具體的問題和對應的解決方案。

② 遷移最佳化

最佳化一，流水線加速

圖2-3 流水線加速

針對長尾分割槽問題，我們主要是做了流水線加速，如圖2-3所示，箭頭以上原生Kafka版本只支援按組提交，比如說一批提交了四個分割槽，當tp4這個分割槽一直卡著無法完成的時候，後續所有分割槽都無法繼續進行。採用流水線加速之後，即使tp4這個分割槽還沒有完成，當其它三個分割槽已經完成的時候，後續就可以繼續提交新的分割槽。可以看出在相同的時間內，原有的方案受阻於tp4沒有完成後續所有分割槽都沒辦法完成，但是在新的方案中，tp4分割槽已經遷移到tp11分割槽了。圖中虛線代表了一個無序的時間視窗，主要用於控制併發，目的是為了和原有的按組提交的個數保持一致，避免過多的遷移影響讀寫請求服務。

最佳化二，遷移取消

圖2-4 遷移取消

如圖2-4所示，箭頭左側描述了因為遷移影響的三種線上型別。第一種是因為遷移會觸發最舊讀，同步大量的資料，在這個過程中會首先將資料回刷到pagecache上，那麼可能會汙染pagecache，進而導致某個實時讀的分割槽發生cache miss，就會導致實時讀觸發磁碟度進而影響讀寫請求；第二類和第三類分別描述的是當存在某些異常節點導致遷移hang住的時候，想對topic做某些操作，比如對topic擴容，例如在午高峰時由於流量上漲想對topic擴容，實際上這個時候擴容是無法完成的。因為在Kafka遷移過程中這些操作都被限制住。第三個和第二個有些類似，它的主要問題是當目標節點掛了，這個時候topic擴容也是無法完成的，使用者可能一直忍受讀寫請求受影響，直到遷移完成。針對這種場景，線上無法忍受由於長時間遷移導致讀寫延遲變高的。

針對上面提到的各種問題，我們支援了一個功能叫遷移取消。當遇到這類問題時，管理員可以呼叫遷移取消命令，中斷正在遷移的分割槽，針對第一種場景，pagecache就不會被汙染，實時讀得以保證；在二、三類場景中，因為遷移取消，擴容得以完成。

遷移取消必須要刪除那些還沒有完成的分割槽，大量的刪除會導致磁碟IO，稱為效能瓶頸進而影響讀寫，因此在這裡我們針對遷移取消做了平滑刪除，避免因大量刪除影響效能問題。

最佳化三，fetcher隔離

圖2-5 fetcher隔離

如圖2-5，綠色代表實時讀，紅色代表延時讀。當某一個follower的實時讀和延時讀共享同一個fetcher時，延時讀會影響實時讀。因為每一次延時讀的資料量是顯著大於實時讀的，而且延時讀容易觸發磁碟讀，可能資料已經不在pagecache中了，顯著的拖慢了fetcher的拉取效率。

針對這種問題我們做的策略叫fetcher隔離。也就是說所有isr的follower共享fetcher，所有非isr的follower共享fetcher，這樣就能保證所有isr中的實時讀不會被非isr的回溯讀所影響。

③ Consumer非同步化

首先來了解一下Kafka-broker分階段延時統計模型，當一個Kafka的producer或consumer請求進入到Kafka-broker時，首先由processor將請求寫入RequestQueue裡面，然後RequestHandler就會從RequestQueue源源不斷地去拉取請求進行處理，在RequestQueue中的等待時間是RequestQueueTime，RequestHandler具體的執行時間為LocalTime，當RequestHandler執行完畢後會將請求扔到DelayedPurgatory元件中，這個實際上就是一個延時佇列。這個延時佇列當觸發某一個延時條件完成了以後會把請求塞到ResponseQueue中，在DelayedPurgatory佇列持續的時間為RemoteTime，processor會不斷的從ResponseQueue中將資料拉取出來發往客戶端，標紅的ResponseTime是可能會被客戶端影響的，因為如果客戶端接收能力不足，那麼ResponseTime就會一直持續增加，從Kafka-broker角度，每一次請求總的延遲叫RequestTotalTime包含了剛才所有流程分階段計時總和。

圖2-7 Consumer非同步化

主要問題是因為Kafka原生consumer基於NIO的單執行緒模型存在缺陷。如圖2-7所示，在phase1，user首先在呼叫poll請求時，當本地無資料時，同時向broker1、broker2和broker3傳送請求，實際上broker1的資料先回來了，Kafka Client立即將資料寫入CompleteQueue，這個時候立即返回，不會再拉取broker2和broker3的資料，此時user執行緒會直接從CompleteQueue中讀取資料，然後直接返回。此時broker2和broker3服務端可能已經處理好，資料已經準備就緒。user執行緒會繼續呼叫poll，訪問下一批請求，可是因為CompleteQueue依然存在broker1上次拉取的資料，這時user執行緒直接返回了，這樣就會導致broker2和broker3中已就緒的資料一直得不到拉取。如圖中phase2，因為單執行緒模型存在缺陷導致waitFetch這部分時長變大，導致Kafka-broker延時指標不斷升高。

針對這個問題我們的改進是引入非同步拉取執行緒。非同步拉取執行緒會及時的拉取就緒的資料，避免服務端延時指標受影響，而且原生Kafka並沒有限制同時拉取的分割槽數，我們在這裡做了限速，避免GC和OOM的發生。非同步執行緒在後臺持續不斷地拉取資料放到CompleteQueue中。

3. 系統層

① Raid卡加速

圖2-9 Raid卡加速

眾所周知，Kafka的寫入藉助了Zero Copy技術將資料直接寫入pagecache，但是隨著隨機讀寫併發量的提升，隨機寫導致的效能不足問題就會顯現出來。表現是隨機寫入的延時會顯著升高，針對這個問題我們引入了Raid卡。Raid卡有一個好處是自帶快取，而且Raid卡使用的是Raid-0模式，並沒有冗餘，與pagecache類似，在這一層會繼續做merge，把資料merge成更大的block寫入disk。更加充分利用順序寫HDD的頻寬，藉助Raid卡保證了隨機寫的效能是比較穩定的。

② cgroup隔離最佳化

圖2-10 cgroup隔離

在介紹cgroup的隔離最佳化之前需要提到的背景是，為了提高資源利用率，美團資料平臺將IO密集型應用和CPU密集型應用混布。IO密集型應用在這裡指的就是Kafka，CPU密集型應用在這裡指的是Flink和Storm，但是原有的隔離策略存在兩個問題：首先是物理核本身會存在資源競爭，在這個物理核下，共享的L1cache和L2cache都存在競爭，當實時平臺CPU飆升時會導致Kafka讀寫延時受到影響；另外，Kafka的HT跨NUMA，增加記憶體訪問耗時，如圖2-10所示，跨NUMA節點是透過QPI去做遠端訪問，而這個遠端訪問的耗時是40ns。

針對這兩個問題我們改進了隔離策略，針對物理核的資源競爭，我們新的混布策略Kafka是獨佔物理核的，也就是說在新的隔離策略中，不存在同一個物理核被Kafka和Flink同時使用；然後是保證Kafka的所有超執行緒處於同一側的NUMA，避免Kafka跨NUMA帶來的訪問延時。透過新的隔離策略，Kafka的讀寫延時不再受Flink CPU飆升的影響。

4. 混合層-SSD新快取架構

圖2-11 混合層SSD新快取架構

首先來了解一下Kafka的資料消費模型，Kafka利用作業系統提供的ZeroCopy技術處理資料讀取請求，pagecache容量充裕時資料直接從pagecache複製到網路卡，有效降低了讀取延時。但是實際上往往pagecache的的容量是不足的，因為它不會超過一個機器的記憶體，容量不足時，ZeroCopy就會觸發磁碟讀，磁碟讀不僅顯著變慢，還會汙染pagecache影響其他讀寫。

如圖2-11中左半部分所示，當一個延遲消費者去拉取資料時，發現pagecache中沒有它想要的資料，這個時候就會觸發磁碟讀，磁碟讀後會將資料回寫到pagecache，導致pagecache汙染，自己讀寫延遲變慢同時也會導致另一個實時消費受影響，因為對於實時消費而言，它一直讀的是最新的資料，最新的資料按正常來說時不應該出發磁碟讀的。

圖2-12 SSD新快取架構方案選型

針對這個問題，我們這邊在做方案選型時有兩種方案，

方案一，讀磁碟時不回寫pagecache，比如使用DirectIO，不過Java並不支援；

方案二，在記憶體和HDD之間引入中間層，比如SDD，如圖2-12所示，隨著讀取併發的增加，SSD的效能並不會顯著降低，非常適合我們的使用場景。

圖2-13 SSD新快取架構決策

針對SSD的方案也有兩種選型:

方案一，可以基於作業系統的核心實現，這種方案SSD與HDD儲存空間按照固定大小分塊，並且SSD與HDD建立對映關係，同時會基於資料區域性性原理，cache miss後資料會按LRU和LFU替換SSD中部分資料，業界典型方案包括OpenCAS和FlashCache。優勢是資料路由對應用層透明，對應用程式碼改動量小，並且社群活躍可用性好；但是問題是區域性性原理並不滿足Kafka的讀寫特性，而且快取空間汙染問題並未得到根本解決，因為它會根據LRU和LFU去替換SSD中的部分資料。

方案二，是基於Kafka的應用層去實現，具體就是Kafka的資料按照時間維度儲存在不同裝置上，對於近實時資料直接放在SSD上，針對較為久遠的資料直接放在HDD上，然後leader直接根據offset從對應裝置讀取資料。這種方案的優勢是他的快取策略充分考慮了Kafka的讀寫特性，確保近實時的資料消費請求全部落在SSD上，保證這部分請求處理的低延遲，同時從HDD讀取的資料不回刷到SSD防止快取汙染，同時由於每個日誌段都有唯一明確的狀態，因此每次請求目的明確，不存在因cache miss帶來的額外效能開銷。同時劣勢也很明顯，需要在server端程式碼上進行改進，涉及的開發以及測試工作量較多。

圖2-14 SSD新快取架構具體實現

下面來介紹一下SSD新快取架構的具體實現。

• 首先新的快取架構會將log內的多個segment按時間維度儲存在不同的儲存裝置上，如圖2-14中的紅圈1，新快取架構資料會有三種典型狀態，一種叫only cache，指的是資料剛寫進SSD，還未同步到HDD上；第2個是cached，指資料既同步到了HDD也有一部分快取在SSD上；第三種型別叫withoutCache，指的是同步到了HDD但是SSD中已經沒有快取了；

• 然後後臺非同步執行緒持續地將SSD資料同步到HDD上；

• 隨著SSD的持續寫入，當儲存空間達到閾值後，會按時間順序刪除距當前時間最久的資料，因為SSD他的資料空間也是有限的；

• 副本可根據可用性要求靈活開啟是否寫入SSD；

• 從HDD讀取的資料是不會回刷到SSD上的，防止快取汙染。

圖2-15 SSD新快取架構細節最佳化

介紹了具體實現之後，再來看一下細節最佳化。

• 首先是關於日誌段同步，就是剛才說到的segment，只同步Inactive的日誌段，Inactive指的是現在並沒有在寫的日誌段，低成本解決資料一致性問題；

• 其次是做同步限速最佳化，在SSD向HDD同步時是需要限速的，同時保護了兩種裝置，不會影響其他IO請求的處理，向SSD寫入資料也是需要限速的，因為SSD的使用壽命是有限的。

瞭解了讀寫延遲最佳化之後，下面來看一下Kafka在美團資料平臺是如何保證大規模叢集的穩定性的。

1. 隔離最佳化

圖3-1 隔離最佳化

由於Kafka服務於多個業務，這些業務的topic混布在一起的話很有可能造成不同業務的不同topic之間相互影響。例如broker如果和controller混布在一起，當broker負載明顯變高的時候，會導致controller無法及時處理請求，從而可能會造成整個叢集發生故障，因為後設資料的變更請求無法傳送出去。

針對這些相互影響的問題，我們從業務、角色和優先順序三個維度來做隔離最佳化。

• 第一點是業務隔離，如圖3-1所示，每一個大的業務會有一個獨立的kafka叢集，比如外賣、團購、優選；

• 第二點是分角色隔離，這裡Kafka的broker和controller以及他們依賴的元件zookeeper是部署在不同機器上的，避免之間相互影響；

• 第三點是可以分優先順序，有的業務可能它的topic可用性等級特別高，那麼我們就可以給他劃分為VIP叢集，給他更多的資源冗餘去保證可用性。

2. 全鏈路監控

圖3-2 全鏈路最佳化

隨著叢集規模的增大分割槽數變多，讀寫的客戶端也會變多，Kafka當前提供的broker端粒度的延時指標在很多情況下無法真實反映某些客戶端是否慢，還有一類問題是當叢集發生故障時，如何能及時得到感知和處理。

針對這兩個問題，我們做了全鏈路監控這樣一個專案。把Kafka核心元件以及指標全部收集起來做了一個全鏈路的追蹤，透過分析上報上來的日誌和指標，我們就可以建立細粒度的日誌大盤。當某一個讀寫請求變慢時，我們透過日誌大盤很容易就知道他具體是慢在哪個環節。日誌和指標的解析服務可以自動實時感知故障還有一些慢節點，這兩類故障有一部分我們可以做到自動處理，我們會把他透過事件的方式通知到Kafka manager，然後Kafka manager會根據這個事件自動去處理這些故障。還有一類故障是無法得到自動處理的，比如說殭屍節點，殭屍節點指的是zookeeper的臨時節點還沒有掉線，但是這個節點不管是controller也好還是客戶端也好，都已經無法訪問了，訪問就會報錯或者超時，這一類故障需要人工介入處理，會直接發給具體的管理員。

3. 服務生命週期管理

圖3-3 服務生命週期管理

首先介紹一下當叢集規模增大以後存在的一系列問題。之前版本的Kafka也有一套自動化運維的系統，但是它存在一些問題，首先是狀態語義存在歧義，無法真實反映系統狀態，往往需要藉助日誌和指標去找到真實系統是否健康或者異常；然後是狀態不全面，異常case需人工介入處理，誤操作風險極大。

基於這兩點問題，我們引入了生命週期管理機制，保證狀態能真實反映系統狀態。生命週期管理指的是從服務開始執行到機器報廢停止服務的全流程管理。並且做到了服務狀態和機器狀態聯動，無需人工同步變更。而且新的生命週期管理機制的狀態變更由特定的自動化運維觸發，禁止人工變更。

4. TOR容災

圖3-4 TOR容災-挑戰

最後一個叢集管理最佳化是TOR容災。隨著叢集規模的變大，Rack級別的故障變得平凡起來，而我們是無法容忍Rack級別的故障的，因為Rack級別的故障可能會導致分割槽不可用，原因是分割槽的多副本在同一個rack下，特別是在流儲存環境下，當某些分割槽不可用時，它會導致收集側的擁堵，影響其他topic的收集上報。並且當實時作業的某個分割槽出現異常時，它會影響整個鏈路。

如圖3-4所示，當rack1發生故障時，TopicPartition1是完全不可用的，因為他的兩個副本都在rack1上，TopicPartition2也是不可用的，雖然他有三個副本，但是他的兩個副本都已經不可用了。

圖3-5 TOR容災-改進

針對Rack級別的故障，我們做了TOR容災。改進了副本的分配演算法，保證同一個分割槽的不同副本不在同一個rack下，如圖3-5所示，即使rack1整個發生故障，也能保證所有分割槽是可用的。

最後介紹一下美團資料平臺的Kafka未來可以做哪些最佳化：首先我們會繼續去做Kafka的高可用建設，比如說客戶端主動去做一些故障節點的避讓，服務端透過多佇列的方式去隔離一些異常請求，避免它們之間相互影響。另外，高可靠方面會去做quorum write多數派寫最佳化，因為Kafka的ack等於1時是需要寫入所有副本的。我們還會去做流批一體的儲存架構，比如Kafka on HDFS。