保证Kafka的可靠性

可靠性保证

• Kafka可以保证分区消息的顺序
• 只有当消息被写入分区的所有同步副本时，它才被认为是"已提交"的。生产者可以选择接收不同类型的确认。
• 只要还有一个副本是活跃的，那么已经提交的消息就不会丢失。
• 消费者只能读取已经提交的消息。

复制

分区首领是同步副本，而对于跟随者副本来说，它需要满足以下条件才能被认为是同步的。

• 与ZooKeeper之间有一个活跃的会话，也就是说，在过去的6s(可配置)内向Zookeeper发送过心跳。
• 在过去的10s内从首领那获取过消息。
• 在过去的10s内从首领那获取过最新的消息，要求几乎零延时。

非同步副本:如果一个或多个副本在同步和非同步状态之间快速切换，说明集群内部出现了问题，通常是Java不恰当的垃圾回收配置导致的。

一个滞后的同步副本会导致生产者和消费者变慢，因为在消息被认为已提交之前，客户端会等待所有同步副本接收消息。如果一个同步副本不再同步，我们就不再关心它是否已经收到消息，所以它不影响性能，但是增大数据丢失风险。

broker配置保证可靠性

复制系数:在主题级别的配置参数是replication.factor，而在broker级别则可以通过default.replication.factor来配置主动创建的主题。broker.rack参数为每个broker配置所在机架的名字。如果配置了机架，Kafka会保证分区的副本被分布在多个机架上。

不完全的首领选举:unclean.leader.election只能在broker级别进行配置，它默认值是true。如果首领不可用时其他副本都是不同步的，如何处理？方案一:如果不同步的副本不能提升为新首领，那么分区在旧首领恢复后之前是不可用的。方案二:如果不同步的副本可以被提升为新首领，会导致数据不一致。是否启用，取决于业务场景。银行这类系统是不允许启用的。

最少同步副本:min.insync.replicas，如果要确保已提交的数据被写入不止一个副本，(因为"所有同步副本"可能只包含一个同步副本)，就需要把最少的同步副本数量设置为大一点的值。如果少于此值的同步副本数量可用，那么broker就会停止接受生产者的请求。生产者继续发送，会收到NotEnoughReplicasException异常。

在可靠的系统里使用生产者:1.根据可靠性需求配置恰当的acks值。2.在参数配置和代码里正确处理错误。acks=0意味着只管发送;acks=1意味着首领在收到消息并把它写到分区数据文件时，会返回确认或错误响应;acks=all意味着所有同步副本都收到消息才会返回确认。

配置生产者的重试参数:一部分是生产者可以自动处理的错误，例如LEADER_NOT_AVAILABLE错误，这类错误可以自动重试，所以需要配置重试参数。还有一部分是需要开发者手动处理的错误，例如INVALID_CONFIG错误。

额外的错误处理:1.不可重试的broker错误，例如消息大小错误。2.消息发送前的错误，例如序列化错误。3.在生产者达到重试次数上限时或者消息占用的内存达到上限时发生的错误。

在可靠的系统里使用消费者:在从分区读取数据时，消费者会获取一批事件，检查这批事件里最大的偏移量，然后从这个偏移量开始读取另外一批事件。这样可以保证消费者总能以正确的顺序获取新数据，不会错过任何事件。

消费者的可靠性配置:1.group.id。2.auto.offset.reset，这个参数指定了在没有偏移量可提交时或者请求的偏移量在broker上不存在时，消费者会做些什么。一种是earliest，消费者将从分区的开始位置开始读取。另一种是latest，这种将从分区的末尾开始读取数据。3.enable.auto.commit配置是否自动提交。4.auto.commit.interval.ms该参数控制提交的频度。

显式提交偏移量:1.总是在处理完事件后再提交偏移量。2.提交频度是性能和重复消息数量之间权衡。3.确保对提交的偏移量心中有数。4.再均衡。5.消费者可能需要重试。6.消费者可能需要维护状态。7.长时间处理。8.仅一次传递。

验证系统可靠性:1.配置验证2.应用程序验证3.在生产环境监控可靠性