《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性能改进 事物能力支持 坏磁盘节点的检测与规避