Kafka高可用机制入门

概念

在Kafka在0.8以前的版本中，是没有Replication的，一旦某一个Broker宕机，则其上所有的Partition数据都不可被消费，这与Kafka数据持久性及Delivery Guarantee的设计目标相悖;

所以,0.8 以后就引入了副本机制;

引入副本机制后带来的问题

引入Replication之后，同一个Partition可能会有多个Replica，而这时需要在这些Replica中选出一个Leader，Producer和Consumer只与这个Leader交互，其它Replica作为Follower从Leader中复制数据。

因为需要保证同一个Partition的多个Replica之间的数据一致性（其中一个宕机后其它Replica必须要能继续服务并且即不能造成数据重复也不能造成数据丢失）。如果没有一个Leader，所有Replica都可同时读/写数据，那就需要保证多个Replica之间互相（N×N条通路）同步数据，数据的一致性和有序性非常难保证，大大增加了Replication实现的复杂性，同时也增加了出现异常的几率。而引入Leader后，只有Leader负责数据读写，Follower只向Leader顺序Fetch数据（N条通路），系统更加简单且高效。

kafka如何分配副本位置?

为了更好地做负载均衡，Kafka尽量将所有的Partition均匀分配到整个集群上。一个典型的部署方式是一个Topic的Partition数量大于Broker的数量。同时为了提高Kafka的容错能力，也需要将同一个Partition的Replica尽量分散到不同的机器。实际上，如果所有的Replica都在同一个Broker上，那一旦该Broker宕机，该Partition的所有Replica都无法工作，也就达不到HA的效果。同时，如果某个Broker宕机了，需要保证它上面的负载可以被均匀的分配到其它幸存的所有Broker上。

Kafka分配Replica的算法如下：

将所有Broker（假设共n个Broker）和待分配的Partition排序
将第i个Partition分配到第（i mod n）个Broker上
将第i个Partition的第j个Replica分配到第（(i + j) mod n）个Broker上

如何设置比较好?

复制因子
新topic的默认复制因子为1。对于高可用性的生产系统，Cloudera建议将复制因子设置为至少3。这至少需要3个Kafka broker。

不洁的领导人选举
禁用不干净的领导者选举后，如果包含该分区的leader replica的broker不可用，并且不存在任何in-sync replica来替换它，则该分区将变为不可用，直到leader replica或另一个in-sync replica重新上线。 启用不干净的领导者选择，以允许不同步的副本成为领导者并保留分区的可用性。 领导者选举不干净时，未同步到新领导者的消息将丢失。 这样可以在一致性（保证消息传递）和可用性之间取得平衡。

Acks
在编写或配置Kafka生产者时，您可以使用属性选择在确认消息之前提交新消息的副本数量。
根据您的要求，设置为（立即确认消息，而无需等待任何代理提交），（在领导者提交消息后确认）或（（在提交所有同步副本后确认）。 设置为可以提供最高的一致性保证，但会降低对集群的写入速度.requiredAcks01-1requiredAcks-1

参考

深入解析Kafka高可用设计如何步步为营 - 大数据 -

Kafka High Availability and Consistency