【kafka】kafka部署硬件考虑
前⾔
本⽂所写的，偏重于架构师的内容，所以阅读的⼩伙伴，要有综合的⼀些能⼒，否则，你可能会被其中的计算给弄晕，不过既然，阅读我的⽂章嘛，都是从基础开始写起，所以还是很好读的。
本⽂要讨论的话题是，当我搭建⼀个kafka集的时候，我们需要考虑的问题。
不能张⼝就来，我需要什么什么配置的机器之类的，那是耍流氓，我们要考虑的有理有据才可以对吧。
⽅案背景
假设我们要搭建⼀个每天要承载10亿数据的kafka集。⼀天24⼩时，晚上12点到凌晨8点⼏乎没多少数据，使⽤⼆⼋法则估计，也就是80%的数据（8亿）会在16个⼩时涌⼊，⽽且8亿的80%的数据（6.4亿）会在这16个⼩时的20%时间（3⼩时）涌⼊。QPS计算公式
=640000000÷(3_60_60)=6万，也就是说⾼峰期的时候，咱们的kafka集要扛住眉每妙6万的并发。
磁盘空间计算，每天10亿数据，每条50kb，也就是46T的数据，保存2副本，462=92T，保留最近三天的数据，故需要923=276T
QPS⾓度
部署kafka，Hadoop，mysql，⼤数据核⼼分布式系统，⼀般建议⼤家直接采⽤物理机，不建议⽤⼀些低配置的虚拟机，QPS这个东西，不能说你只要6万QPS，你的集就刚好⽀撑6万QPS就可以了，加⼊说你只要⽀撑6WQPS，2台物理机绝对够了，单台物理机部署kafka⽀撑个⼏万QPS是没问题的，但是，尽量让⾼峰QPS控制在集能承载的总QPS的39% 左右，也就是总QPS为20万～30万才是安全的，所以⼤体上来说，需要5到7台物理机，每台要求在每妙⼏万条数据就可以了。
磁盘⾓度
磁盘数量，我们现在需要5台物理机，需要存贮276T的数据，所以⼤概需要每台存贮60T的数据，公司配置⼀般是11块盘，这样的话，⼀个盘7T就搞定了。
SAS盘还是SSD盘
我们都知道ssd盘⽐sas盘要块，但是他快的是随机读写能⼒，那kafka呢？kafka是顺序写⼊的，所以这个时候，ssd盘的作⽤就不是很⼤，所以，我们是可以采⽤sas盘的，也就是机械硬盘的，当然了，能⽤ssd盘更好。
内存⾓度
前提预知条件，kafka写⼊数据是先写到缓存中，也就是os cache中，然后再写⼊磁盘中。
kafka⾃⾝的jvm是⽤不了过多的对内存的，因为kafaka设计就是规避掉⽤jvm对象来保存数据，避免频繁fullgc导致的问题，所以⼀般kafka⾃⾝的jvm堆内存，分配个10G左右就够了，剩下的内存全部都留给os cache。
那么服务器需要多少内存呢？我们估算⼀下，⼤概有100个topic，所以要保证有100个topic的leader partition的数据在os cache，按照⼀个topic有5个分区，总共有500个partition，每个partition的⼤⼩是1个G，按照两个副本，也就是1千G，如果都要驻留在内存中的话，需要1000G的内存，现在有5台服务器，每个平均分⼀下，就是200G，当然了，并不是所有的数据都需要留在内存，所以按照25% 的计算就⾏了，也就是我们需要50G的内存，然后再留给jvm为10G，⽐较接近的，我们可以选择64G的内存服务器就可以了，当然了，内存肯定是越⼤也好，⽐如我们选择128G的。
cpu⾓度
cup的规划，主要是看你的线程有多少个线程。
所以到这⾥，我们来插播⼀个关于kafka的⽹络传输过程。
这个图⽚字体看起来⽐较⼩，但是你可以把它下载下来看，主要说⼀下他的过程，这个过程是kafka及其
核⼼的过程。
⾸先客户端有500个消费者，200个⽣产者，那么他⾸先会将这些请求发送给Acceptor，然后acceptor，这些请求叫socketchannel，然后这些socketchannel就会被发送给processor，默认情况下，有三个proccessor，然后这些proccessor就会将请求发送给request队列，这个时候后⾯默认有8个线程池来请求这些request队列⾥⾯的内容，这些线程池就会⽤零拷贝的⽅式直接写⼊到磁盘中，当然了，零拷贝本⾝也实现写⼊os cache，然后，线程池处理完毕，就会发送给reponse队列，告诉客户端写⼊成功了，当然了，这个成功，我们再写代码的时候会有三种配置，后⾯我会写通过代码的⽅式配置的⽂章的时候会提到这个参数配置的。
那么我们在搭建kafka集的时候，会关注这样两个参数，分别为
# The number of threads that the server uses for receiving requests from the network and sending responses to the network
numwork.threads=3
# The number of threads that the server uses for processing requests, which may include disk I/O
num.io.threads=8
numwork,threads=3这个参数就是processor，
num.io.threads=8，这个就是线程池。
我们在搭建集的时候，建议将它扩⼤，⽐如numwork.threads这个可以搞成6个或者9个，num.io.threads=8这个我们可以将它搞成24个，或者32个，这样⼦，线程⼀下就可以增⼤很多倍。
有了这个知识之后，我们就可以来具体的说cpu了。
我们来算⼀算这个线程数，⾸先会有9*32=288，在加上定期定期清理7天前数据的线程，加起来有⼏百个了，这样⼦，根据经验4个Cpu core，⼀般来说⽀持个10⼏个线程的话，在⾼峰期是完全打满了，所以我们选择8个cpu core，这样⼦就⽐较宽裕⽀持个⼏⼗个线程繁忙的⼯作，所以，我们采⽤16核的，当然了，采⽤32 cpu core更好了。
⽹卡⾓度
现在的⽹基本上就是千兆ka，还有万兆⽹卡，kafka集之间，broker和broker之间是会做数据同步的，因为leader要同步数据到follwer上⾯去，所以不同服务器之间的传输⽐较频繁，根据之前测算的qps计算，每妙有6万，按照每天请求处理1000个请求，每个请求50kb，⼤概是488M，当然了，我们还有副本，所以要有两倍，于是⼤概是就是976M/s的⽹路带宽。于是如果在⾼峰期的话，采⽤千兆⽹络，就会
有压⼒的。
于是经过上⾯的分析，我们⼤概得出结论。
配置总结
5台物理机
硬盘：11 （sas） * 7T，7200转
内存：64G/128G，jvm分配10G，剩余的给os cache
kafka为什么那么快
cpu：16核/32核
⽹络：千兆⽹路/万兆⽹络

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。