# 大数据集群资源评估
# 集群资源评估
# 某二手电商需要构建一个Kafka集群，该集群的目标就是每天要hold住10亿请
# QPS估算
每天集群需要承载10亿数据请求，一天24小时,对于电商网站，晚上12点到凌晨8点这8个小时几乎没多少数据。 使用二八法则估计，也就是80%的数据(8亿)会在其余1 6个小时涌入，而且8亿的80%的数据(6.4亿) 会在 这1 6个小时的20%时间(3小时)涌入。 QPS计算公式=640000000+(36060)=6万，故高峰期Kafka集群需要要抗住每秒6万的并发。
# 存储估算
每天10亿数据，每个请求50kb,也就是46T的数据。如果保存2副本，462=92T, 保留最近3天的数据。故需要923=276T 注:一条消息50kb是我们公司的情况，这个值是偏大的，很多公司的- -个Kafka的请求里数据达不到50k这么大。
# QPS角度
如果资源充足，让高峰期QPS控制在集群能承载的总QPS的30%左右，故目前kafka集群能承载的总QPS为 20万~30万才是安全的,根据经验- -台物理机能支持4万QPS是没问题的，所以从QPS的角度讲，需要物理 机5-7台。
# 磁盘的数量
需要多少个磁盘?
5台物理机，需要存储276T的数据，每台存储60T的数据，- -般的配置是11块盘，一个盘7T就搞定。
# 磁盘的类型
是需要SSD固态硬盘，还是普通SAS机械硬盘? SSD就是固态硬盘，比机械硬盘要快，SSD的快主要是快在磁盘随机读写 Kafka是顺序写的，机械硬盘顺序写的性能机会跟内存读写的性能是差不多的，所以对于Kafka集群使用机 械硬盘就可以了。
# 内存角度
Kafka自身的jvm是用不了过多堆内存，因为kafka设计就是规避掉用jvm对象来保存数据,避免频繁fullgc导 致的问题，所以- -般kafka自身的jvm堆内存，分配个6G左右就够了,剩下的内存全部留给os cache。
每台服务器需要多少内存
经过梳理，公司集群大概有100个topic,这100个topic的partition的数据在os chache里效果是最好的。100个topic, 一个topic有5 个partition。那么总共会有500个partition。每个partition的Log文件大小是1G,我们有2个副本，也就是说要把1 00个topic的partition数据都驻留在内存里需要1000G的内存。我们现在有5台服务器，所以平均下来每天服务器需要200G的内存，但是其实partition的数据我们没必要所有的都要驻留在内存里面，只需要25%的数据在内存就行，200G * 0.25 = 50G就可以了。所以- -共需要56G的内存，故我们可以挑选64G内存的服务器也行，当然如果是128G内存那就更好。
# CPU角度
CPU規刻，主要是看Kafka迸程里会有多少个銭程J銭程主要是依托多核CPU来抗行的，如果銭程特別多，但是CPU核很少，就会尋致CPU奐載很高，会尋致整体工作銭程抗行的效率不太高。
- Accept线程
- 默认的3个Process线程( -般会设置程9个)
- 默认的8RequestHandle线程(可以设置成32个)
- 清理日志的线程
- 感知Controller状态的线程
- 副本同步的线程 估算下来Kafka内部有100多个线程
4个cpu core, -般来说几十个线程，在高峰期CPU几乎都快打满了。8个cpu core,也就能够比较宽裕的支撑几十个线程繁忙的工作。所以Kafka的服务器一般是建议16核， 基本上可以hold住一两百线程的工作。当然如果可以给到32 cpu core那就最好不过了!
# 网卡角度
- 接受请求
- 副本同步
每秒两台broker机器之间大概会传输多大的数据量?高峰期每秒大概会涌入6万个请求，约每台处理10000个请求，每个请求50kb，故每秒约进来488M数据，我们还有副本同步数据，故高峰期的时候需要488M * 2 = 976M/s的网络带宽，所以在高峰期的时候，使用千兆带宽，网络还是非常有压力的。
# 集群资源规划
1 0亿请求，6w/s的吞吐量，276T的数据，5台物理机 硬盘: 11 (SAS) * 7T，7200转 内存: 64GB/1 28GB, JVM分配6G,剩余的给os cache CPU: 16核/32核 网络:千兆网卡，万兆更好
← Kafka核心技术与实战 Hbase →