Kafka中关于集群副本的一些理解

什么是副本？

简单的理解一下，副本就是对于分区中消息的备份，是kafka中通过数据的冗余保证高可用的一种方式，所以副本又是建立在kafka集群模式的基础上的。

下图中表示的含义为：集群中有3台broker，有一个名为topic的主题，设置了分区数为3，副本数量为3。

首领含义稍后解释。

如果分区的数量大于broker数量时，就会变成这样，其中一个broker上会存放2个分区首领。
如下图表示的含义为：集群中有2台broker，一个名为topic的主题，设置了分区数为3，副本数量为2，其中有两个首领都在broker上。

分区中的首领会尽量保持均匀的存放在不同的broker中，以提高消息的处理能力与kafka的可用性，因为只有首领分区才会处理消息的接收与发送。

注意，副本的数量不能大于broker数量，否则会报错。
下面中个例子中我只启动了2台broker，却想创建了3个副本，所以报错了，提示信息也很明显。

当broker数量为3台时，创建成功。

什么是分区中首领副本？

当我们设置一定副本数量时，有且只有一个副本是首领（leader）副本，其余的副本都是跟随者（follower）副本。

生产者发送的消息只会由leader副本直接接收到，同样的，消费者拉取消息也只会从leader副本中拉取，follower副本只负责不断的从leader副本中同步数据即可，会尽量的让自己与leader保持一致，这也是一种冗余设计，以此来保证高可用性。

什么是分区中的跟随者副本？

分区副本中除了首领副本，其余的都是跟随者副本，跟随者副本不会接收与发送消息，只负责从首领副本中同步消息，以保证与首领副本中的消息一致，在首领副本发送故障时，通过选举变为新的首领副本，以此保证可用性与一致性。

什么是ISR？

ISR（In-Sync Replica），是与分区leader保持同步的副本集合，在leader宕机时，一般会优先从ISR中选举一个作为新的首领，所以follower副本会不断的从leader副本中拉取并同步消息，以保证自己在ISR集合中。

3台broker组成集群，broker.id为别为：0、1、2
创建了一个主题名为：test_repli
分区数量：6
分区副本数：3

从图中可以看出，每台broker均匀承担了2个分区的leader，每一个分区都有3个副本，isr副本有的分区是全量的，有的分区则并没有满足条件。

当把borker.id为2的停掉，可以看出原来leader为2的分区，一台为0，一台为1了。isr中也没有了id为2的副本了。
至于为什么replicas中为什么还有id为2，那是因为这列信息不管是否boker是否存活都会显示。

那么什么样follower可以视为与leader保持同步呢？或者说满足什么样的条件就可以放入ISR中？

实际上由于网络抖动，通信延迟，突然流量等原因，并不一定要follower与leader保持完全一致才可以放入ISR。

在0.9.0.0版本之前，有一个参数replica.lag.max.messages，意为当副本中的追随者与leader最多相差多少条消息时，则会被踢出，这个参数在突发流量的场景下很容易造成追随者被频繁的踢出，平稳后又被加入ISR中。
所以之后的版本中衡量一个跟随者是否能存在ISR中只有一个参数replica.lag.time.max.ms，意为最长多少时间不向leader请求数据，则被判定不同步，被踢出ISR。

假如ISR列表中只有leader自己，其他所有的副本都没有与leader保持同步，那么这时候如果leader宕机了，该怎么办呢？

1. 等待ISR中任意一个副本出现，选举为leader
2. 随便选择一个跟随者，选举为leader

第一种方案可能会造成等待时间较长，如果ISR中所有的副本都无法活过来了，则分区会变的永久不可用，侧重于数据的可靠性。
第二种方案虽然可能会丢失消息，但是保证了可用性。

unclean.leader.election.enable参数决定使用哪一种，默认true（在0.11.0.0版本后默认为false）。

为true表示：允许从非ISR副本中选择一个跟随者，选举为leader。
为false表示：必须从ISR副本中选择leader。

关于这个参数到底是设置true还是false，需要结合自己的业务区理解，不过可以看出kafka官方更侧重于数据的可靠性。

最小同步副本？
与ISR相关的还有一个参数min.insync.replicas（最小同步副本），只有当ISR中的数量大于等于最小同步副本数时，生产者的消息才会被提交，即生产者才会被告知消息发送成功。

注意这个参数必须是生产者设置ack为all时才会生效，如果ack设置为0或者1时，表示的含义明显与最小同步副本冲突。

关于ack含义的补充：
0:生产者只要把消息发送出去即可，不用等待broker的处理结果，吞吐量最高，同样消息的丢失率也最高。
1:生成者需要等分区leader将消息写入成功后 才认为此消息发送成功，1是ack的默认配置，兼顾了吞吐量和消息丢失的问题，但是同样有消息丢失的风险，比如当leader写入成功后突然挂了，其他分区跟随者并为能够将此消息同步，则此消息丢失。
all:生产者会等待所有的副本都写入成功后才认为此消息发送成功，此方法保证了消息不丢失，但也是吞吐量最低的。