wordpress微云解析插件seo优化专员编辑
编写目的意义
应用场景为如果有租户需要部署kafka集群，并给出业务压力，根据业务评估kafka资源情况，如cpu 磁盘 内存 带宽等维度。为业务解决因资源过小故障和新业务部署提供了参考和计算方法，减少后续的维护成本
资源容量评估
本文档只提供计算逻辑和评估模型，具体业务资源需求，需要根据下面逻辑严格计算和评估。Kafka需要大量cpu和内存，消耗都比较大。下面通过场景驱动的方式来深度剖析 Kafka 生产级容量评估方案如何分析,申请和实施。
kafka容量评估需求场景分析
场景说明
假设kafka集群平均承受1亿次日请求量，每天单次请求1条日志，每天总共的日志条数是1亿1条=1亿条。
每条日志大小约 : 0.5k-10k。 我们取10k。个别业务也有几十k的，极个别公司一条日志也有几MB的，比较少见。
每天总数据量 ：1亿条 10k≈10亿k（每天产生数据量约等于953G）
高峰期计算 : 953G * 2倍=1907G。（峰值每天1907G数据量。极端情况可以乘以数十倍，根据业务场景评估）
kafka容量评估之磁盘
磁盘容量规划考虑因素：
- 每天消息量
- 新增消息数；
- 消息保留时长；
- 平均消息大小；
- 副本数；
- 消息是否启用压缩。
- 预留磁盘空间
机械硬盘 or 固态硬盘SSD
两者主要区别如下：
SSD的优点是速度快，日常的读写比机械硬盘快几十倍上百倍。缺点是单位成本高，不适合做大容量存储。
HDD的优点是单位成本低，适合做大容量存储，但速度远不如SSD。
首先SSD硬盘性能好，主要是指的随机读写能力性能好，非常适合Mysql这样的集群，而SSD的顺序读写性能跟机械硬盘的性能是差不多的。机械硬盘性价比高，完全可以满足集群的使用。Kafka 写磁盘是顺序追加写的，所以对于 kafka 集群来说，使用普通机械硬盘就可以了，除非有极端场景需求。如果预算充足可考虑SSD。
一堆普通磁盘（JBOD） 与 磁盘整列（RAID) 选择：JBOD，性价比高，使用没有问题。RAID，如果预算充足就考虑，可以提供冗余的数据存储空间，天然负载均衡。
每台服务器需要多少块硬盘
Kafka的每条消息都保存在实际的物理磁盘中，消息默认会被broker保存一段时间之后清除。
假设业务要求每个topic保留3个副本，那么每天业务数据量为1907G * 2倍=3814G
假设消息保留3天，那么每天业务实际存量为3814G * 3倍=11442G
假设根据磁盘容量安全需要，需要有20%的磁盘冗余，那么kafka集群全部磁盘空间一共为11442G/80%=14302G (14T)
根据评估结果一共需要存储14T数据，我们可以设置3节点kafka集群，大约每台机器需要存储5T数据。
kafka容量评估之内存
jvm堆内存评估
Kafka 读写数据的流程主要都是基于os cache，所以基本上 Kafka 都是基于内存来进行数据流转的，这样的话要分配尽可能多的内存资源给os cache。
kafka的核心源码基本都是用 scala 和 java (客户端)写的，底层都是基于 JVM 来运行的，所以要分配一定的内存给 JVM 以保证服务的稳定性。对于 Kafka 的设计，并没有把很多的数据结构存储到 JVM 中，所以根据业界最佳实践经验给 JVM 分配6~10G就足够。
物理内存评估
如果要保证这所有 partition 的最新的 .log 文件的数据都在内存中，这样性能当然是最好的，但是没有必要所有的数据都驻留到内存中，只保证10%左右的数据在内存中就可以了，这样大概需要953G* 10% = 95G内存，外加上面分析的JVM的6G*3=18G，总共需要113G内存。还要保留一部分内存给操作系统和业务高峰使用，我们需要给业务高峰留30%的内存，这样总内存大约需要113/70%=161G内存，再加上给操作系统留出12G内存。故我们选择173G内存的服务器是非常够用了，我们可选用64G内存型号机器，可以考虑选用3台即可。
kafka容量评估之CPU
CPU Core分析
我们评估需要多少个 CPU Core，主要是看 Kafka 进程里会有多少个线程，线程主要是依托多核CPU来执行的，如果线程特别多，但是 CPU核很少，就会导致CPU负载很高，会导致整体工作线程执行的效率不高,性能也不会好。所以我们要保证CPU Core的充足，来保障系统的稳定性和性能最优。
Kafka不算是cpu消耗型服务，不是计算密集型系统，应尽可能追求多核而非高时钟频率。但是如果client端启用了消息压缩，除了必要的CPU资源外，broker端也有可能需要大量的CPU资源。
还有kafka是否启用SASL等机制认证，也会消耗cpu。一个 kafka 服务启动后，会有至少100多个线程在跑。
kafka对计算处理应用场景，客户端为了优化网络和磁盘空间，会对消息进行压缩。服务器需要对消息进行批量解压，设置偏移量，然后重新进行批量压缩，再保存到磁盘上。
最重要、最消耗时间的就是下面3种线程：
如果单台服务器给 32 个 cpu core，建议分为24+8两个部分。
num.io.threads=8负责写磁盘的线程数，默认8，整个参数值要占总核数的 50%。24 * 50% = 12核
num.replica.fetchers=1副本拉取线程数，默认1，这个参数占总核数的 50%的 1/3。24 * 50% * 33% =4核
num.network.threads =3 数据传输线程数，默认3，这个参数占总核数的 50%的 2/3。24 * 50% *66% = 8核
以上共计24核，剩余8核给其他线程使用
kafka容量评估之带宽
Kafka是在网络间传输大量数据的分布式数据管道，带宽资源很重要，并且容易成为瓶颈。
kafka支持多个消费者，造成流入和流出的网络流量不平衡，从而让情况变得更加复杂。集群复制和镜像也会占用网络流量。如果网络接口出现饱和，那么集群的复制出现延时就在所难免。
总结起来，对于带宽资源的规划，你需要考虑以下几个因素：
- 网络带宽：根据网络环境确定每秒处理的数据量。
- 带宽利用率：根据实际情况确定 Kafka 服务器使用的带宽比例。
- 预留资源：为了避免网络丢包，额外预留一部分带宽资源。
- 数据处理目标：根据业务需求确定每秒需要处理的数据量。
- 消息复制：如果消息需要复制，考虑复制的数量。
我们目前服务器绝大多数都是万兆带宽。根据文档场景假设，Kafka集群每天处理数据量约等于953G，平台一天每小时要处理40G的数据，平均每秒处理11M数据。
假设需要带宽冗余，使用30%带宽应对网络突发情况。那么实际要求带宽为11M/70%=16M/s
假设每天服务器给kafka进程的带宽资源为60%，那么单台kakfa服务器带宽需要：16M/60%=27M/s
带宽单位是bit比特，1byte=8bit。实际上百兆带宽100Mbps/8 =12.5M/s。千兆带宽实际上125Mb/s。万兆带宽实际上1250Mb/s。
综上所述，单台物理机万兆带宽足够kafka集群使用。Kafka集群仍可选3台做业务支撑。