架构-大数据集群资源评估方法

心已赠人 2023-02-14 10:04 2阅读 0赞

# 架构-大数据集群资源评估方法 #

# 转载声明 #

***本文大量内容系转载自网络，有删改，并参考其他文档资料加入了一些内容：***

# 1 资源需求背景 #

二手电商网站需要构建一个Kafka集群，目标是每天抗住10亿请求量。

# 2 二八法则之QPS预估 #

每天集群需要承载10亿数据请求，对于普通电商网站而言，一般0点到上午8点请求量很小。

使用二八法则估计：

1.  80%的数据( 8亿)会在其余16个小时（8点-24点）涌入
2.  而且8亿的80%的数据( 6.4亿)会在这16个小时的20%时间( 3小时内)涌入:
    
    QPS=6 4000 0000 / (3*60*60)=60000
    
    即预估结果为Kafka集群需要在业务最高峰期抗住 60000/s 的 QPS。

# 3 存储估算 #

## 3.1 请求量、数据大小与数据总量 ##

*  每天10亿请求，每个请求大小50KB，则数据总量为46TB。
 *  如果还要保存2副本，则总量为46\*2=92T 。
 *  如果还需要保留最近3天的数据，则总量进一步增加为92 \* 3= 276T

**注: 1条消息50KB是该业务的具体情况，已经相当大了，所以需要根据提业务数据大小进行计算。**

## 3.2 适当提高资源预估上限(3倍) ##

如果资源充足，让高峰期QPS控制在集群能承载的总QPS的30%左右是比较安全的策略，即应设计kafka集群承载QPS上限为`20万~30万 / s` 才是安全的。

根据经验，对该业务来说一台物理机可稳定支持4万QPS，所以从QPS的角度来说预估需要物理机5-7台。

## 3.3 磁盘数量 ##

5台物理机，需要存储3天总共276T的数据，每台存储约60T。

一般的配置是11块7T的盘,就行了。

为Kafka接收log配置多个盘的目录：

log.dirs=/data1,/data2,/data3,....

## 3.4 磁盘类型 ##

结论-Kafka使用机械硬盘足够。

是需要SSD固态硬盘，还是普通SAS机械硬盘?

*  SSD就是固态硬盘，比机械硬盘要快得多，且主要是快在磁盘随机读写，没有寻道时间。
 *  Kafka是顺序写的，机械硬盘顺序写的性能跟内存读写的性能差不多，所以对于Kafka集群使用机械硬盘就可以了。

# 4 内存估算 #

## 4.1 Kafka读写流程回顾 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JhaWNob3VmZWk5MA_size_16_color_FFFFFF_t_70]

## 4.2 内存评估 ##

Kafka自身的JVM是用不了过多堆内存的，因为kafka设计就是规避掉用JVM对象来保存数据，避免频繁ful lgc导  
致的STW问题。

所以一般kafka自身的JVM堆内存分配个6G左右就够了，剩下的内存全部留给os cache。

## 4.3 实际计算 ##

经过梳理，公司集群大概有100个topic的数据放在os chache里效果是最好的：

*  100个topic，一个topic有5 个partition，那么总共会有500个partition。
 *  每个partition的Log文件大小是1G，我们有2个副本，也就是说要把100个topic的partition数据都驻留在内存里需要`500 * 1 * 2 = 1000G`的内存。
 *  我们现在有5台服务器，所以平均下来每台服务器需要200G的内存。但是其实partition的数据我们没必要所有的都要驻留在内存里面，只需要25%的数据在内存就行，即200G \* 0.25 = 50G就可以了。

所以我们可以最少选择64G内存的服务器，当然如果是128G内存那就更好，可以放更多数据到os cache。

# 5 CPU估算 #

## 5.1 概述 ##

CPU规划，主要是看Kafka进程里会有多少个线程，线程主要是依托多核CPU来执行的，如果线程特别  
多，但是CPU核很少，就会导致CPU负载很高，会导致整体工作线程执行的效率不太高。

## 5.2 Kafka线程模型 ##

那Kafka进程里面大概有多少线程呢？  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JhaWNob3VmZWk5MA_size_16_color_FFFFFF_t_70 1]

1.  1个Accept线程
2.  默认的3个Process线程（一般会设置为9个）
3.  默认的8个RequestHandler工作线程（可以设置为32个）
4.  清理日志的线程
5.  感知Controller状态的线程
6.  副本同步的线程
7.  …

估算下来Kafka内部有100多个线程

## 5.3 实际计算 ##

4个cpu core，一般来说几十个线程，在高峰期CPU几乎都快打满了。

8个cpu core，也就能够比较宽裕的支撑几十个线程繁忙的工作。所以Kafka的服务器一般是建议16核，基本上可以hold住一两百线程的工作。当然如果可以给到32 cpu core那就最好不过了！

# 6 网络资源估算 #

## 6.1 Kafka网络架构 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JhaWNob3VmZWk5MA_size_16_color_FFFFFF_t_70 2]

## 6.2 实际计算 ##

每秒两台broker机器之间大概会传输多大的数据量？依据前文二八法则预估，高峰期每秒大概会涌入6万个请求，每台处理约10000个请求，每个请求50KB，故每秒约进来488MB数据。且我们一共2个副本，需要同步数据，故高峰期的时候需要488M \* 2 = 976MB/s的网络带宽，所以在高峰期的时候，使用千兆网卡，网络还是非常有压力的。

# 7 总结 #

*  10亿请求，6w/s的吞吐量，276T的数据，5台物理机
 *  硬盘：11（SAS） \* 7T，7200转
 *  内存：64GB/128GB，JVM分配6G，剩余的给os cache
 *  CPU：16核/32核
 *  网络：千兆网卡，万兆更好

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JhaWNob3VmZWk5MA_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200602222125743.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JhaWNob3VmZWk5MA==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JhaWNob3VmZWk5MA_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200602233002716.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JhaWNob3VmZWk5MA==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JhaWNob3VmZWk5MA_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200602233729681.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JhaWNob3VmZWk5MA==,size_16,color_FFFFFF,t_70