4. Kafka生产者实战：发送模式、分区策略、消息确认机制与幂等性
在实时风控评分沙盘中，Kafka 生产者是数据流的起点。风控事件（如登录、交易、授信）必须可靠、有序、低延迟地写入 Kafka 集群。本章深入生产者的核心配置与运行机制，涵盖发送模式、分区策略、消息确认（acks）、重试与幂等性，帮助你在高并发风控场景下做出正确选型。
4.1 发送模式：同步 vs 异步
Kafka 生产者提供两种发送模式，直接影响风控事件的投递延迟与吞吐量。
| 特性 | 同步发送 | 异步发送 |
|---|---|---|
| 调用方式 | producer.send(record).get() |
producer.send(record, callback) |
| 阻塞行为 | 阻塞直到 Broker 确认 | 立即返回，回调处理结果 |
| 延迟 | 高（等待网络 RTT） | 低（批量发送） |
| 吞吐量 | 低（每条消息等待确认） | 高（批量、异步刷盘） |
| 风控适用场景 | 关键事件（如大额转账）需确认写入 | 高吞吐事件（如点击流、日志） |
实战建议：风控评分沙盘中，对延迟敏感且允许少量丢失的事件（如行为埋点）使用异步模式；对资金安全类事件（如提现、修改密码）使用同步模式或异步+回调重试。
4.2 分区策略：数据如何路由到 Partition
分区策略决定了消息写入哪个 Partition，直接影响消费并行度与顺序性。风控场景中，同一用户的事件通常需要顺序处理。
- 默认分区器（DefaultPartitioner）：当 Key 不为 null 时，对 Key 的哈希值取模；Key 为 null 时，使用粘性分区（Sticky Partition）策略，批量发送到同一分区以提高吞吐。
- 自定义分区器：实现
Partitioner接口，按风控业务规则路由。例如：按用户 ID 哈希、按事件类型、按风险等级。 - 顺序保证：同一 Key 的消息始终进入同一 Partition，保证局部有序。风控中常用
userId作为 Key。
关键点：如果风控规则要求同一用户的事件严格有序，必须设置 Key 并确保分区数不变。增加分区数会破坏 Key 与分区的映射关系。
4.3 消息确认机制（acks）
acks 参数控制生产者等待 Broker 确认的级别，直接影响数据可靠性与延迟。风控场景需根据事件重要性选择。
| acks 值 | 行为描述 | 可靠性 | 延迟 | 风控推荐场景 |
|---|---|---|---|---|
acks=0 |
不等待任何确认，发送即视为成功 | 最低（可能丢数据） | 最低 | 日志、监控指标（可容忍少量丢失） |
acks=1 |
等待 Leader Partition 写入本地日志即确认 | 中等（Leader 宕机可能丢数据） | 中等 | 一般风控事件（如行为埋点） |
acks=all（或 -1） |
等待 Leader 和所有 ISR 副本确认写入 | 最高（不丢数据） | 最高 | 资金交易、授信、密码修改等关键事件 |
注意：使用
acks=all 时，必须配合 min.insync.replicas 参数（Broker 端）设置最小同步副本数，否则单副本场景下等同于 acks=1。
4.4 重试机制与幂等性
网络抖动或 Leader 选举可能导致发送失败。Kafka 提供重试机制，但重试可能引发消息重复。幂等性（Idempotence）正是为解决此问题而设计。
4.4.1 重试配置
retries：重试次数，默认Integer.MAX_VALUE（配合delivery.timeout.ms使用）。retry.backoff.ms：重试间隔，默认 100ms。delivery.timeout.ms：发送超时总时间，默认 120000ms（2分钟）。超过此时间不再重试。
风控最佳实践：设置
delivery.timeout.ms 为 3000~5000ms，避免长时间阻塞关键事件；重试间隔使用默认值；关键事件开启幂等性。
4.4.2 幂等性原理
启用幂等性（enable.idempotence=true）后，生产者会为每个消息分配一个唯一的序列号（Producer ID + 序列号）。Broker 端去重，即使重试发送多次，也只会写入一次。
- Producer ID（PID）：每个生产者初始化时分配，重启后变更。
- 序列号（Sequence Number）：从 0 开始，每个 Partition 独立递增。
- 去重范围：单次会话内，单个 Partition 上，最多保留 5 个序列号（可配置）。
4.5 综合配置示例（风控场景）
以下是一个面向实时风控评分沙盘的生产者配置模板，兼顾可靠性、吞吐与顺序性。
Properties props = new Properties();
props.put("bootstrap.servers", "kafka1:9092,kafka2:9092,kafka3:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
// 关键事件使用同步+acks=all+幂等性
props.put("acks", "all");
props.put("enable.idempotence", true);
props.put("delivery.timeout.ms", 5000);
props.put("retries", Integer.MAX_VALUE);
props.put("retry.backoff.ms", 100);
// 高吞吐事件使用异步+acks=1
// props.put("acks", "1");
// props.put("linger.ms", 5); // 批量发送延迟
// props.put("batch.size", 16384); // 批量大小
// 分区策略：按 userId 路由，保证同一用户顺序
props.put("partitioner.class", "org.apache.kafka.clients.producer.RoundRobinPartitioner");
// 实际风控中建议自定义分区器
KafkaProducer<String, String> producer = new KafkaProducer<>(props);
沙盘演练：在本地启动 Kafka 单节点，分别测试
acks=0、acks=1、acks=all 三种模式下，模拟 Broker 宕机时的消息丢失情况。观察启用幂等性后重复发送是否产生重复数据。
4.6 本章小结
- 发送模式：同步保证可靠，异步提升吞吐，风控中按事件重要性混合使用。
- 分区策略：Key 哈希保证顺序，自定义分区器支持业务路由。
- 消息确认：
acks=all提供最强可靠性，但需配合min.insync.replicas。 - 重试与幂等性：重试解决临时故障，幂等性防止重复写入，两者结合实现 exactly-once 语义。