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

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

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

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

结果一上线：

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

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

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

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

咱不学术，尽量说人话。

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

1️⃣ 分区的本质是啥？

很多人背过一句话：

Kafka 的并行度 = 分区数

这句话对，但不完整。

我更愿意这么理解：

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

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

1. 最大消费并发
2. 消息能不能保证顺序
3. 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）自定义分区器（高手利器，新手陷阱）

public int partition(String topic, Object key, byte[] keyBytes,
                     Object value, byte[] valueBytes, Cluster cluster) {
    if (key.toString().startsWith("VIP")) {
        return 0;
    }
    return Math.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 在底层做了三件事：

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

也就是说：

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

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

很多人会问：

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

简单区分一下：

👉 大部分业务：

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

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

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

Properties props = new Properties();
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 = new KafkaProducer<>(props);

然后配合：

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

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

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

很多人问我：

“Kafka 用好是不是很难？”

我通常只回一句话：

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

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

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

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

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