2019年快手萬億級別Kafka集群應用實踐與技術演進之路.pdf

《2019年快手萬億級別Kafka集群應用實踐與技術演進之路.pdf》由會員分享，可在線閱讀，更多相關《2019年快手萬億級別Kafka集群應用實踐與技術演進之路.pdf（34頁珍藏版）》請在三個皮匠報告上搜索。

1、快手萬億級別Kafka集群應用實踐與技術演進之路大數據架構團隊負責人目錄業務背景技術演進未來規劃目錄業務背景場景集群規模技術演進未來規劃業務場景集群場景在線集群在線服務消息中間件集群場景LOG集群 1.日志收集與傳輸的本地緩存2.面向重要的實時消費與數據處理集群場景離線集群1.日志的最終匯聚點，數據dump到Hadoop集群。離線建倉與處理2.面向次重要的實時消費與數據處理業務場景集群場景在線集群在線服務消息中間件LOG集群1.日志收集與傳輸的本地緩存2.面向重要的實時消費與數據處理離線集群1.日志的最終匯聚點，數據dump到Hadoop集群2.面向次重要的實時消費與數據處理集群拆分：服務質量

2、保障規模日處理消息數4萬億+日消息峰值1億總流量4P/20P帶寬峰值(bps)1T/4T集群數30+Topic12000TopicPartition20萬機器數2000目錄業務背景技術演進演進時間線技術改進剖析未來規劃技術演進時間線2017.72017.7多集群建設2017.122017.12可用性改造2018.42018.4資源管理平臺建設2018.82018.8Cache改造201920192017.102017.10平滑擴容2018.22018.2Mirror集群化建設2018.62018.6資源隔離2018.112018.11消費智能限速支持業務快發展保障業務穩定可維護性提升，提高效率

3、精細化打磨：穩定性、流控、性能容量優化技術演進時間線2017.72017.7多集群建設2017.122017.12可用性改造2018.42018.4資源管理平臺建設2018.82018.8Cache改造201920192017.102017.10平滑擴容2018.22018.2Mirror集群化建設2018.62018.6資源隔離2018.112018.11消費智能限速平滑擴容213平滑擴容為什么一定要從partition最初offset開始遷移數據呢？原有擴容流程問題：數據遷移從Partition最初的offset開始,觸發讀盤，物理資源大量消耗=produce延遲增高且抖動；擴容不平滑平滑

4、擴容 解決思路：從最新offset開始遷移 同步一定時間，保障所有consumer都已經跟上https:/issues.apache.org/jira/browse/KAFKA-8328技術演進時間線2017.72017.7多集群建設2017.122017.12可用性改造2018.42018.4資源管理平臺建設2018.82018.8Cache改造201920192017.102017.10平滑擴容2018.22018.2Mirror集群化建設2018.62018.6資源隔離2018.112018.11消費智能限速Mirror集群化 MirrorMaker主要問題：1.靜態管理，運維成本高，易

5、出錯 mirror的topic（1000+）mirror的機器列表2.變更操作導致正在運行的數據Mirror整體斷流 增減topic 增減機器Mirror集群化KReplicator是基于UReplicator的改進版本UReplicator：https:/ Controller：動態管理topic、worker節點的增減 Topic partition的分配策略（變更時支持局部partition的遷移）檢測worker異常，并重新分配 KReplicator worker：支持動態增加或者減少topic partition 執行mirror任務（一個worker支持多個源到多個目標集群的傳輸

6、）執行dump到HDFS的任務 ZooKeeper：協調controller與worker的交互Mirror服務集群化管理：減低運維，避免出錯，支持快速調整，應對突增流量技術演進時間線2017.72017.7多集群建設2017.122017.12可用性改造2018.42018.4資源管理平臺建設2018.82018.8Cache改造201920192017.102017.10平滑擴容2018.22018.2Mirror集群化建設2018.62018.6資源隔離2018.112018.11消費智能限速資源隔離 問題1.不同業務線topic缺少物理隔離，會相互影響資源隔離 問題1.不同業務線top

7、ic缺少物理隔離，會相互影響 解決思路：Broker級別物理隔離 創建Topic 遷移TP 宕機恢復流程資源隔離 問題1.不同業務線topic缺少物理隔離，會相互影響 解決思路：Broker級別物理隔離 創建Topic 遷移TP 宕機恢復流程 問題2.Kafka Rpc隊列缺少隔離，一旦某個topic處理慢，會導致所有請求hang住資源隔離 問題1.不同業務線topic缺少物理隔離，會相互影響 解決思路：Broker級別物理隔離 創建Topic 遷移TP 宕機恢復流程 問題2.Kafka Rpc隊列缺少隔離，一旦某個topic處理慢，會導致所有請求hang住 解決思路：多RPC隊列，進行隔離技

8、術演進時間線2017.72017.7多集群建設2017.122017.12可用性改造2018.42018.4資源管理平臺建設2018.82018.8Cache改造201920192017.102017.10平滑擴容2018.22018.2Mirror集群化建設2018.62018.6資源隔離2018.112018.11消費智能限速Cache改造 Kafka高性能依賴page cache，但page cache不可控，主要問題：1.Consumer的lag讀會對page cache產生污染Cache改造 Kafka高性能依賴page cache，但page cache不可控，主要問題：1.Con

9、sumer的lag讀會對page cache產生污染2.Follower也會占用page cache的空間，從而產生污染 Kafka服務自己維護數據cache：1.嚴格按照時間順序cache2.控制follower的數據不進入cacheCache改造Cache改造Cache改造 環境：5個Broker；一個topic（150Partiton+3副本）壓力：Mirror數據到topic上；150個consumer，總體lag 450w讀數據 結論：Cache版本可以緩存更多數據在內存中 Cache版本的性能會更好Cache改造寫入操作同步寫內存，異步刷磁盤，延遲更穩定！技術演進時間線2017.7

10、2017.7多集群建設2017.122017.12可用性改造2018.42018.4資源管理平臺建設2018.82018.8Cache改造201920192017.102017.10平滑擴容2018.22018.2Mirror集群化建設2018.62018.6資源隔離2018.112018.11消費智能限速消費智能限速 問題：如何解決comsumer lag后讀盤導致producer寫入受阻問題？思路：當磁盤繁忙，針對lag的consumer進行限速控制消費智能限速穩定穩定限速開始限速開始目錄業務背景技術演進演進時間線技術改進剖析（平滑擴容、mirror集群化、可用性、性能）未來規劃未來規劃 跨IDC統一大集群建設 Controller性能改進 事物能力支持 壞磁盤節點的檢測與規避