Kafka集群应用实践与技术演进之路

1、技术创新，变革未来Kafka集群应用实践与技术演进之路目录业务背景技术演进 未来规划目录业务背景场景 集群 规模技术演进 未来规划业务场景集群场景在线集群在线服务消息中间件集群场景LOG集群1.日志收集与传输的本地缓存2.面向重要的实时消费与数据处理。集群场景离线集群1.日志的最终汇聚点，数 据dump到Hadoop集群 离线建仓与处理2. 面向次重要的实时消费 与数据处理业务场景集群场景在线集群在线服务消息中间件LOG集群1.日志收集与传输的本 地缓存2.面向重要的实时消费 与数据处理离线集群1.日志的最终汇聚点， 数据dump到Hadoop 集群2. 面向次重要的实时消 费与数据处理集群拆

2、分：服务质量保障规模4万亿+日处理 消息数1亿日消息 峰值4P/20P总流量1T/4T带宽峰 值(bps)30+集群数12000Topic20万Topic Partition2000机器数目录业务背景技术演进演进时间线 技术改进剖析未来规划技术演进时间线多集群建设2017.7可用性改造2017.12资源管理平台建设2018.4Cache改造2018.820192017.10平滑扩容2018.2Mirror集群化建设2018.6资源隔离2018.11消费智能限速支持业务快发展保障业务稳定可维护性提升，提高效率精细化打磨：稳定性、流控、性能容量优化技术演进时间线多集群建设2017.7可用性改造20

3、17.12资源管理平台建设2018.4Cache改造2018.820192017.10平滑扩容2018.2Mirror集群化建设2018.6资源隔离2018.11消费智能限速平滑扩容213平滑扩容为什么一定要从partition最初offset开始迁移数据呢？原有扩容流程问题：数据迁移从Partition最初的offset开始,触发读 盘，物理资源大量消耗 = produce延迟增高且 抖动；扩容不平滑平滑扩容解决思路：从最新offset开始迁移同步一定时间，保障所有consumer都已经 跟上/jira/browse/KAFKA-8328技术演进时间线多集群建设2017.7可用性改造2017

4、.12资源管理平台建设2018.4Cache改造2018.820192017.10平滑扩容2018.2Mirror集群化建设2018.6资源隔离2018.11消费智能限速Mirror集群化MirrorMaker主要问题：静态管理，运维成本高，易出错mirror的topic（1000+）mirror的机器列表变更操作导致正在运行的数据Mirror 整体断流增减topic增减机器Mirror集群化KReplicator是基于UReplicator的改进版本 UReplicator： /uber/uReplicatorMirror集群化Controller：动态管理topic、worker节点的增减

5、Topic partition的分配策略（变更时支持局部partition的迁移）检测worker异常，并重新分配KReplicator worker：支持动态增加或者减少topic partition执行mirror任务（一个worker支持多个源到多个 目标集群的传输）执行dump到HDFS的任务ZooKeeper：协调controller与worker的交互KReplicator是基于UReplicator的改进版本 UReplicator： /uber/uReplicatorMirror服务集群化管理：减低运维，避免出错，支持快速调整，应对突增流量技术演进时间线多集群建设2017.7可

6、用性改造2017.12资源管理平台建设2018.4Cache改造2018.820192017.10平滑扩容2018.2Mirror集群化建设2018.6资源隔离2018.11消费智能限速资源隔离问题1. 不同业务线topic缺少物理隔 离，会相互影响资源隔离问题1.不同业务线topic缺少物理隔 离，会相互影响解决思路：Broker级别物理隔离创建Topic迁移TP宕机恢复流程资源隔离问题1.不同业务线topic缺少物理隔 离，会相互影响解决思路：Broker级别物理隔离创建Topic迁移TP宕机恢复流程问题2. Kafka Rpc队列缺少隔离，一 旦某个topic处理慢，会导致所有请求han

7、g住资源隔离问题1.不同业务线topic缺少物理隔 离，会相互影响解决思路：Broker级别物理隔离创建Topic迁移TP宕机恢复流程问题2. Kafka Rpc队列缺少隔离，一 旦某个topic处理慢，会导致所有请求hang住解决思路：多RPC队列，进行隔离技术演进时间线多集群建设2017.7可用性改造2017.12资源管理平台建设2018.4Cache改造2018.820192017.10平滑扩容2018.2Mirror集群化建设2018.6资源隔离2018.11消费智能限速Cache改造Kafka高性能依赖page cache，但page cache不可控，主要问题：Consumer的l

8、ag读会对page cache产生污染Cache改造Kafka高性能依赖page cache，但page cache不可控，主要问题：Consumer的lag读会对page cache产生污染Follower也会占用page cache的空间，从而产生污染Kafka服务自己维护数据cache：严格按照时间顺序cache控制follower的数据不进入cacheCache改造Cache改造Cache改造环境：5个Broker；一个topic（150Partiton+3副本）压力：Mirror数据到topic上；150个consumer，总体lag 450w读数据结论：Cache版本可以缓存更多数据在内存中Cache版本的性能会更好Cache改造写入操作同步写内存，异步刷磁盘，延迟更稳定！技术演进时间线多集群建设2017.7可用性改造2017.12资源管理平台建设2018.4Cache改造2018.820192017.10平滑扩容2018.2Mirror集群化建设2018.6资源隔离2018.11消费智能限速消费智能限速问题：如何解决comsumer lag后读盘导致producer写入受阻问题？思路：当磁