Kafka万亿级消息实战干货~持续更新中
完整文章地址：https://mp.weixin.qq.com/s/4t4k6aO_1P_wSH6pU2geog
文章目录
- 一、Kafka应用层面
-
- 1.版本升级
- 2.数据/副本迁移
- 3.流量限制
- 4.运维监控告警；
-
- 4.1.硬件基础监控
- 4.2.Kafka服务监控
- 4.3.客户端应用监控
- 4.4.zookeeper监控
- 5.资源隔离
- 6.集群归类
- 7.扩容/缩容
- 8.负载均衡
- 9.安全认证
- 10.集群容灾
- 11.参数/配置优化
-
- 11.1.服务参数优化；
- 11.2.生产参数优化；
- 11.4.服务器内核参数优化；
- 12.硬件层面优化
-
- 12.4.网络隔离打标
- 13.业务大屏
- 14.集群管理
- 15.集群治理
- 16.mock功能
- 17.集群IP、域名映射
- 18.性能测试评估
- 19.kafka常见痛点
- 二、Kafka底层原理层面
-
- 1.生产者实现细节
- 2.消费者实现细节
- 3.副本迁移实现细节
- 4.topic的增、删、改、查实现细节
- 5.Controller的选举细节
- 6.topic分区Leader选举实现细节
- 7.Metrics指标实现细节
- 8.Quota流量限制实现细节
- 9.时间轮实现细节
- 10.安全认证实现细节
- 11.事务实现细节
- 12.topic分区数据过期处理实现细节
- 13.动态配置实现细节
- 14.topic分区isr列表变化如何处理
- 15.日志数据存储细节
- 三、kafka开源版本功能缺陷
-
- 1.副本迁移
-
- 1.1.现有方案缺陷
- 1.2.源码改造点
- 1.3.改造后达成效果
当前线上集群规模已经超过了
600+broker，入流量超3万亿记录/天，出流量超7万亿记录/天。在巨大的流量实战中，我们遇到了很多麻烦，这里抽了点时间梳理了一下。主要从 应用层面、 底层原理层面、 开源版本功能缺陷三个方面进行了核心知识点的梳理。目前本文只是对核心知识点进行概括，并不会详细描述每个知识点的细节，后续我将抽出时间来继续整理完善细节，希望可以为大家提供一些帮助。
一、Kafka应用层面
1.版本升级
1.1.如何进行版本滚动升级与回退；
2.数据/副本迁移
2.1.broker间数据迁移；
2.2.broker内部磁盘间数据迁移；
3.流量限制
3.1.生产者流量限制；
3.2.消费者流量限制；
3.3.follower副本同步leader副本流量限制；
4.运维监控告警；
4.1.硬件基础监控
4.1.1.网络
网络入流量、网络出流量、网络丢包、网络重传、交换机。
4.1.2.磁盘
磁盘write、磁盘read、磁盘ioutil、磁盘iowait、磁盘存储空间、磁盘坏盘、磁盘坏块/坏道。
4.1.3.CPU
CPU空闲率/负载
4.1.4.内存
内存使用率
4.1.5.缓存命中率
Linux的PageCache缓存命中率，详细内容请阅读下面这篇文章：https://blog.csdn.net/yangyijun1990/article/details/105341785
4.2.Kafka服务监控
4.2.1.broker级别：
broker进程、broker出/入流量、broker连接数、broker网络空闲率、broker生产延时、broker消费延时、broker生产请求数、broker消费请求数、broker上分布leader个数、broker上分布副本个数、broker请求队列
4.2.2.topic级别：
topic副本缺失、topic出/入流量、topic消费者消费延迟记录、topic分区leader切换
4.2.3.用户级别
用户出/入流量、用户出/入流量被限制时间；
4.2.4.服务日志
对server端打印的错误日志进行监控告警；
4.3.客户端应用监控
4.3.1.生产者客户端
- 维度：客户端ID、客户端IP、topic名称、集群名称、brokerIP；
- 指标：连接数、io等待时间、生产流量大小、生产记录数、请求次数、请求延时、发送错误/重试次数等；
4.3.2.消费者客户端
- 维度：客户端ID、客户端IP、topic名称、集群名称、消费组、brokerIP、topic分区
- 指标：连接数、io等待时间、消费流量大小、消费记录数、消费延时、topic分区消费延迟记录等
4.4.zookeeper监控
4.4.1.zookeeper的进程监控；
4.4.2.zookeeper的leader切换；
4.4.3.zookeeper服务的错误日志监控；
5.资源隔离
5.1.业务资源物理隔离（分资源组，不同资源组之间物理隔离），不同业务互不影响；
6.集群归类
我们根据业务和用途的不同，对集群进行了归类。主要分为以下几类：
- 日志集群；
- 监控集群；
- 计费集群；
- 商业化集群；
- 非商业化集群；
7.扩容/缩容
7.1.topic扩容分区；
7.2.集群节点扩容broker（新broker上线）；
7.3.集群缩容（节点下线）；
8.负载均衡
8.1.开发自动负载均衡程序采集metrics指标，生成副本迁移计划，并执行迁移；
8.2.broker间负载均衡、broker内部多块磁盘间负载均衡；
9.安全认证
9.1.生产者权限认证；
9.2.消费者权限认证；
9.3.指定迁移数据目录安全认证；
10.集群容灾
10.1.跨机架容灾；
10.2.跨集群容灾；
10.3.跨机房容灾；
11.参数/配置优化
11.1.服务参数优化；
num.network.threads
建议设置为broker当CPU核心数2，这个值太低经常出现网络空闲太低而缺失副本。
num.io.threads
建议设置为broker磁盘个数2
num.replica.fetchers
建议设置为CPU核心数/4，适当提高可以提升CPU利用率及follower同步leader数据当并行度。
compression.type
建议采用lz4压缩类型，压缩可以提升CPU利用率同时可以减少网络传输数据量。
11.2.生产参数优化；
linger.ms
客户端生产消息等待多久时间才发送到服务端，单位：毫秒。和batch.size参数配合使用；
batch.size
客户端发送到服务端消息批次大小，和linger.ms参数配合使用；
compression.type
建议采用lz4压缩类型，具备较高的压缩比及吞吐量；
11.3.消费参数优化；
11.4.服务器内核参数优化；
11.4.服务器内核参数优化；
- Linux的pagecache参数优化。参考地址：http://q.vivo.xyz/?/article/137
- vm.max_map_count优化；
/etc/security/limits.con 修改文件句柄；
ulimit -n 2048 这个只是临时生效,想要永久生效需要添加如下行：
-
soft nofile 999000 -
hard nofile 1000000
12.硬件层面优化
12.1.采用SSD固态硬盘代替HDD(机械盘)；
12.2.采用更大内存服务器，比如256GB及以上；
12.3.配置更高的网络带宽，比如 10Gb/s及以上；
12.4.网络隔离打标
由于一个机房可能既部署有离线集群（比如HBase、Spark、Hadoop等）又部署有实时集群（如Kafka）。那么实时集群和离线集群挂载到同一个交换机下的服务器将出现竞争网络带宽的问题，离线集群可能对实时集群造成影响。所以我们需要进行交换机层面的隔离，让离线集群和实时集群不要挂载到相同到交换机下。另外对机房的网络带宽进行金、银、铜、铁优先级打标，实时业务优先级排最高。
13.业务大屏
集群个数、节点个数、存储大小、用户个数、topic个数、分区个数、副本个数、消费组个数、生产延时、消费延时、生产流量、消费流量、数据可靠性/完整性；
14.集群管理
14.1.集群配置管理；
14.2.集群滚动重启；
15.集群治理
15.1.无生产/消费的topic从集群中清理掉；
15.2.消费延迟较高的topic分区监控告警，并让相应的消费方检查延迟较大原因及解决措施；
16.mock功能
16.1.生产mock；
16.2.消费mock；
17.集群IP、域名映射
17.1.上线broker添加域名到broker的映射；
17.2.下线broker剔除域名与broker的映射；
18.性能测试评估
18.1.根据性能测试结果评估broker节点个数及分区个数；
19.kafka常见痛点
请阅读文章：https://blog.csdn.net/yangyijun1990/article/details/106698084
二、Kafka底层原理层面
1.生产者实现细节
1.1.如何获取元数据；
1.2.添加分区后如何感知；
1.3.分区leader切换后如何感知；
1.4.数据如何存储；
1.5.如果acks被设置为-1，则如何进行回调判断所有follower都已经收到数据；
2.消费者实现细节
1.1.如何获取元数据；
1.2.添加分区后如何感知；
1.3.分区leader切换后如何感知；
1.4.添加新的消费者实例如何均衡；
1.5.如何检索消息；
3.副本迁移实现细节
3.1.不带指定数据目录的迁移（broker间数据迁移）；
3.2.带指定数据目录的迁移（broker间数据迁移及broker内部数据目录迁移）；
4.topic的增、删、改、查实现细节
5.Controller的选举细节
6.topic分区Leader选举实现细节
7.Metrics指标实现细节
8.Quota流量限制实现细节
9.时间轮实现细节
10.安全认证实现细节
11.事务实现细节
12.topic分区数据过期处理实现细节
13.动态配置实现细节
13.1.broker、topic、user配置动态管理；
14.topic分区isr列表变化如何处理
14.1.isr列表收缩；
14.2.isr列表扩展；
15.日志数据存储细节
15.1.日志目录结构；
15.2.日志内容格式；
三、kafka开源版本功能缺陷
1.副本迁移
1.1.现有方案缺陷
由于Kafka自身的架构设计特点，这必然导致集群节点规模达到一定量（比如，单集群规模达到数百个broker节点）时，集群各broker之间流量或者broker内部各磁盘之间流量负载不均衡。
在这种情况下就需要对集群进行负载均衡，让流量能够比较均匀的分布到各broker的各块磁盘上。Kafka官方也为我们提供了相应的副本迁移工具，然而此迁移工具存在以下问题：
（1）迁移会全量读取历史数据，这可能导致大量的磁盘读取操作，从而使broker的IO负载持续较高；从磁盘读取的历史数据污染PageCache，导致消费者消费时无法命中缓存，严重的影响了集群的稳定和服务的性能；
（2）全量读取历史数据，针对一些保留时间较长的topic（如保留时间为3天甚至更久），当此topic的分区数据存储特别大时（数百GB），数据迁移将变成一个漫长的过程，可能需要数小时才能迁移完毕；
（3）迁移任务启动后无法手动终止，当迁移任务影响到集群的稳定时，我们将束手无策，迁移任务将加重集群的负担，最终可能放大故障的影响范围；
（4）同一个集群副本迁移任务是串行的（无法进行并发迁移），对于我们已经在集群内部做资源组物理隔离的方案来说，不同资源组之间是互不影响的，而串行迁移使迁移效率变得低下，影响负载均衡的效率；
1.2.源码改造点
针对已有功能存在的问题，我们对Kafka源码进行了改造，主要优化点如下：
（1）把全量迁移改造为可以支持全量与增量两种策略，可以根据实际场景需求动态调整迁移策略；
（2）把迁移任务启动后不可终止的缺陷进行了优化，全量和增量迁移都实现了终止迁移功能；
（3）分不同资源组，实现单个集群内，多个资源组之间的并发迁移。
1.3.改造后达成效果
（1）数据迁移任务从小时级延时降低至秒级延时，平均迁移速度提升100倍以上，可以实现流量瞬间转移，提升了负载均衡的效率；
（2）整个迁移过程无读磁盘IO，降低了数据迁移给集群稳定与性能造成影响的风险，提升了集群的稳定性；
（3）可以实现迁移任务终止操作，解决了各种异常迁移场景无法终止迁移任务的缺陷，让迁移更加可控；
（4）可以实现并发迁移，提升集群内迁移效率；