消息一致性的核心结论是：通过 “分区日志结构 + 副本同步 + 生产 / 消费端机制”，实现 “不丢、不重、有序” 的基础一致性，跨场景一致性需结合幂等 / 事务机制强化，整体可按需灵活配置。
核心维度拆解
Kafka 的消息一致性主要体现在三个核心维度，每个维度对应明确的保障目标：
- 不丢失：消息从生产者发出后，能被 Kafka 持久化存储，且消费者最终可读取。
- 不重复：消费者不会多次处理同一条有效消息，避免业务逻辑重复执行。
- 顺序性：消息的消费顺序与生产者发送顺序一致，尤其单业务流程依赖顺序的场景（如支付流程）。
各环节一致性保障手段
1. 生产端：避免消息丢失与重复
- 配置 acks=all：生产者发送消息后，需等待该分区 ISR（同步副本集）中所有副本确认接收，才视为发送成功。
- 开启重试机制（retries>0）：网络抖动或 broker 临时故障时，自动重试发送，避免消息丢失。
- 幂等性生产（enable.idempotence=true）：通过 PID（生产者 ID）+ Sequence Number 标记消息，Kafka 自动过滤重复发送的消息。
2. 存储端：确保数据持久化与同步
- 多副本机制：每个分区配置至少 2 个副本（replication.factor≥2），主副本故障时，从 ISR 中选举新主副本，避免数据丢失。
- 日志刷盘策略：通过 log.flush.interval.messages 和 log.flush.interval.ms 配置，确保消息定期刷盘持久化，防止 broker 宕机导致内存数据丢失。
3. 消费端：保证消费准确与顺序
- 手动提交 offset（enable.auto.commit=false）：消费者处理完消息后，手动提交 offset，避免 “消息未处理但 offset 已提交” 导致的丢失。
- 单分区单消费者：同一分区的消息仅分配给一个消费者实例，确保消费顺序与分区内消息顺序一致。
- 业务端幂等处理：通过消息唯一 ID（如业务流水号）在消费端二次去重，应对极端场景下的重复消息。
4. 跨场景一致性：解决复杂业务场景
- 事务消息：针对 “多主题 / 分区发送”“消费后生产新消息” 场景，通过事务机制实现原子提交 / 回滚，避免部分消息成功导致的数据不一致。
