Kafka最佳实践-Kafka常见的使用误区

1.  kafka集群单个节点磁盘挂载的越多越好

业界Kafka的标准使用方式是作为临时缓存使用。因此，很多人会误以为，kafka的每个节点只要存储够大就行，不用关心其他的指标。官方并不建议kafka单节点关在多个磁盘，因为磁盘越多，表示需要更多的处理线程去管理（num.io.thread决定），CPU的压力将非常大，如果磁盘数大于了CPU逻辑核数，kafka的CPU将因为非常繁忙导致数据落盘失败，从而影响业务。

建议：

1. 建议每个节点挂盘数，满足每台机器最大挂盘数量 <= processor（CPU逻辑核数） / 2。
2. 最优策略为每个节点使用raid5或者raid10挂载数据目录，每个raid5或者raid10的逻辑盘不超过8块。

2.  把kafka当做数据库使用

很多人认为，如果数据重要，需要把kafka中的数据保存周期延长到很大（例如：1年），例如。Kafka对于数据目录中的每个segment文件会有一个操作句柄对应，如果数据保存周期过长，会导致操作句柄使用率增加，如果句柄数无限制增加并且到达上限后会导致kafka服务异常。

正常情况下，业务侧应当根据集群中的磁盘总容量来评估数据的保留时间。如果，集群中的业务种类多、数据量大。于此同时又不关心数据量的大小，很容易造成磁盘容量不足。

建议：

1. 建议业务侧评估好数据量的大小，调整合适的保留时间。一般情况下，建议使用7天即可。

3.  分区数越多越好

Kafka增加分区数的作用主要有两点：第一：将数据分布均匀，防止不会出现某个节点或者某个数据盘的数据热点。第二，提升消费并行度，消费者通常与分区是一一对应的，提升分区数同样也能提升消费者的个数，从而提升消费性能。但是分区数不能无限制增加，如果数量太多会导致kafka和zookeeper负载增高，kafka内部调度线程无法及时处理响应，导致节点进程故障。

建议：

建议集群中topic总量不超过2000，每个节点的分区总量不超过2000。

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

4.  业务侧对写入kafka的数据大小不感知

kafka组件的主要定位为消息队列（非文件队列），官方建议写入kafka最佳的数据大小不超过15K。但是在很多的业务场景下，需要写入的数据往往是大于15k的。Kafka服务端默认可以接受的最大的数据大小为10M

建议：

• 客户端默认单条数据大小最大为1M（由配置request.size决定），在数据大小小于1M的情况下，使用默认值发送数据即可。
• 如果数据在1M到5M之间，开启在生产端开启压缩模式（由type决定，可以选择gzip, snappy, 或者lz4），开启压缩后，生产端的压缩数据过程和消费端的解压缩数据过程会增加CPU的使用率。
• 不建议发送大于5M的数据，经过验证持续返送大于5M的数据会导致kafka的直接内存溢出。

5.      Topic可以随意的创建和删除

      Kafka的topic代表了一个类型的数据，频繁的创建删除topic会导致zookeeper通信压力大，出现broker节点信息上报失败，服务不可用的情况。一旦zookeeper出现异常，删除topic的流程会处于阻塞状态，导致topic无法正常删除。

建议：

1. Topic不建议频繁创建删除。
2. 对于有共同特点的数据（例如：协议类型相同），可以归并到一个topic里面处理。

6.   频繁使用旧版本客户端消费工具

旧版本的消费工具使用的命令如下：

每使用一次就会在zookeeper下生成一个永久节点。这个节点不会自动清理，如果经常使用会导致zookeeper异常。