Kafka集群部署规范

1.CPU规格与挂盘数量的关系规范

根据FusionInsight HD产品文档中所述的硬件要求来选择合适的部署方式。对于kafka组件需要关注机器中具体处理器超线程个数，即processor的个数，可以通过命令：grep -c processor /proc/cpuinfo 查看。这个参数代表了整个机器的处理能力，kafka默认，建议：每台机器最大挂盘数量 <= processor / 2

例如：机器的processor数量为24，那么这个机器的最大挂盘数为12块。

2.磁盘挂载规范

Kafka在1.x版本（FI对应版本为6.5.x）之前，对于磁盘容错方面做的不够完善，如果单台节点如果出现一块磁盘故障，那么这个节点的kafka进程就会出现异常，因此，不建议每个broker节点挂载多个单盘。

使用建议：建议每台机器使用raid5来挂载磁盘。单台机器可以挂载多个raid5的逻辑盘，每块逻辑盘的物理盘个数可以按照需求指定。

3.Topic创建规范

kafka的一个topic通常代表了一类数据，合理的创建topic是保持kafka集群健壮的基本因素。 标准的topic使用建议如下：

1. 不可无休止的创建而不删除topic。kafka集群的topic数量（或者说topic的分区总量）有一定限，上限根据集群的性能而定。一旦整个集群的分区总量到达上限，会导致kafka集群无法正常服务，建议集群中topic总量不超过2000，每个节点的分区总量不超过2000。

     使用建议：如果业务重要或者数据量很大，建议分区量=节点数*磁盘数，如果该数值大于200，则分区数选择为200，如果后期需要需要提升分区数来提升读写性       能，可以使用kafka后台命令逐步提升，如果数据量很小，建议分区量=节点数，保证每个节点的数据量均衡。

    b.副本数不可配太多。副本是kafka容错能力的基础，当kafka出现节点故障后，另外的副本会承担leader接收数据责任。副本数增加一个，就需要多一次数据同步，也会使 kafka节点之间的数据流量同步能加一次。如果副本太多会。导致leader节点的数据流量压力增加。

     使用建议：创建的topic有2~3备份即可。

    c. 机架参数要合理使用。FusionInsight-HD中的kafka集群默认使用了机架感知策略，即：保证kafka所创建的topic的分区副本在不同的机架上面，这样能够保证如果出现机架宕机后，kafka依然有可用的副本。但是如果集群中每个机架上面的节点数量不均衡，会导致严重的数据倾斜。例如：kafka总共有2个机架10台机器，如果一个机架上有3个节点，一个机架上面有7个节点，那么3节点机架上的机器的副本数一定大于7节点机架的。

使用建议：如果kafka集群的机器在每个机架上面分布不均衡，在创建topic的时候加入机架不感知参数。

创建方式如下,其中ZK_IP为集群zookeeper的ip:

kafka-topics.sh --create --topic <topic name> --partitions <Integer: the number of partitions> --replication-factor <Integer: replication factor> --zookeeper <ZK_IP1: 24002,ZK_IP2:24002,.../kafka> --disable-rack-aware

   d. 不可频繁的创建删除topic。topic的创建目的应该是一次创建，长时间使用，如果topic出现异常可以删除重建。如果频繁创建，会导致broker节点异常，topic无法正常删除，同时对zookeeper也会造成一定的压力（频繁的创建删除，也就是频繁的增删zookeeper上面的节点，如果频率很大容易导致“羊群效应”和“脑裂”）。例如：每天大批量的创建删除1000个。

使用建议：

1. 如果有删除topic需要。每天删除量不建议超过10个。
2. 规整数据的协议类型，将多个相同类型的数据合并到一个topic中，创建后长期使用。防止出现topic频繁创建删除的情形。

   
   

4.集群性能调优

Kafka的集群调优通常考虑维度主要有两个，第一，是磁盘读写能力，第二，网络带宽。

磁盘的读写的负载可以通过命令：iostat –x -1 查看 idle指标，这个值越大代表磁盘越空闲。万兆网卡的极限能力为1250M/s，网络速度可以通过前台界面的，主机管理->对应主机“网络写入速度”，“网络读取速度”获取。通常在性能的极限情况下，磁盘io会成为性能瓶颈。Kafka侧优化写入性能的参数如下：

kafka集群的性能参数调整到最优值后，kafka数据的处理能力会大幅度提升cpu的使用率也会增加。如果后续节点上的数据流量持续增长，CPU的使用率也会上升。

5. Kafka性能维度标准

5.1性能维度

6.5.1版本之后kafka生产者的性能基线标准

如何判断一个kafka集群是否已经处于性能瓶颈，通常的判断条件有如下几点：

维度1：磁盘IO

读写磁盘性能是kafka重要的参数指标，如果磁盘IO到达性能瓶颈会直接导致业务故障。Kafka读写性能跟磁盘IO之间的关系计算如下：

举例：假设磁盘IO的上限为100M/s，数据大小为8k，假设在topic仅设置为单副本的情况下，理论上一块盘能写入的数据量为100*1024/8=12800条。如果一个节点挂载4块盘，那么理论性能为4*12800条。如果kafka集群有4个节点，那么整个集群的性能为4*4*12800条。

维度2：网络IO

    现网的网卡设置一般为万兆网卡，一张万兆网卡的理论极限性能为1250MB/s，在多kafka集群场景下，如果每个节点的数据流量不超过这个值，网卡一般不会出现性能瓶颈。

维度3：CPU使用率

     Kafka使用CPU的地方主要在请求的处理、数据落盘等，如果CPU使用率频繁出现95%以上的情况表示kafka集群性能已经到达瓶颈。通常影响kafka集群CPU使用率的几个参数主要有以下几个：

num.recovery.threads.per.data.dir，background.threads，num.replica.fetchers，num.network.threads，num.io.threads。具体参数含义见1.4章节。在磁盘和网卡未达到瓶颈的前提下，如果CPU使用率未达到上限，可以适当调大num.io.threads和num.network.threads，以提升kafka的集群处理能力。

以上三个性能指标哪个先达到瓶颈就是kafka集群的瓶颈。

5.2接口基线性能

• 异步producer性能数据

随着消息大小变大，吞吐量增加，每秒处理的消息条数逐渐变少。

• 同步producer性能数据

Producer同步发送的性能每秒在6万条左右。

• Consumer性能数据

随着Batch-size增加，消费者每秒消费的消息条数增加。以上场景的硬件信息如下：

硬件配置如下：

l   CPU：32core 2.0GHZ

l   内存：128G

l   硬盘：2*（SAS OS盘）+12*2.7T（SATA）

l   Broker节点数：2个

l Kafka使用的配置：num.io.thread=8

其它场景下，异步模式下生产、消费性能基线见附件：性能基线-kafka