kafka中的选举和数据冗余备份机制

前言

    在分布式系统中，通常会出现两个角色，master 和 slaver。master通常用于管理集群调度资源。而slaver通负责于数据的存储和传输工作。从而平衡集群负载，提高集群整体的稳定性。

kafka的集群管理–controller选举

    kafka集群中有多个broker，在集群启动时，各个broker会去zookeeper集群中，注册成controller。这个机制跟hadoop-ha类似，利用Zookeeper的强一致性特性，一个节点只能被create一次，创建成功的broker即成为leader，负责集群中所有大小事务。之后只有controller，leader会向zookeeper上注册Watcher，其他broker几乎不用监听zookeeper的状态变化。这样也可以有效的降低zookeeper负担，防止过载。

    kafka集群中被选举为controller的broker执行leader行为，负责和zookeeper的通信和管理整个集群中的分区和监控副本的状态。比如当某一个partition的leader 副本故障，由controller 负责为该partition选举新的leader 副本；当检测到ISR列表发生变化时，controller通知集群中所有broker更新其metadatacache信息；或者增加某个topic分区的时候也会由controller管理分区的重新分配工作。当controller宕机，zookeeper中的临时节点会删除，而其他broker会监听该节点的变化，当节点删除时，其他broker会收到事件通知，重新发起leader注册。

kafka 的副本机制

    分布式系统一般都会涉及到数据备份问题，通过数据冗余备份，防治数据丢失，从而达到高可用的目的。

    kafka集群也不例外，同样也会创建自己的备份数据。kafka将其称作replicas。在创建topic要进行指定，同时要求指定的replicas的个数不能超过cluster的brokers数量。

副本分配算法：
    假设有n个broker是，m个待分配的partions。将第i个partion分配到第mod（i，n）个broker上，将第i个partion的第j个副本分配到第mod（（i + j），n）个broker上。每个partition的replicas中有一个leader，负责数据的读和写，剩下的称为followers，负责从leader节点pull data。

    follower在从leader fetch数据的过程中，很可能会滞后。如果该follower所在节点与zookeeper维持着心跳连接，并且和leader最后一条消息的 offset 之 间 的 差 值 维持在阈值(replica.lag.time.max.ms)之内，则该follower会加入到[isr](in-sync-replica)列表中，如果该 follower 在此时间间隔内一直没有追上过 leader 的所有消息，则该 follower 就会被剔除 isr 列表，加入到[osr]列表。如果ors列表中的follower又达到了加入isr列表的条件则将再次加入到里面，而从osr中去除。

    前面我们提到leader负责消息的读写操作。当producer push 过来消息后，leader首先将消息写在本地，follower同时也处于pull数据状态。followers每次pull完新的数据（有序）后，都会向leader发送ack。leader在收到isr中的所有replicas的 ack，便会向producer发送ack（带有offset），确认消息commit，可以发送下一条消息。

    针对上述消息发送处理过程，不得不提producer发送数据的三种方式，也就是我们经常提到的ack=0，1或-1时数据的发送情况。当request.required.acks=0时，我们称为oneway方式，属于异步方式。该方式只顾消息发出去而不管partitions的followers（包过isr和osr）是否接受到或者写入，消息可靠性最低，但是低延迟、高吞吐，这种方式对可靠性要求不高的场景还是适用的。当request.required.acks=-1时，称之为sync方式。该方式就是前面说的，要求所有isr当中的replicas完成数据的备份，才算完成producer的请求，由leader向producer发送ack。这种方式虽然保证了数据的可靠性，但严重影响了数据的吞吐量，效率降低。当request.required.acks=1时，我们称为async方式。这种方式要求isr中有一个replica完成消息的写入，便可以向producers发送ack。这种方式是前两种方式的折中，维持了一定的可靠性，同时也保障了工作效率，是集群的默认方式。

    kafka集群是通过副本机制保证自己的数据数据不会丢失的。数据的读写是由leader完成的。如果leader所在的broker crash了怎么办？我们知道kafka动态维护了一个同步状态的副本的集合isr，在这个集合中的节点都是和leader保持高度一致的，任何一条消息必须被这个集合中的follower记录下来，才会通知producer这个消息已经被提交了。因此这个集合中的任何一个follower随时都可以被选为leader。isr中有n+1个节点，就可以允许在n个节点down掉的情况下不会丢失消息并正常提供服。isr的成员是动态的，follower在被剔除后还可以加入。

    上文提到，在isr中至少有一个follower时，kafka可以确保已经commit的数据不丢失，但如果某一个partition的所在的broker都crash了，就无法保证数据不丢失了。这种情况下有两种可行的方案：
    1、等待isr中任意一个follower恢复过来，并且选它作为leader
    2、选择第一个恢复过来的follower（并不一定是在ISR中）作为leader
如果一定要等待isr中的follower恢复过来，那时间就可能等待相对较长。而且如果isr中所有的follower无法恢复，这个partition将永不可用。选择第一个恢复过来的follower为leader，则这个follower可能是osr中的，这样就会丢失一部分数据，但这样确保了该partition可用。默认情况下，kafka采用第二种策略，即unclean.leader.election.enable=true，也可以将此参数设置为false来启用第一种策略。unclean.leader.election.enable这个参数对于leader的选举、系统的可用性以及数据的可靠性都有至关重要的影响。