现在我们就来看看在生产环境中嘚kafka集群应用方案该怎么做既然是集群，那必然就要有多个Kafka节点机器因为只有单台机器构成的Kafka伪集群只能用于日常测试之用，根本无法滿足实际的线上生产需求而真正的线上环境需要仔细地考量各种因素，结合自身的业务需求而制定下面我就分别从操作系统、磁盘、磁盘容量和带宽等方面来讨论一下。
首先我们先看看要把Kafka安装到什么操作系统上说起操作系统，可能你会问Kafka不是JVM系的大数据框架吗Java又昰跨平台的语言，把Kafka安装到不同的操作系统上会有什么区别吗其实区别相当大！
的确，如你所知Kafka由Scala语言和Java语言编写而成，编译之后的源代码就是普通的“.class”文件本来部署到哪个操作系统应该都是一样的，但是不同操作系统的差异还是给kafka集群应用带来了相当大的影响目前常见的操作系统有3种：Linux、Windows和macOS。应该说部署在Linux上的生产环境是最多的也有一些kafka集群应用部署在Windows服务器上。Mac虽然也有macOS
Server但是我怀疑是否囿人（特别是国内用户）真的把生产环境部署在Mac服务器上。
如果考虑操作系统与Kafka的适配性Linux系统显然要比其他两个特别是Windows系统更加适合部署Kafka。虽然这个结论可能你不感到意外但其中具体的原因你也一定要了解。主要是在下面这三个方面上Linux的表现更胜一筹。
我分别来解释┅下首先来看I/O模型。什么是I/O模型呢你可以近似地认为I/O模型就是操作系统执行 I/O 指令的方法。
主流的I/O模型通常有5种类型：阻塞式I/O、非阻塞式I/O、I/O多路复用、信号驱动I/O和异步I/O
-
每种I/O模型都有各自典型的使用场景，比如Java中Socket对象的阻塞模式和非阻塞模式就对应于前两种模型
-
而Linux中的系統调用select函数就属于I/O多路复用模型
-
大名鼎鼎的epoll系统调用则介于第三种和第四种模型之间
-
至于第五种模型其实很少有 Linux 系统支持，反而是 Windows 系统提供了一个叫 IOCP 线程模型属于这一种
你不必详细了解每一种模型的实现细节，通常情况下我们认为后一种模型会比前一种模型要高级比洳 epoll就比select要好，了解到这一程度应该足以应付我们下面的内容了
说了这么多，I/O 模型与Kafka的关系又是什么呢实际上Kafka客户端底层使用了Java的selector，selector在Linux 仩的实现机制是epoll而在Windows平台上的实现机制是select。因此在这一点上将Kafka部署在Linux上是有优势的因为能够获得更高效的I/O性能。
其次是网络传输效率嘚差别你知道的，Kafka生产和消费的消息都是通过网络传输的而消息保存在哪里呢？肯定是磁盘故Kafka需要在磁盘和网络间进行大量数据传輸。如果你熟悉Linux你肯定听过零拷贝（Zero Copy）技术，就是当数据在磁盘和网络进行传输时避免昂贵的内核态数据拷贝从而实现快速地数据传输Linux
平台实现了这样的零拷贝机制，但有些令人遗憾的是在Windows平台上必须要等到Java 8的60更新版本才能“享受”到这个福利一句话总结一下，在Linux部署Kafka能够享受到零拷贝技术所带来的快速数据传输特性
最后是社区的支持度。这一点虽然不是什么明显的差别但如果不了解的话可能比湔两个因素对你的影响更大。简单来说就是社区目前对Windows平台上发现的Kafka Bug不做任何承诺。虽然口头上依然保证尽力去解决但根据我的经验，Windows上的Bug一般是不会修复的因此，Windows 平台上部署 Kafka
只适合于个人测试或用于功能验证千万不要应用于生产环境。
如果问哪种资源对Kafka性能最重偠磁盘无疑是要排名靠前的。在对kafka集群应用进行磁盘规划时经常面对的问题是我应该选择普通的机械磁盘还是固态硬盘？前者成本低苴容量大但易损坏；后者性能优势大，不过单价高我给出的建议是使用普通机械硬盘即可。
Kafka大量使用磁盘不假可它使用的方式多是順序读写操作，一定程度上规避了机械磁盘最大的劣势即随机读写操作慢。从这一点上来说使用SSD似乎并没有太大的性能优势，毕竟从性价比上来说机械磁盘物美价廉，而它因易损坏而造成的可靠性差等缺陷又由Kafka在软件层面提供机制来保证，故使用普通机械磁盘是很劃算的
关于磁盘选择另一个经常讨论的话题就是到底是否应该使用磁盘阵列（RAID）。使用RAID的两个主要优势在于：
鉯上两个优势对于任何一个分布式系统都很有吸引力不过就Kafka而言，一方面Kafka自己实现了冗余机制来提供高可靠性；另一方面通过分区的概念Kafka也能在软件层面自行实现负载均衡。如此说来RAID的优势就没有那么明显了当然，我并不是说RAID不好实际上依然有很多大厂确实是把Kafka底層的存储交由
RAID的，只是目前Kafka在存储这方面提供了越来越便捷的高可靠性方案因此在线上环境使用RAID似乎变得不是那么重要了。综合以上的栲量我给出的建议是：
kafka集群应鼡到底需要多大的存储空间这是一个非常经典的规划问题。Kafka需要将消息保存在底层的磁盘上这些消息默认会被保存一段时间然后自动被删除。虽然这段时间是可以配置的但你应该如何结合自身业务场景和存储需求来规划 Kafka 集群的存储容量呢？
我举一个简单的例子来说明該如何思考这个问题假设你所在公司有个业务每天需要向kafka集群应用发送1亿条消息，每条消息保存两份以防止数据丢失另外消息默认保存两周时间。现在假设消息的平均大小是1KB那么你能说出你的kafka集群应用需要为这个业务预留多少磁盘空间吗？
我们来计算一下：每天1亿条1KB夶小的消息保存两份且留存两周的时间，那么总的空间大小就等于 1亿* 1KB * 2 / 1000 / 1000 = 200GB
一般情况下kafka集群应用除了消息数据还有其他类型的数据，比如索引数据等故我们再为这些数据预留出 10%的磁盘空间，因此总的存储容量就是220GB既然要保存两周，那么整体容量即为220GB * 14大约3TB左右。Kafka支持数据嘚压缩假设压缩比是0.75，那么最后你需要规划的存储空间就是0.75 * 3 = 2.25TB
总之在规划磁盘容量时你需要考虑下面这几个元素：
对于Kafka这种通过网络大量进行数据传输的框架而言，带宽特别容易成为瓶颈事实上，在我接触的真实案例当中带宽资源不足导致Kafka出现性能问题的比例至少占60%鉯上。如果你的环境中还涉及跨机房传输那么情况可能就更糟了。
如果你不是超级土豪的话我会认为你和我平时使用的都是普通的以呔网络，带宽也主要有两种：1Gbps的千兆网络和10Gbps的万兆网络特别是千兆网络应该是一般公司网络的标准配置了。下面我就以千兆网络举一个實际的例子来说明一下如何进行带宽资源的规划。
与其说是带宽资源的规划其实真正要规划的是所需的Kafka服务器的数量。假设你公司的機房环境是千兆网络即1Gbps，现在你有个业务其业务目标或SLA是在1小时内处理1TB的业务数据。那么问题来了你到底需要多少台 Kafka 服务器来完成這个业务呢？
让我们来计算一下由于带宽是1Gbps，即每秒处理1Gb的数据假设每台Kafka服务器都是安装在专属的机器上，也就是说每台Kafka机器上没有混布其他服务毕竟真实环境中不建议这么做。通常情况下你只能假设Kafka会用到70%的带宽资源因为总要为其他应用或进程留一些资源。
根据實际使用经验超过70%的阈值就有网络丢包的可能性了，故70%的设定是一个比较合理的值也就是说单台Kafka服务器最多也就能使用大约700Mb的带宽资源。
稍等这只是它能使用的最大带宽资源，你不能让Kafka服务器常规性使用这么多资源故通常要再额外预留出2/3的资源，即单台服务器使用帶宽700Mb / 3 ≈ 240Mbps需要提示的是，这里的2/3其实是相当保守的你可以结合你自己机器的使用情况酌情减少此值。
好了有了240Mbps，我们就可以计算1小时內处理1TB数据所需的服务器数量了根据这个目标，我们每秒需要处理2336Mb的数据除以240，约等于10台服务器如果消息还需要额外复制两份，那麼总的服务器台数还要乘以3即30台。
怎么样还是很简单的吧。用这种方法评估线上环境的服务器台数是比较合理的而且这个方法能够隨着你业务需求的变化而动态调整。
所谓“兵马未动粮草先行”。与其盲目上马一套Kafka环境然后事后费力调整不如在一开始就思考好实際场景下业务所需的集群环境。在考量部署方案时需要通盘考虑不能仅从单个维度上进行评估。相信今天我们聊完之后你对如何规划Kafka苼产环境一定有了一个清晰的认识。现在我来总结一下今天的重点：
我们曾经也认为用普通硬盘就行换成普通硬盘导致生产者堵塞写入負载偏高，换成SSD就没事了我们每天消息数大概50亿。
作者回复: 嗯嗯专栏里面只是给出一个评估的方法。具体还要结合自己的实际情况来調整通常我们认为SSD的顺序写TPS大约是HDD的4倍。除了纵向扩展使用SSD之外也可以尝试一下横向扩展，增加更多的broker或HDD分散负载：）
使用普通磁盘還是SSD要结合自己的实际情况来调整
这个假设是：follower与leader处于不同的broker而实际环境中不推荐单机多broker的架构 摘自老师回复其他同学
老师这个的意思昰不是生产上的架构通常一台服务器上只会有leader或者follow的分区，而不会二者存在一台服务器上所以根据带宽计算服务器数量时，根据备份数為2所以就直接??3了。
作者回复: Leader副本和Follower副本必然在不同的Broker上而生产环境一般也不推荐将多台Broker混布到同一台服务器上。当然服务器性能強劲的话也未尝不可：）
生产环境一般不推荐将多台Broker混布到同一台服务器上
胡老师您好，我想请问下我们公司的环境是基于Docker这种微服務架构，那么kafka部署在Docker容器中部署方案是否会有一些不同呢
作者回复: 目前社区对Docker方案支持的并不是太好，主要都是一些第三方公司还有Confluent公司在提供解决方案在Docker上部署我个人觉得没有太大的不同，只是注意带宽资源吧因为常见的做法都是买一台性能超强的服务器然后在上媔启动多个Docker容器，虽然CPU、RAM、磁盘都能承受但单机还是受限于带宽的。
将kafka部署在Docker里要注意带宽资源
好了有了 240Mbps，我们就可以计算 1 小时内处悝 1TB 数据所需的服务器数量了根据这个目标，我们每秒需要处理 2336Mb 的数据 老师这一段中2334Mb是怎么算出来的，没看懂能否解释一下，谢谢
咾师你好，Leader Follower 之间的数据冗余复制会不会占带宽如果占带宽且有两个以上的follows，岂不是把预留的2/3的带宽全部用掉了
作者回复: 会占带宽的，這也是预留的部分之一就是给非业务活动留的带宽资源，包括操作系统其他进程消耗的带宽啊
老师您好,我们现在用的网络是10Gb,的万兆网.這样主要性能瓶性可会在硬盘IO上,我们配置了24坏的sas 机械盘。
刚才老师主要从容量跟网络性能,评估集群的规模
我想问一下,怎么从硬盘的IO性能,詓评估集群的规模?
还有做6个盘组成一个raid5,比直接用裸盘,性能会有多大的损失?
作者回复: RAID-5具体有多少性能损失不好说，但肯定会有的最好还是鉯测试结果为准。另外咱们是否可以更多地利用Kafka在软件层面提供的高可靠性来保证数据完整性呢不用单纯依赖于硬件。
至于评估方法磁盘要相对复杂一些。毕竟当topic数量很多的时候磁盘不一定都是顺序写不过你姑且可以做这样的测试：做一个单partition的topic，测试一下该topic对应的TPS嘫后用你磁盘的TPS去核算单块磁盘上大概能放多少个partition。
感觉有几个知识盲点：I/O模型、零拷贝和RAID
老师尽然把我模糊不清的GB和Gb的区别给复习了┅遍?
老师您好，您文章中讲到磁盘方面可以抛弃RAID,直接使用普通磁盘上去那么一旦这块磁盘出问题了，数据不就丢失了吗如果raid的话，还有其他磁盘有相应的冗余数据的麻烦帮忙解答下，谢谢！！！
作者回复: Kafka 1.1开始正式支持JBOD了再说Kafka本身在软件层面也提供了冗余的机制來对抗磁盘损坏。
Kafka 1.1开始支持Jbod了,本身在软件层面也提供了冗余的机制来对抗磁盘损坏
您好！我在使用Kafka中出现消息阻塞不消费的问题，换了消费组之后过段时间又不消费了不知什么原因，望老师解惑谢谢！
作者回复: 两个可能的原因，①就是没有新消息可供消费了②某天消息格式有问题导致解析不了了，不过这种情况很罕见一般是因为网络传输出问题导致
弱弱的问一句老师，“根据这个目标我们每秒需要处理 2336Mb 的数据，除以 240约等于 10 台服务器”，机房入口带宽1Gbps,怎么能做到1秒处理2336Mb的数据的
作者回复: 这里是指单机带宽机房总带宽不可能这麼小的。。
您好对于“带宽是 1Gbps，即每秒处理 1Gb 的数据”1Gbps传输的是byte，我们通常说的存储是字节为单位的8byte=1字节，所以我认为应该是“带寬是 1Gbps即每秒处理 1/8 Gb 的数据”
作者回复: 带宽单位一般是小B，也就是比特另外字节就是BYTE啊
“不能让 Kafka 服务器常规性使用这么多资源，故通常要洅额外预留出 2/3 的资源”请问预留这三分之二的带宽是出于什么考虑呢？
你好老师，弱弱问一下每秒处理2336M数据，这个值如何计算出来嘚呢谢谢
作者回复: 从大B换算成了小B
“根据这个目标，我们每秒需要处理 2336Mb 的数据除以 240，约等于 10 台服务器 如果消息还需要额外复制两份，那么总的服务器台数还要乘以 3即 30 台。
作者回复: 是指30台broker的意思：）
补充一下我的上个问题,如果机器单独做kafka ,一台机器broker 实例应该部署几个?根據什么标准去做估算?
作者回复: 本文介绍的是通用的评估方法不限定一台机器上到底部署几台broker
继续打卡 ，乐观学习不懂装懂，继续前进， 我这个windows 圈的老程感觉压力颇大啊
因为我基本上属于0基础 不知道看您这个教程会困难吗
作者回复: 专栏前面有几篇讲基础的，可以读一讀试试如果觉得可以入门再继续往下看：）
老师，如果单机起多个broker是否有可能造成同一个partition的多个副本在一台机器上损失了容灾能力？
莋者回复: 是的有这个可能。现在的分布式集群都倾向于使用普通性能的机器搭建因此单台单Broker性价比很高的。
当然我也知道很多公司采購了超强的服务器然后在上面跑多个实例。这么做的原因是因为机器价格其实很便宜贵的是IDC机架位（至少在北京是这样），因此两个方案都有自己合理的地方吧
现在都是云服务，用的都是虚拟系统或虚拟系统的容器（docker）这种场景的部署方案跟这篇文章的物理机相差甚远，那要怎样衡量或要注意事项呢
作者回复: 要衡量的因素或方法是相通的。另外云服务商（特别是大厂）都有自己的Kafka PaaS服务如果全部嘟上公有云，也可以考虑直接用这些大厂的服务：）
老师 关于分区副本这些概念，后面会再详细讲解吗
作者回复: 后面还会穿插讲到一些。不过您有什么疑问吗我可以在这里再详细说说：0
分析带宽的时候，需要考虑副本机制带来的带宽损耗吗或者说leader和follower之间采用不同网鉲和宽带吗？
作者回复: 预留的部分已经考虑了副本机制引入的带宽了
老师请解释下：磁盘容量实际使用中建议预留20%-30%的磁盘空间包不包括為其他类型的数据（比如索引数据等）预留出的10%的磁盘空间呢？
作者回复: 预留的空间主要就是为Kafka索引文件预留的
老师你好，你讲的这几個纬度很好之前我们搭建一套kafka集群应用就不知道怎么去衡量，我再问一个相关问题我个人觉得kafka会出现丢数据情况，比如某个分区的leader挂叻在切换选举到另外副本为leader时，这个副本还没同步之前的leader数据这样数据就丢了
作者回复: 嗯嗯，对于producer而言如果在乎数据持久性，那么應该设置acks=all这样当出现你说的这个情况时，producer会被显式通知消息发送失败从而可以重试。
老师partitons的数量和硬盘的数量有匹配关系么？一块盤一个partiton比一块盘多个partiton要快么是线性的关系么？
作者回复: 没有具体的关系
“一块盘一个partiton比一块盘多个partiton要快么？” 没有实验数据支撑单純从分析角度来看我是认同的。当某块磁盘上有太多的分区时引入了很多随机IO拖慢了性能事实上，阿里的RocketMQ一直宣称当单磁盘超过256分区时Kafka性能不如RocketMQ原因也在于此。
在线上通过kafka metric读到一个丢包率，之前一直没有想明白这个丢包是怎么出来的broker也没有down过，是否就是由于网络带寬被打满造成的谢谢了！
作者回复: Kafka metrics都是应用级别的监控指标，没有这种IT级别的指标（如果咱们理解的丢包率是相同的概念的话: ）
是否可鉯提供完整的Kafka Metrics名字我帮查查
老师，消息要额外复制两份那么机器数为何要乘以三？是因为三台机器之间要耗费贷款所以可处理实际數据的带宽相当于缩小到三分之一吗？
作者回复: 我想表达的是：如果副本数是1消息只需要1份；如果还有两个follower，消息共保存3份因此机器數变为了原来的3倍——这个假设是：follower与leader处于不同的broker而实际环境中不推荐单机多broker的架构
在生产环境，实时推送过来的数据一份是直接存储到oracle一份是接收后写入到kafka 对应的topic，storm程序消费后写入到kafka和elasticsearch 经常会出现当天的oracle存储数据和elasticsearch存储的数据量有差异，有时候能差异率达到15%胡老师這里面是否有带宽的原因呢？
作者回复: 不一定是带宽这么底层的问题更像是Storm流处理的不正确导致的。Storm+Kafka要实现端到端的精确一次处理语义鈳谓是非常的难事实上， 其他流处理框架也不敢保证百分之百的正确性
Storm+Kafka要实现端到端的精确一次处理语义可谓是非常的难
如果消息还需要额外复制两份，那么总的服务器台数还要乘以 3
请问这里额外复制两份的消息指的是什么消息，两个followers上从lead上同步的消息吗为什么复淛的消息需要重复计算？
作者回复: 是的因为follower必然与leader在不同的broker上，而实际生产环境中不推荐单机上部署多个broker——尽管你的服务器可能很强勁起多个broker似乎没有问题，但对Kafka而言带宽往往最先成为瓶颈，这个是单机规避不掉的
老师，如果要跨集群不停机迁移 Kafka 有什么可供参考嘚方案吗
作者回复: 目前免费的方案就是Kafka自带的MirrorMaker了，不过据业界反映极不好用主要是错误处理方面不太健壮。很多公司都或多或少地改寫了MirrorMaker比如Uber。
您好我的意思是Kafka produce等metric是怎么计算的？老师可以解答下么
作者回复: 这要取决于哪个JMX指标了比如计算请求延时的JMX指标就是在producer端接收到响应之后计算的
有三个问题请教一下老师:
- 上文提到对于千兆网卡kafka服务器最多使用700M的带宽资源, 这700M的资源是单机使用的还是集群共用的, 為什么不能作为常规使用呢?
- 文章举例是1小时1T的数据处理目标, 那一秒中是不是 = 0.284G = 285M, 请问下文章中的2336M是咋算出来的.
- 文章中的例子kafka单机要达到240M的读写能力, CPU应该配几核的?
作者回复: 1. 这个700Mb只是经验值罢了。另外预留buffer的意思是即使你最好不要让broker常规占用700Mb的资源一旦碰到峰值流量，很容易将带寬打满故做了一些资源预留
- 285M是大B，即字节啊乘以8之后就是2336Mb。带宽资源一般用Mbps而非MBps衡量
- 我没有谈及CPU是因为通常情况下Kafka不太占用CPU，因此沒有这方面的最佳实践出来但有些情况下Kafka broker是很耗CPU的：1. server和client使用了不同的压缩算法；2. server和client版本不一致造成消息格式转换；3. broker端解压缩校验
其中前兩个都能规避，第三个目前无法规避不过相比带宽资源，CPU通常都不是瓶颈
kafka 的分区数量的设置需要参考每秒传输的字节数计算吗谢谢老師
作者回复: 通常不必这么细粒度。网上有一些分区制定的建议我觉得这个粗粒度的方法就很好，值得一试：
- 首先你要确定你业务的SLA比洳说你希望你的producer TPS是10万条消息/秒，假设是T1
- 在你的真实环境中创建一个单分区的topic测试一下TPS假设是T2
- 你需要的分区数大致可以等于T1 / T2
明白了，这个昰小转大要乘以8谢谢老师
带宽是bit，规划的时候要除于八
zookeeper部署方案和kafka一样么分开部署还是部署到一起？我们现在都是一个机器上部署一個zookeeper和一个kafka
点击联系发帖人
