kafka配置参考

CPU

Kafka是I/O密集型而非计算密集型的框架，所以对CPU的需求是各个指标里最宽松的，消耗CPU的点主要在于消息的压缩和解压缩。一个Kafka Broker节点往往要承载许多个Topic Partition并与许多个Producer/Consumer交互，所以并行度（核心/线程数）要比单核性能（频率）更重要。

一般来讲单节点8C/16T，主频2GHz以上（按Broadwell架构计）就可以满足小型生产环境，负载比较重的集群可以配到12C/24T甚至16C/32T。注意根据CPU规格的不同，Broker的num.network.threads和num.io.threads参数也要适当改变。

内存

nsumer在消费时能够命中Broker的page cache，那么消息的读写就可以空中接力而不必执行磁盘I/O，所以Broker内存大小与Consumer的吞吐量关系密切。Kafka集群最好是专用的，不混合部署其他吃内存的服务，因为它们会挤占Kafka的page cache空间，产生脏页，造成性能下降。

现在内存的价格并不高，一般64GB是较低要求，128GB应付高吞吐的场景也轻松愉快了。

硬盘

Producer发送的消息最终都要持久化，所以Broker的硬盘配置与Producer的吞吐量关系密切。Kafka的数据盘最好与系统、ZooKeeper等的存储分开，以免拖累性能。

HDD vs SSD？

毫无疑问，SSD的性能（尤其是随机读写性能）比HDD要高不少。但是Kafka是顺序读写的，SSD的优势并没有那么大，并且考虑到成本问题，普通7.2K/10K转的SAS/SATA HDD就足够了。

JBOD vs RAID？

为了尽量增大吞吐量，最好使用多块磁盘。JBOD和RAID是最常见的两种组织多块磁盘的方法。

JBOD即“Just a Bunch of Disks”的缩写，中文意译为“磁盘簇”，就是指多块磁盘简单地挂载为一个或多个不同的逻辑设备，只提供容量与并行度的增加，不提供任何冗余。示意图如下。

RAID即“独立磁盘冗余阵列”（Redundant Array of Independent Disks），在大学操作系统课程中肯定讲过，所以不再赘述。RAID能够提供读写性能提升和/或冗余机制，生产环境中常用的RAID10的示意图如下。

那么该用哪种呢？Kafka在应用层提供数据冗余（副本）机制，所以选择JBOD是完全可行的，但是如果Partition之间的数据倾斜比较严重，可能会造成不同磁盘占用率相差悬殊。对数据安全性和性能要求比较高的场合可以选择RAID10，并且RAID可以在底层平衡磁盘用量，不过可用的存储空间会减半，成本也会高一些。

容量

硬盘容量需要根据消息数量、消息平均大小、副本数、保留时长（即log.retention.hours）和压缩率来综合考虑。举个栗子，业务端每天产生10亿条消息，每条消息平均大小为1KB，副本数为2，消息保留一周，那么可计算出集群内至少需要预留的磁盘空间为14TB。

网络

Kafka集群内外的数据交换非常频繁，可以说网络带宽是制约吞吐量的重要瓶颈，需要根据业务忙时的尖峰流量来配置。目前数据中心的服务器配置的基本都是万兆（10 Gbps）网卡，问题不大。