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 异样。
本文由华为云公布