Kafka集群應(yīng)用實(shí)踐與技術(shù)演進(jìn)之路

1、技術(shù)創(chuàng)新，變革未來(lái)Kafka集群應(yīng)用實(shí)踐與技術(shù)演進(jìn)之路目錄業(yè)務(wù)背景技術(shù)演進(jìn) 未來(lái)規(guī)劃目錄業(yè)務(wù)背景場(chǎng)景 集群 規(guī)模技術(shù)演進(jìn) 未來(lái)規(guī)劃業(yè)務(wù)場(chǎng)景集群場(chǎng)景在線集群在線服務(wù)消息中間件集群場(chǎng)景LOG集群1.日志收集與傳輸?shù)谋镜鼐彺?.面向重要的實(shí)時(shí)消費(fèi)與數(shù)據(jù)處理。集群場(chǎng)景離線集群1.日志的最終匯聚點(diǎn)，數(shù) 據(jù)dump到Hadoop集群 離線建倉(cāng)與處理2. 面向次重要的實(shí)時(shí)消費(fèi) 與數(shù)據(jù)處理業(yè)務(wù)場(chǎng)景集群場(chǎng)景在線集群在線服務(wù)消息中間件LOG集群1.日志收集與傳輸?shù)谋?地緩存2.面向重要的實(shí)時(shí)消費(fèi) 與數(shù)據(jù)處理離線集群1.日志的最終匯聚點(diǎn)， 數(shù)據(jù)dump到Hadoop 集群2. 面向次重要的實(shí)時(shí)消 費(fèi)與數(shù)據(jù)處理集群拆

2、分：服務(wù)質(zhì)量保障規(guī)模4萬(wàn)億+日處理 消息數(shù)1億日消息 峰值4P/20P總流量1T/4T帶寬峰 值(bps)30+集群數(shù)12000Topic20萬(wàn)Topic Partition2000機(jī)器數(shù)目錄業(yè)務(wù)背景技術(shù)演進(jìn)演進(jìn)時(shí)間線 技術(shù)改進(jìn)剖析未來(lái)規(guī)劃技術(shù)演進(jìn)時(shí)間線多集群建設(shè)2017.7可用性改造2017.12資源管理平臺(tái)建設(shè)2018.4Cache改造2018.820192017.10平滑擴(kuò)容2018.2Mirror集群化建設(shè)2018.6資源隔離2018.11消費(fèi)智能限速支持業(yè)務(wù)快發(fā)展保障業(yè)務(wù)穩(wěn)定可維護(hù)性提升，提高效率精細(xì)化打磨：穩(wěn)定性、流控、性能容量?jī)?yōu)化技術(shù)演進(jìn)時(shí)間線多集群建設(shè)2017.7可用性改造20

3、17.12資源管理平臺(tái)建設(shè)2018.4Cache改造2018.820192017.10平滑擴(kuò)容2018.2Mirror集群化建設(shè)2018.6資源隔離2018.11消費(fèi)智能限速平滑擴(kuò)容213平滑擴(kuò)容為什么一定要從partition最初offset開(kāi)始遷移數(shù)據(jù)呢？原有擴(kuò)容流程問(wèn)題：數(shù)據(jù)遷移從Partition最初的offset開(kāi)始,觸發(fā)讀 盤，物理資源大量消耗 = produce延遲增高且 抖動(dòng)；擴(kuò)容不平滑平滑擴(kuò)容解決思路：從最新offset開(kāi)始遷移同步一定時(shí)間，保障所有consumer都已經(jīng) 跟上/jira/browse/KAFKA-8328技術(shù)演進(jìn)時(shí)間線多集群建設(shè)2017.7可用性改造2017

4、.12資源管理平臺(tái)建設(shè)2018.4Cache改造2018.820192017.10平滑擴(kuò)容2018.2Mirror集群化建設(shè)2018.6資源隔離2018.11消費(fèi)智能限速M(fèi)irror集群化MirrorMaker主要問(wèn)題：靜態(tài)管理，運(yùn)維成本高，易出錯(cuò)mirror的topic（1000+）mirror的機(jī)器列表變更操作導(dǎo)致正在運(yùn)行的數(shù)據(jù)Mirror 整體斷流增減topic增減機(jī)器Mirror集群化KReplicator是基于UReplicator的改進(jìn)版本 UReplicator： /uber/uReplicatorMirror集群化Controller：動(dòng)態(tài)管理topic、worker節(jié)點(diǎn)的增減

5、Topic partition的分配策略（變更時(shí)支持局部partition的遷移）檢測(cè)worker異常，并重新分配KReplicator worker：支持動(dòng)態(tài)增加或者減少topic partition執(zhí)行mirror任務(wù)（一個(gè)worker支持多個(gè)源到多個(gè) 目標(biāo)集群的傳輸）執(zhí)行dump到HDFS的任務(wù)ZooKeeper：協(xié)調(diào)controller與worker的交互KReplicator是基于UReplicator的改進(jìn)版本 UReplicator： /uber/uReplicatorMirror服務(wù)集群化管理：減低運(yùn)維，避免出錯(cuò)，支持快速調(diào)整，應(yīng)對(duì)突增流量技術(shù)演進(jìn)時(shí)間線多集群建設(shè)2017.7可

6、用性改造2017.12資源管理平臺(tái)建設(shè)2018.4Cache改造2018.820192017.10平滑擴(kuò)容2018.2Mirror集群化建設(shè)2018.6資源隔離2018.11消費(fèi)智能限速資源隔離問(wèn)題1. 不同業(yè)務(wù)線topic缺少物理隔 離，會(huì)相互影響資源隔離問(wèn)題1.不同業(yè)務(wù)線topic缺少物理隔 離，會(huì)相互影響解決思路：Broker級(jí)別物理隔離創(chuàng)建Topic遷移TP宕機(jī)恢復(fù)流程資源隔離問(wèn)題1.不同業(yè)務(wù)線topic缺少物理隔 離，會(huì)相互影響解決思路：Broker級(jí)別物理隔離創(chuàng)建Topic遷移TP宕機(jī)恢復(fù)流程問(wèn)題2. Kafka Rpc隊(duì)列缺少隔離，一 旦某個(gè)topic處理慢，會(huì)導(dǎo)致所有請(qǐng)求han

7、g住資源隔離問(wèn)題1.不同業(yè)務(wù)線topic缺少物理隔 離，會(huì)相互影響解決思路：Broker級(jí)別物理隔離創(chuàng)建Topic遷移TP宕機(jī)恢復(fù)流程問(wèn)題2. Kafka Rpc隊(duì)列缺少隔離，一 旦某個(gè)topic處理慢，會(huì)導(dǎo)致所有請(qǐng)求hang住解決思路：多RPC隊(duì)列，進(jìn)行隔離技術(shù)演進(jìn)時(shí)間線多集群建設(shè)2017.7可用性改造2017.12資源管理平臺(tái)建設(shè)2018.4Cache改造2018.820192017.10平滑擴(kuò)容2018.2Mirror集群化建設(shè)2018.6資源隔離2018.11消費(fèi)智能限速Cache改造Kafka高性能依賴page cache，但page cache不可控，主要問(wèn)題：Consumer的l

8、ag讀會(huì)對(duì)page cache產(chǎn)生污染Cache改造Kafka高性能依賴page cache，但page cache不可控，主要問(wèn)題：Consumer的lag讀會(huì)對(duì)page cache產(chǎn)生污染Follower也會(huì)占用page cache的空間，從而產(chǎn)生污染Kafka服務(wù)自己維護(hù)數(shù)據(jù)cache：嚴(yán)格按照時(shí)間順序cache控制follower的數(shù)據(jù)不進(jìn)入cacheCache改造Cache改造Cache改造環(huán)境：5個(gè)Broker；一個(gè)topic（150Partiton+3副本）壓力：Mirror數(shù)據(jù)到topic上；150個(gè)consumer，總體lag 450w讀數(shù)據(jù)結(jié)論：Cache版本可以緩存更多數(shù)據(jù)在內(nèi)存中Cache版本的性能會(huì)更好Cache改造寫(xiě)入操作同步寫(xiě)內(nèi)存，異步刷磁盤，延遲更穩(wěn)定！技術(shù)演進(jìn)時(shí)間線多集群建設(shè)2017.7可用性改造2017.12資源管理平臺(tái)建設(shè)2018.4Cache改造2018.820192017.10平滑擴(kuò)容2018.2Mirror集群化建設(shè)2018.6資源隔離2018.11消費(fèi)智能限速消費(fèi)智能限速問(wèn)題：如何解決comsumer lag后讀盤導(dǎo)致producer寫(xiě)入受阻問(wèn)題？思路：當(dāng)磁