集群磁盘分布倾斜
现象
| 节点id | broker_id | CPU | 内存 | 磁盘 |
|---|---|---|---|---|
| xxx | 0 | 35% | 12% | 60% |
| xxx | 1 | 35% | 12% | 70% |
| xxx | 2 | 35% | 12% | 83% |
原因
有3个topic是只有3分区的，也就是只有3个主副本，另外还有2个从副本，每个分区3副本。这3个topic一天的数据量超过了2TB。而Kafka集群有35个节点，每个节点磁盘是2000GB。
解决方案
1、扩分区。下游不用重启，所以可以直接扩分区。扩分区之后，需要对分区做副没有什么数据。
2、把副本迁移到磁盘使用率低的节点上。这个只是权宜之计，上面将topic的分区数扩到和broker节点数一致，才能保证后续topic的数据均匀的分布在集群中。
相关原理
1、Kafka Topic的分区机制
2、Kafka Producer的发送流程
3、数据在Kafka Broker集群中的存储架构
PB级数据存储
问题
假如，一个数据采集的系统，每天客户端总共有1PB的数据上报上来，经过后端服务发往kafka，再被消费后进入下游。在保存3副本、保存时间为1天的情况下，每天需要3PB的存储空间，这么庞大的集群成本是很高的。
解决方案
优化存储策略
1PB的数据不可能条条都重要，数据肯定是要分层级的。
1、重要的数据：保存3副本、保存1天。
2、不重要的数据：保存2副本、保存12小时。
实操下来，节省个1/4的存储空间都可以。
数据压缩
接收网关传入数据的后端服务同时也是kafka的Producer，在发送数据时可以将数据压缩。
xml
spring.kafka.producer.compression-type=gzipkafka支持多种压缩方式：gzip，snappy， lz4， zstd(2.10之后的版本)。针对压缩比较高的gzip和lz4做测试发现：生产者与消费者的CPU、内存使用率基本没有变化，在此基础上，gzip的压缩比约是1/5、lz4的压缩比是1/4。
那么有一个问题，consumer需不需要配置才能解压缩呢？消费的数据里压缩和没压的都有怎么消费呢？
consumer不需要配置解压，会根据RecordBatch中的3个bit，判断这批数据是否采用了压缩，以及使用了哪种压缩方式，然后进行不同的消费行为。 
相关原理
1、数据在Kafka Broker集群中的存储架构
2、数据压缩
集群切换
当需要把原有的HDD磁盘，替换为SSD磁盘时，需要升级Kafka集群。直接升级的话，影响的节点会很多，影响数据传输流程，影响下游业务使用。
可以新建SSD磁盘集群，用双消费逐步切换：
消费堆积
消费资源不足
消费堆积最常见的一种情况就是消费组资源不足。
如果是用java服务来消费kafka，则需要增加服务的实例数，也就是增加消费者组里的消费者数量。最好是能被topic的分区数整除，不然会有分区倾斜堆积。
如果是Flink算子来消费，则需要增加Flink的并行度，和taskmanager里的slot数量。并行度越大，每个taskmanager里面的slot数量越少，则taskmanager数量越多。
消费重试
消费者如果消费报错，kafka好像没有自动重试，rocketmq有，但如果给消费失败的数据加上重试队列。这是如果消费报错不及时解决，一直重试，消费必然快速堆积。
或者flink消费kafka数据格式错误，也会导致快速堆积。
参数设置
