Kafka在数据传递可靠性方面具备很大的灵活性。
6.1 可靠性保证
ACID指的是原子性、一致性、隔离性和持久性。
- Kafka可以保证分区消息的顺序
- 只有消息被写入分区的所有同步副本时，才被认为是“已提交”的
- 只要还有一个副本是活跃的，那么已经提交的信息就不会丢失
- 消费者只能读取已经提交的消息
6.2 复制
Kafka的复制机制和分区的多副本架构是Kafka可靠性保证的核心。把消息写入多个副本可以使Kafka在发生奔溃时仍能保证消息的持久性。
6.3 broker配置
6.3.1 复制系数
默认3
6.3.2 不完全的首领选举
允许不同步的副本成为首领，就要承担丢失数据和出现数据不一致的风险；
如果不允许它们称为首领，那么就要接受较低的可用性，必须等待原先的首领恢复到可用状态。
默认true,允许。
6.3.3 最少同步副本
6.4 在可靠的系统里使用生产者
6.4.1 发送确认
选择3种不同的确认方式：
- acks = 0
- acks = 1
- acks = all
6.4.2 配置生产者的重试参数
可重试错误
不可重试错误
6.4.3 额外的错误处理
6.5 在可靠的系统里使用消费者
6.5.1 消费者的可靠性配置
1 group.id
2 auto.offset.reset
指定了在没有偏移量可提交时或者请求的偏移量在broker上不存在时，消费者会做些什么。
3 enable.auto.commit
可以让消费者基于任务调度自动提交偏移量，也可以在代码里手动提交偏移量。
4 auto.commit.interval.ms
选择了自动提交偏移量，可以通过该参数配置提交的频度，默认值是每5秒种提交一次。
6.5.2 显示提交偏移量
1 总是在处理完事件后再提交偏移量
2 提交频率是性能和重复消息数量之间的权衡
3 确保对提交的偏移量心里有数
4 再均衡
5 消费者可能需要重试
6 消费者可能需要维护状态
7 长时间处理
8 仅一次传递
6.6 验证系统可靠性
6.6.1 验证配置
验证配置的工具类：
VerifiableProducer
VerifiableConsumer
6.6.2 应用程序验证
6.6.3 在生产环境监控可靠性
6.7 总结