八大步骤带你深度剖析Kafka生产级容量评估方案
接下来还会有一系列的 Kafka 相关文章, 全方位的梳理和剖析 Kafka 「原理设计, 架构, 源码剖析」。本篇是 Kafka 系列文章的第三篇, 本篇章会通过场景驱动的方式来深度剖析 Kafka 生产级容量评估方案如何分析,申请和实施。
kafka容量评估需求场景分析
拿电商平台为例, kafka 集群每天需要承载10亿+请求流量数据，一天24小时，对于平台来说，晚上12点到凌晨8点这8个小时几乎没多少数据涌入的。这里我们使用「二八法则」来进行预估，也就是80%的数据（8亿）会在剩余的16个小时涌入，且8亿中的80%的数据（约6.4亿）会在这16个小时的20%时间 （约3小时）涌入。
通过上面的场景分析,可以得出如下:
QPS计算公式 = 640000000 ÷ (3 * 60 * 60) = 6万，也就是说高峰期集群需要抗住每秒6万的并发请求。
假设每条数据平均按20kb(生产端有数据汇总)来算, 那就是 1000000000 * 20kb = 18T, 一般情况下我们都会设置3个副本, 即54T, 另外 kafka 数据是有保留时间周期的, 一般情况是保留最近3天的数据, 即 54T * 3 = 162T
场景总结:
要搞定10亿+请求,高峰期要支撑6万QPS, 需要大约162T的存储空间
kafka容量评估之物理机数量
一般对于Kafka, Mysql, Hadoop 等集群自建的时候, 都会使用物理机来进行搭建, 性能和稳定性相对虚拟机要强很多。
在第一步中我们分析得出系统高峰期的时候要支撑6万QPS, 如果公司资金和资源充足的情况下, 我们一般会让高峰期的QPS控制在集群总承载QPS能力的30%左右, 这样的话可以得出集群能承载的总QPS能力约为20万左右, 这样系统才会是安全的。
场景总结:
根据经验可以得出每台物理机支撑4万QPS是没有问题的, 从QPS角度分析, 我们要支撑10亿+请求,大约需要5台物理机, 考虑到消费者请求, 需要增加约1.5倍机器, 即7台物理机。
kafka容量评估之磁盘
主要区别:
1、SSD就是固态硬盘，它的优点是速度快，日常的读写比机械硬盘快几十倍上百倍。缺点是单位成本高，不适合做大容量存储。
2、HDD就是机械硬盘，它的优点是单位成本低，适合做大容量存储，但速度远不如SSD。
首先SSD硬盘性能好, 主要是指的随机读写能力性能好, 非常适合Mysql这样的集群, 而SSD的顺序读写性能跟机械硬盘的性能是差不多的。
在上一篇 kafka三高架构设计剖析 中我们了解到 Kafka 写磁盘是顺序追加写的, 所以对于 kafka 集群来说,我们使用普通机械硬盘就可以了。
根据第一二步骤计算结果, 我们需要7台物理机, 一共需要存储162T数据,大约每台机器需要存储23T数据, 根据以往经验一般服务器配置11块硬盘, 这样每块硬盘大约存储2T的数据就可以了, 另外为了服务器性能和稳定性, 我们一般要保留一部分空间, 保守按每块硬盘最大能存储3T数据。
场景总结:
要搞定10亿+请求, 需要7台物理机, 使用普通机械硬盘进行存储, 每台服务器11块硬盘, 每块硬盘存储2T数据
kafka容量评估之内存
1) 从上图可以得出 Kafka 读写数据的流程主要都是基于os cache, 所以基本上 Kafka 都是基于内存来进行数据流转的, 这样的话要分配尽可能多的内存资源给os cache。
2) kafka的核心源码基本都是用 scala 和 java (客户端)写的, 底层都是基于 JVM 来运行的, 所以要分配一定的内存给 JVM 以保证服务的稳定性。对于 Kafka 的设计,并没有把很多的数据结构存储到 JVM 中, 所以根据经验,给 JVM 分配6~10G就足够了。
3) 从上图可以看出一个 Topic 会对于多个 partition ,一个 partition 会对应多个 segment , 一个 segment 会对应磁盘上4个log文件。假设我们这个平台总共100个 Topic , 那么总共有 100 Topic * 5 partition * 3 副本 = 1500 partition 。对于 partition 来说实际上就是物理机上一个文件目录, .log就是存储数据文件的, 默认情况下一个.log日志文件大小为1G。
4) 如果要保证这1500个 partition 的最新的 .log 文件的数据都在内存中, 这样性能当然是最好的, 需要 1500 * 1G = 1500 G内存, 但是我们没有必要所有的数据都驻留到内存中, 我们只保证25%左右的数据在内存中就可以了, 这样大概需要 1500 * 250M = 1500 * 0.25G = 375G内存, 通过第二步分析结果,我们总共需要7台物理机, 这样的话每台服务器只需要约54G内存, 外加上面分析的JVM的10G, 总共需要64G内存。还要保留一部分内存给操作系统使用,故我们选择128G内存的服务器是非常够用了。
场景总结:
要搞定10亿+请求, 需要7台物理机, 每台物理机内存选择128G内存为主, 这样内存会比较充裕。
kafka容量评估之CPU压力
我们评估需要多少个 CPU Core，主要是看 Kafka 进程里会有多少个线程，线程主要是依托多核CPU来执行的，如果线程特别多，但是 CPU核很少，就会导致CPU负载很高，会导致整体工作线程执行的效率不高,性能也不会好。所以我们要保证CPU Core的充足, 来保障系统的稳定性和性能最优。
我们评估下 Kafka 服务器启动后会有多少线程在跑, 其实这部分内容跟kafka超高并发网络架构密切相关, 上图是Kafka 超高并发网络架构图, 从图中我们可以分析得出:
| 线程名 | 默认数 | 建议数 | 总数 |
| Accept线程 | 1 | 1 | 1 |
| Processor线程 | 3 | 9 | 9 |
| RequestHandle线程 | 8 | 32 | 32 |
| 定时清理线程 | 1 | 1 | 1 |
| 副本同步线程 | 1 | 1 | 1 |
| 感知控制器状态的线程 | 1 | 1 | 1 |
| 定时检测ISR线程 | 1 | 1 | 1 |
| ........ | ........ | ........ | ........ |
除了上图所列的还有其他一些线程, 所以估算下来,一个 kafka 服务启动后, 会有100多个线程在跑。
| cpu数 | 支撑情况分析 |
| 4 | 可以支撑几十个线程, 在高峰期cpu几乎会被打满 |
| 8 | 可以比较宽裕的支撑几十个线程繁忙的工作 |
| 16 | 建议核数(2 cpu * 8), 基本可以支撑100~200个线程的工作 |
| 32 | 如果资源充裕, 性能会更好 (4 cpu * 8) |
场景总结:
要搞定10亿+请求, 需要7台物理机, 每台物理机内存选择128G内存为主,需要16个cpu core(32个性能更好)
kafka容量评估之网卡
| 网卡类型 | 性能分析 |
| 千兆网卡 | 1000Mbit/s网卡，是根据网速从10M/100M/1000M自适应的网卡，也称为千兆以太网网卡，多用于服务器。其传输速率可达1000Mbps，根据端口区分有1口，2口，4口网卡，可以为服务器与交换机提供高速的连接，提高网络主干系统的响应速度。 |
| 万兆网卡 | 一般指万兆光纤网卡。万兆网卡适用于服务器领域，为10G/秒通讯量的网卡，采用32/64位总线的网络接口卡，提供PC机服务器和交换机的连接，解决Internet模式中服务器网卡的瓶颈问题。 |
通过上图分析可以得出千兆网卡和万兆网卡的区别最大之处在于网口的传输速率的不同，千兆网卡的传输速率是1000Mbps，万兆网卡的则是10Gbps万兆网卡是千兆网卡传输速率的10倍。性能上讲，万兆网卡的性能肯定比千兆网卡要好。万兆网卡现在主流的是10G的，发展趋势正逐步面向40G、100G网卡。但还是要根据使用环境和预算来选择投入，毕竟千兆网卡和万兆网卡的性价比区间还是挺大的。
根据第一二步分析结果, 高峰期的时候, 每秒会有大约6万请求涌入, 即每台机器约1万请求涌入(60000 / 7), 每秒要接收的数据大小为: 10000 * 20 kb = 184 M/s, 外加上数据副本的同步网络请求, 总共需要 184 * 3 = 552 M/s。
一般情况下,网卡带宽是不会达到上限的,对于千兆网卡, 我们能用的基本在700M左右, 通过上面计算结果, 千兆网卡基本可以满足, 万兆网卡更好。
场景总结:
要搞定10亿+请求, 需要7台物理机, 每台物理机内存选择128G内存为主,需要16个cpu core(32个性能更好), 千兆网卡基本可以满足, 万兆网卡更好。
kafka容量评估之核心参数
| 核心参数 | 参数说明与建议 |
| broker.id | 每个broker都必须设置一个唯一的ID |
| log.dirs | 这个参数非常重要, kafka 所有的数据都是写入到这个目录下的磁盘文件中的,如果说机器上有多块物理硬盘的话,那么可以把多个目录挂载到不同的物理硬盘上,然后这里可以设置多个目录。这样 kafka 可以把数据分散到多块物理硬盘,多个硬盘可以并发写,提升吞吐量。 上面评估我们每台机器会有11块硬盘对应这里的11个目录: /data0/log,/data1/log,.....,/data10/log |
| zookeeper.connect | controller是 kafka 中的管理者,对 kafka 的管理其实就相当于对zk的管理,此参数是链接 kafka 底层的zk集群的 |
| listeners | 这是broker监听客户端发起请求的端口号 |
| delete.topic.enable | 默认为true, 允许删除topic |
| log.retention.hours | 日志保留策略时间配置, kafka 里面的数据是有生命周期的,就是底层日志文件要保留多长时间, 默认为7天(168小时), 一般我们建议3天(72小时), 另外云服务默认也是3天 |
| log.retention.bytes | 即如果分区数据量超过这个设置,会自动被清理掉,默认-1不按照这个策略来清理 |
| log.segment.bytes | 段文件默认配置1GB，有利于快速回收磁盘空间，重启kafka加载也会加快，相反如果文件过小，则文件数量比较多，kafka 启动 时是单线程扫描目录(log.dirs)下所有数据文件)，文件较多时性能会稍微降低。可通过如下选项配置段文件大小:log.segment.bytes=1073741824 |
| num.network.threads | 负责转发请求给实际工作线程的网络请求处理线程的数量,默认为3个, 上面评估高负载情况下可以设置为9个 |
| num.io.threads | 控制实际处理请求的线程数量,默认为8个,上面评估高负载情况下可以设置为32个 |
| message.max.bytes | broker默认接收的消息的最大大小,默认为977kb,建议设置成10M |
| log.flush.interval.message | log数据文件刷盘策略, 为了大幅度提高 producer写入吞吐量，需要定期批量写文件 优化建议为：每当producer写入10000条消息时，刷数据到磁盘:log.flush.interval.messages=10000 |
| log.flush.interval.ms | log数据文件刷盘策略, 为了大幅度提高 producer写入吞吐量，需要定期批量写文件 优化建议为：每当producer写入10000条消息时，刷数据到磁盘。 每间隔1秒钟时间，刷数据到磁盘: log.flush.interval.ms=1000 |
| replica.lag.time.max.ms | Follower 副本能够落后 Leader 副本的最长时间间隔, 当前默认值为10秒, 也就是说, 只要一个Follower 副本落后 Leader 副本的时间不连续超过10秒, Kafka 就认为两者是同步的, 即使 Follower 副本中保持的消息要少于 Leader 副本中的消息。 |
| request.required.acks | 参考<kafka三高架构设计剖析>中的ack机制篇章 |
kafka容量评估之集群规划
这里我采用五台服务器来构建 Kafka 集群，集群依赖 ZooKeeper，所以在部署 Kafka 之前，需要部署好 ZooKeeper 集群。这里我将 Kafka 和 ZooKeeper 部署在了一起，Kafka 集群节点操作系统仍然采用 Centos 7.7 版本，各个主机角色和软件版本如下表所示：
| IP地址 | 主机名 | 安装软件 | 软件版本 |
| 172.16.213.31 | kafka-zk1 | kafka + zk | kafka_2.11-2.4.1 zookeeper-3.5.8 |
| 172.16.213.32 | kafka-zk2 | kafka + zk | kafka_2.11-2.4.1 zookeeper-3.5.8 |
| 172.16.213.33 | kafka-zk3 | kafka + zk | kafka_2.11-2.4.1 zookeeper-3.5.8 |
| 172.16.213.34 | kafka-zk4 | kafka + zk | kafka_2.11-2.4.1 zookeeper-3.5.8 |
| 172.16.213.35 | kafka-zk5 | kafka + zk | kafka_2.11-2.4.1 zookeeper-3.5.8 |
这里需要注意：Kafka 和 ZooKeeper 的版本，默认 Kafka2.11 版本自带的 ZooKeeper 依赖 jar 包版本为 3.5.7，因此 ZooKeeper 的版本至少在 3.5.7 及以上。
Kafka 需要安装 Java 运行环境，你可以点击Kafka官网
(https://kafka.apache.org/downloads)获取 Kafka 安装包，推荐的版本是 kafka_2.11-2.4.1.tgz。将下载下来的安装包直接解压到一个路径下即可完成 Kafka 的安装，这里统一将 Kafka 安装到 /usr/local 目录下，我以在 kafka-zk1 主机为例，基本操作过程如下：
[root@kafkazk1~]# tar -zxvf kafka_2.11-2.4.1.tgz -C /usr/local[root@kafkazk1~]# mv /usr/local/kafka_2.11-2.4.1 /usr/local/kafka这里我创建了一个 Kafka 用户，用来管理和维护 Kafka 集群，后面所有对 Kafka 的操作都通过此用户来完成，执行如下操作进行创建用户和授权：
[root@kafkazk1~]# useradd kafka[root@kafkazk1~]# chown -R kafka:kafka /usr/local/kafka在 kafka-zk1 节点安装完成 Kafka 后，先进行配置 Kafka，等 Kafka 配置完成，再统一打包复制到其他两个节点上。
broker.id=1listeners=PLAINTEXT://172.16.213.31:9092log.dirs=/usr/local/kafka/logsnum.partitions=6log.retention.hours=72log.segment.bytes=1073741824zookeeper.connect=172.16.213.31:2181,172.16.213.32:2181,172.16.213.33:2181auto.create.topics.enable=truedelete.topic.enable=truenum.network.threads=9num.io.threads=32message.max.bytes=10485760log.flush.interval.message=10000log.flush.interval.ms=1000replica.lag.time.max.ms=10 Kafka 配置文件修改完成后，接着打包 Kafka 安装程序，将程序复制到其他4个节点，然后进行解压即可。注意，在其他4个节点上，broker.id 务必要修改，Kafka 集群中 broker.id 不能有相同的(唯一的)。
五个节点的 Kafka 配置完成后，就可以启动了，但在启动 Kafka 集群前，需要确保 ZooKeeper 集群已经正常启动。接着，依次在 Kafka 各个节点上执行如下命令即可：
[root@kafkazk1~]# cd /usr/local/kafka[root@kafkazk1 kafka]# nohup bin/kafka-server-start.sh config/server.properties &[root@kafkazk1 kafka]# jps21840 Kafka15593 Jps15789 QuorumPeerMain这里将 Kafka 放到后台(deamon)运行，启动后，会在启动 Kafka 的当前目录下生成一个 nohup.out 文件，可通过此文件查看 Kafka 的启动和运行状态。通过 jps 指令，可以看到有个 Kafka 标识，这是 Kafka 进程成功启动的标志。
总结
整个场景总结:
要搞定10亿+请求, 经过上面深度剖析评估后需要以下资源:
| 评估项 | 具体评估需要的资源量 |
| 请求量 | 10亿+读写请求 |
QPS | 高峰期需要支撑6万QPS |
| 存储空间 | 162T |
| 物理机 | 7台 |
| 硬盘选择 | 使用普通机械硬盘 |
| 硬盘数量 | 每台服务器11块盘, 每块盘2T数据 |
| 物理机内存 | 64G勉强可以支撑,128G性能更佳 |
| CPU Core | 16核(32核性能更佳) |
| 网卡 | 千兆基本可以满足,万兆性能更佳 |
至此已经跟大家全面深度剖析了 Kafka 生产环境容量评估方案的方方面面, 下一篇会深度剖析Kafka 生产者和消费者底层原理和设计思想, 大家敬请期待.....
坚持总结, 持续输出高质量文章 关注我: 华仔聊技术
Kafka基础入门篇
Kafka三高架构设计剖析
Redis5源码分析系列之字典
觉得不错 点个在看哦