第6章 可靠的数据传递
6.1 可靠性保证
①kafka保证分区消息的顺序，A-->B，B的偏移量更大的话也会后被读取
②当所有同步副本被成功保存时，消息才为已提交，但生产者可选0,1，all
③只要还有分区副本活跃，已提交消息便不会丢失。
④消费者（除slaver外），只能读取已提交分区
6.2 复制
当一个broker与zookeeper连接心跳正常，并在10s（可配置）内向master获取过最新消息，认为是其同步副本
【一个或多个副本在同步与非同步频繁切换，可能为不恰当的垃圾回收配置导致】
6.3 broker配置
关于可靠性的配置，可以基于broker控制全部主题，也可以基于topic，控制个别broker
6.3.1 复制系数
topic级：repliacation.factor
broker级：dufault.replication.factor
【追求高可用时，一般设置为3】
6.3.2 不完全的首领选举
unclean.leader.election.enable：是否让非同步副本成为master
true：高可用，但会有一致性问题
false：保证一致性，但在故障修复前不可用
6.3.3 最少同步副本
min.insync.replicas：最少存活的同步副本数
6.4 在可靠的系统里使用生产者
①更具可靠性正确配置acks(0,1,all)
②在配置和代码中正确处理异常
6.4.1 发送确认
①acks=0，可以得到惊人的吞吐量与带宽利用率。但在首领故障时，一定会丢失信息
②acks=1，若正确处理异常并重试，只有在首领接收到并写入缓存，且slaver来复制时首领故障，才会丢失消息
③acks=all，低吞吐量，可异步、大批次加速。需要与同步副本参数结合使用
6.4.2 配置生产者的重试参数
①若需要抓住异常并重试，可将该参数调大
②若需要失败后记录，可调小，待之后处理
重试可能会导致出现两条相同的消息，一般在消费端做幂等操作
6.4.3 额外的错误处理
①若重试只是为了重试发送消息，那么推荐用内置retry
②其他不可retry错误需要生产者自行处理
6.5 在可靠的系统里使用消费者
6.5.1 消费者的可靠性配置
②auto.offset.reset：第一次启动时读取全部消息或读取最后消息
③enable.sauto.commit：自动提交
【自动提交可能会导致两个问题：1>若消费者异步处理消息，可能导致消息未处理完时已经提交，丢失数据；2>若消费者自动提交后，又处理了半批消息后故障，会导致重复消费消息】
④auto.commit.interval.ms：默认5秒提交一次偏移量，有额外开销，但降低重复消费
6.5.2 显式提交偏移量
可靠的消息提交准则：
1>在处理完事件后再提交偏移量
2>提交频度由性能与再平衡重复消费数权衡得出
3>确保对提交的偏移量心里有数
4>在均衡时通过接口做特殊处理
5>消费者可能需要重试
【重试后不能简单的提交偏移量，可能会导致覆盖，推荐先保存消息在某些地方之后处理】
6>消费者可能需要维护状态
7>长时间处理
【长时间处理时可以让消费者保持轮询，但不获取新消息，来保证心跳的正常发送(0.9.0之前)】
8>仅一次传递
不重复处理消息，需要消费者自己实现
6.6 验证系统可靠性
6.6.1 配置验证
工具：org.apache.kafka.tools.VerifiableProducer && VerifiableConsumer
验证种类：首领选举、控制器选举、依次重启、不完全首领选举
6.2.2 应用程序验证
1>客户端从服务器断开连接
2>首领许那句
3> 依次重启broker
4>依次重启以消费者
5>依次重启生产者