生产者分区策略决定消息如何分配到Topic的各个分区，核心影响因素是业务顺序性需求和数据均匀性需求。Kafka提供4种主流策略，需根据场景选择：
原理：忽略消息Key，将所有分区按哈希排序，依次轮询分配给生产者。若未指定Key，这是默认策略。
适用场景：无Key的大批量均匀写入场景（如日志采集、监控数据上报）。
优点：绝对均衡，避免数据倾斜；
缺点：无法保证分区内有序（因消息分散在不同分区）。
注意事项：若业务需要顺序性，禁止使用此策略。
原理：对消息Key进行哈希计算（如hash(key) % 分区数），将相同Key的消息固定分配到同一分区。
适用场景：需要分区内有序的业务（如订单状态更新、用户行为轨迹追踪）。
优点：保证相同Key的消息顺序，满足业务逻辑需求；
缺点：若Key分布不均（如某些Key出现频率极高），会导致对应分区成为热点（数据倾斜），影响吞吐量。
注意事项：需监控Key分布，若出现热点，可通过复合Key（如用户ID+时间戳）或自定义分区器分散流量。
原理：每条消息随机分配到任意分区。早期版本默认策略，现基本被轮询替代。
适用场景：测试环境或对顺序性、均匀性无要求的场景。
优点：实现简单；
缺点：无法保证均匀性（长期运行可能出现偏差），不推荐生产使用。
原理：实现Partitioner接口，通过业务逻辑（如用户地理位置、数据类型）自定义分区规则。
适用场景：特殊业务需求（如按地区分片存储、高频Key单独处理）。
优点：灵活性极高，完全贴合业务；
缺点：开发成本高，需维护自定义代码。
注意事项：需确保分区逻辑与消费者处理逻辑一致，避免数据倾斜。
消费者分区策略决定组内消费者如何分配Topic的分区，核心目标是负载均衡和减少重平衡开销。Kafka提供4种主流策略，需根据消费者组动态性选择：
原理：针对每个Topic，将分区按序号排序，消费者按字典序排序，前m个消费者（m = 分区数%消费者数）多分配1个分区，其余各分配n = 分区数/消费者数个分区。
适用场景：单一Topic或消费者数量固定的环境（如固定数量的消费者组）。
优点：实现简单；
缺点：多Topic订阅时易出现字典序靠前消费者过载（如每个Topic都分配给C0更多分区）。
注意事项：避免多Topic订阅，若必须使用，需监控消费者负载。
原理：将组内所有消费者和所有Topic的分区合并，按哈希排序后轮询分配，实现全局负载均衡。
适用场景：多Topic订阅且需全局均衡的场景（如消费者组同时订阅多个业务Topic）。
优点：全局均衡，避免单Topic分区集中；
缺点：重平衡时分区迁移成本高（需重新分配所有分区），适合消费者变动少的场景。
注意事项：消费者变动频繁时，不建议使用。
原理：初始分配时尽量均衡，重平衡时保留原有分配结果，仅调整因消费者加入/退出而必须变更的分区（如新增消费者时，从现有消费者处均匀迁移少量分区）。
适用场景：动态消费者组（如Kubernetes自动扩缩容、消费者频繁崩溃重启）。
优点：大幅减少重平衡时的分区迁移开销（避免大规模数据重分布），提升消费效率；
缺点：需Kafka 2.3+版本支持，配置复杂度略高。
注意事项：是当前最推荐的消费者策略，尤其适合生产环境的弹性伸缩场景。
原理：是Sticky策略的改进版，支持协作式再平衡（消费者主动参与分区分配决策，减少Broker端的协调压力），进一步提升重平衡效率。
适用场景：Kafka 2.4+版本的生产环境，尤其是消费者组规模大、重平衡频繁的场景。
优点：比Sticky策略更高效，减少重平衡时间；
缺点：版本要求高，需升级Kafka至2.4及以上。
注意事项：若使用Kafka 2.4+，优先选择此策略替代传统Sticky策略。
分区数=2×预期消费者数）和Key设计（避免热点），防止数据倾斜。
