Kafka 最佳实践：分区策略、重试、幂等生产者-编程阁

Kafka 最佳实践：分区策略、重试、幂等生产者

——消息不丢、不乱、不重，才配叫“稳定生产”

我是Echo_Wish。
实话说，Kafka 这玩意儿吧，入门不难，翻车很快。
很多同学一开始觉得：

“不就是发消息、消费消息嘛，能有多复杂？”

结果一上线：

顺序乱了
消息重复了
延迟飙升
线上日志一片红

然后大家才开始翻配置、补知识、查原理。

今天这篇文章，我不打算从“官方定义”讲起，而是从真实生产经验出发，把 Kafka 里最容易被忽略、但最关键的三件事聊透：

分区策略：决定你系统上限的隐形天花板
重试机制：你以为在兜底，其实可能在制造灾难
幂等生产者：Kafka 世界里最被低估的安全带

咱不学术，尽量说人话。

一、分区策略：不是越多越好，而是“刚刚好”

1️⃣ 分区的本质是啥？

很多人背过一句话：

Kafka 的并行度 = 分区数

这句话对，但不完整。

我更愿意这么理解：

分区 = 并发能力 + 顺序边界 + 负载分摊单元

也就是说，分区一旦定下来，你同时定下了三件事：

最大消费并发
消息能不能保证顺序
Broker 负载是否均匀

所以，分区不是拍脑袋定的。

2️⃣ 常见三种分区策略（踩坑指数递增）

✅ 1）Key Hash（最常见，也最安全）

producer.send(topic="order_topic",key=b"user_123",value=b"create_order")

Kafka 会对 key 做 hash，然后% partition_num。

优点：

同一个 key 永远进同一个分区
天然保证顺序
非常适合：订单、用户、账户、设备维度

缺点：

key 如果设计不好，容易数据倾斜

👉我的经验：

80% 的业务，用 Key Hash 就够了，关键在于key 设计得像不像业务主键

⚠️ 2）Round-Robin（负载均匀，但顺序没了）

props.put(ProducerConfig.PARTITIONER_CLASS_CONFIG,"org.apache.kafka.clients.producer.RoundRobinPartitioner");

优点：

分区非常均匀
压测数据好看

致命问题：

完全不保证顺序
同一业务事件可能被不同消费者并行处理

👉 我见过最惨的案例是：

创建订单 → 扣库存 → 发通知
顺序全乱，库存扣成负数

结论一句话：

业务消息，慎用 Round-Robin

❌ 3）自定义分区器（高手利器，新手陷阱）

publicintpartition(Stringtopic,Objectkey,byte[]keyBytes,Objectvalue,byte[]valueBytes,Clustercluster){if(key.toString().startsWith("VIP")){return0;}returnMath.abs(key.hashCode())%cluster.partitionCountForTopic(topic);}

适合什么场景？

VIP 用户单独分区
热点业务隔离
灰度流量

但我要泼点冷水：

90% 的自定义分区器，最后都变成了“技术债”

因为：

业务一变，分区规则就得跟着改
一改就可能导致历史数据顺序失效
运维复杂度直线上升

📌 Echo_Wish 的分区总结

先用 Key Hash，
用不好再谈定制，
千万别为了“看起来高级”而复杂化。

二、重试机制：你以为在补救，其实可能在放大故障

很多人对 Kafka Producer 的理解是：

“发送失败？那就重试呗。”

这句话，一半对，一半坑。

1️⃣ Kafka 的重试是“自动的”，但不一定是“安全的”

retries=3 retry.backoff.ms=100

看起来很合理，对吧？

但你有没有想过一个问题：

重试时，之前那条消息到底有没有成功？

答案是：Producer 不一定知道。

2️⃣ 经典事故场景（真实发生过）

Producer 发送消息
Broker 已经写入成功
ACK 在网络中丢了
Producer 以为失败 → 重试
结果：同一条业务消息写了两次

然后下游就炸了。

3️⃣ 重试不是问题，无脑重试才是问题

我给你一个生产级推荐配置：

acks=all retries=Integer.MAX_VALUE delivery.timeout.ms=120000 linger.ms=5

你会发现：

retries 设得非常大
但真正兜底的，不是 retries，而是下面要说的——幂等性

三、幂等生产者：Kafka 世界里的“安全带”

1️⃣ 什么是幂等？

说人话版定义：

同一条消息，不管你发多少次，Broker 最终只认一次

Kafka 从 0.11 开始，就支持了Idempotent Producer。

2️⃣ 开启方式简单到离谱

enable.idempotence=true acks=all retries=Integer.MAX_VALUE

就这三行。

但很多项目：

要么没开
要么开了不知道为啥

3️⃣ 幂等生产者是怎么做到的？

Kafka 在底层做了三件事：

给 Producer 分配PID（Producer ID）
每个分区维护序列号（Sequence Number）
Broker 拒绝重复序列号的写入

也就是说：

Kafka 帮你挡掉了“重试带来的重复写”

4️⃣ 幂等 ≠ 事务（别搞混）

很多人会问：

“那我还需要 Kafka 事务吗？”

简单区分一下：

能力	幂等 Producer	Kafka 事务
防止重复写	✅	✅
跨分区原子性	❌	✅
Exactly Once	部分	完整

👉大部分业务：

幂等生产者 + 下游去重
已经足够稳定

四、把三件事串起来，才是真正的“最佳实践”

我最后给你一个我自己项目里常用的 Producer 模板：

Propertiesprops=newProperties();props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG,"kafka:9092");props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG,StringSerializer.class.getName());props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG,StringSerializer.class.getName());props.put(ProducerConfig.ACKS_CONFIG,"all");props.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG,true);props.put(ProducerConfig.RETRIES_CONFIG,Integer.MAX_VALUE);props.put(ProducerConfig.LINGER_MS_CONFIG,5);KafkaProducer<String,String>producer=newKafkaProducer<>(props);

然后配合：

合理的 key 设计
消费端幂等处理
监控 lag 和失败率

这套组合，我跑过双十一级别的流量，很稳。

五、写在最后：Kafka 稳定性，拼的不是技巧，是敬畏

很多人问我：

“Kafka 用好是不是很难？”

我通常只回一句话：

Kafka 不难，难的是你有没有把‘最基础的三件事’当回事。

分区随便配
重试随便开
幂等懒得管

那系统迟早会用线上事故来提醒你。

如果你现在正在用 Kafka，强烈建议你回头看一眼：

Topic 分区是不是拍脑袋定的？
Producer 有没有开幂等？
重试到底是在救你，还是在害你？

Kafka 最佳实践：分区策略、重试、幂等生产者