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

业界Kafka的规范应用形式是作为长期缓存应用。因而，很多人会误以为，kafka的每个节点只有存储够大就行，不必关怀其余的指标。官网并不倡议kafka单节点关在多个磁盘，因为磁盘越多，示意须要更多的解决线程去治理（num.io.thread决定），CPU的压力将十分大，如果磁盘数大于了CPU逻辑核数，kafka的CPU将因为十分忙碌导致数据落盘失败，从而影响业务。

倡议：

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

2.把kafka当做数据库应用

很多人认为，如果数据重要，须要把kafka中的数据保留周期缩短到很大（例如：1年），例如。Kafka对于数据目录中的每个segment文件会有一个操作句柄对应，如果数据保留周期过长，会导致操作句柄使用率减少，如果句柄数无限度减少并且达到下限后会导致kafka服务异样。

失常状况下，业务侧该当依据集群中的磁盘总容量来评估数据的保留工夫。如果，集群中的业务品种多、数据量大。于此同时又不关怀数据量的大小，很容易造成磁盘容量有余。

倡议：业务侧评估好数据量的大小，调整适合的保留工夫。个别状况下，倡议应用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无奈失常删除。

倡议：

  • Topic不倡议频繁创立删除。
  • 对于有独特特点的数据（例如：协定类型雷同），能够归并到一个topic外面解决。

6.频繁应用旧版本客户端生产工具

旧版本的生产工具应用的命令如下：

每应用一次就会在zookeeper下生成一个永恒节点。这个节点不会主动清理，如果常常应用会导致zookeeper异样。

本文由华为云公布