kafka的isr机制

Data Replication

Kafka 的 Data Replication 需要解决如下问题：

怎样 Propagate 消息
在向 Producer 发送 ACK 前需要保证有多少个 Replica 已经收到该消息
怎样处理某个 Replica 不工作的情况
怎样处理 Failed Replica 恢复回来的情况

Propagate 消息
通过zookeeper先知道leader在哪一台机器上，然后produce将消息发送到leader上，Follower 在收到该消息并写入其 Log 后，向 Leader 发送 ACK。一旦 Leader 收到了 ISR 中的所有 Replica 的 ACK，该消息就被认为已经 commit 了，Leader 将增加 HW 并且向 Producer 发送 ACK。

ACK 前需要保证有多少个 Replica 已经收到该消息
Leader 会跟踪与其保持同步的 Replica 列表，该列表称为 ISR（即 in-sync Replica）。如果一个 Follower 宕机，或者落后太多，Leader 将把它从 ISR 中移除。

Kafka 的复制机制既不是完全的同步复制，也不是单纯的异步复制。完全同步复制要求所有能工作的 Follower 都复制完，这条消息才会被认为 commit，这种复制方式极大的影响了吞吐率（高吞吐率是 Kafka 非常重要的一个特性）。而异步复制方式下，Follower 异步的从 Leader 复制数据，数据只要被 Leader 写入 log 就被认为已经 commit，这种情况下如果 Follower 都复制完都落后于 Leader，而如果 Leader 突然宕机，则会丢失数据。

Data Replication如何处理Replica全部宕机
1、等待ISR中任一Replica恢复,并选它为Leader

等待时间较长,降低可用性
或ISR中的所有Replica都无法恢复或者数据丢失,则该Partition将永不可用
2、选择第一个恢复的Replica为新的Leader,无论它是否在ISR中

并未包含所有已被之前Leader Commit过的消息,因此会造成数据丢失
可用性较高

Data Replication如何处理Replica恢复
leader挂掉了，从它的follower中选举一个作为leader，并把挂掉的leader从ISR中移除，继续处理数据。一段时间后该leader重新启动了，它知道它之前的数据到哪里了，尝试获取它挂掉后leader处理的数据，获取完成后它就加入了ISR。

ack机制
方案                                                                优点                                                                                               缺点
半数以上完成同步，就发送ack                    延迟低                                                                         选举新的leader时，容忍n台节点的故障，需要2n+1个副本
全部完成同步，才发送ack              选举新的leader时，容忍n台节点的故障，需要n+1个副本                           延迟高

Exactly Once
在0.11版本之后，Kafka引入了幂等性机制（idempotent），配合acks = -1时的at least once语义，实现了producer到broker的exactly once语义。

idempotent + at least once = exactly once

使用时，只需将enable.idempotence属性设置为true，kafka自动将acks属性设为-1。

参考文献:
https://www.infoq.cn/article/kafka-analysis-part-2
https://blog.csdn.net/qq_37502106/article/details/80271800
https://colobu.com/2017/11/02/kafka-replication/