1       集群部署规范

1.1      Cpu规格与挂盘数量的关系

   对于kafka组件需要关注机器中具体处理器超线程个数，即processor的个数，可以通过命令：grep -c processor /proc/cpuinfo 查看。

   这个参数代表了整个机器的处理能力，kafka默认，建议：

            每台机器最大挂盘数量 <= processor / 2

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

1.2       磁盘挂载方式

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

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

1.3      Topic创建方式

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

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

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

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

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

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

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

创建方式如下：

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

其中ZK_IP为集群zookeeper的ip。

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

使用建议：

a)      如果有删除topic需要。每天删除量不建议超过10个。

b)      规整数据的协议类型，将多个相同类型的数据合并到一个topic中，创建后长期使用。防止出现topic频繁创建删除的情形。