Kafka之ISR机制的理解
Kafka对于producer发来的消息怎么保证可靠性？
每个partition都给配上副本，做数据同步，保证数据不丢失。
副本数据同步策略
和zookeeper不同的是，Kafka选择的是全部完成同步，才发送ack。但是⼜有所区别。
所以，你们才会在各种博客看到这句话【kafka不是完全同步，也不是完全异步，是⼀种ISR机制】
这句话对也不对，不对也对（谜语⼈......）
⾸先笔者认为：Kafka使⽤的就是完全同步⽅案。
完全同步的优点
同样为了容忍 n 台节点的故障，过半机制需要 2n+1 个副本，⽽全部同步⽅案只需要 n+1 个副本，
⽽ Kafka 的每个分区都有⼤量的数据，过半机制⽅案会造成⼤量数据的冗余。（这就是和zookeeper的不同）完全同步会有什么问题？
假设就有这么⼀个follower延迟太⾼或者某种故障的情况出现，导致迟迟不能与leader进⾏同步。
怎么办？leader等还是不等？
等吧：producer有话要说：“Kafka也不⾏啊，处理个消息这么费劲，垃圾，你等NM呢等”
不等：那你Kafka对外说完全同步个鸡⼉，你这是完全同步么？
基于此，Kafka的设计者和开发者想出了⼀个⾮常鸡贼的点⼦：ISR
什么是ISR？
先来看⼏个概念
1、AR（Assigned Repllicas）⼀个partition的所有副本（就是replica，不区分leader或follower）
2、ISR（In-Sync Replicas）能够和 leader 保持同步的 follower + leader本⾝ 组成的集合。
3、OSR（Out-Sync Relipcas）不能和 leader 保持同步的 follower 集合
4、公式：AR = ISR + OSR
所以，看明⽩了吗？
Kafka对外依然可以声称是完全同步，但是承诺是对AR中的所有replica完全同步了吗？
并没有。Kafka只保证对ISR集合中的所有副本保证完全同步。
⾄于，ISR到底有多少个follower，那不知道，别问，问就是完全同步，你再问就多了。
这就好⽐⽹购买⼀送⼀，结果邮来了⼀⼤⼀⼩两个产品。
你可能觉得有问题，其实是没问题的，商家说送的那个是⼀模⼀样的了吗？并没有。
ISR就是这个道理，Kafka是⼀定会保证leader接收到的消息完全同步给ISR中的所有副本。
⽽最坏的情况下，ISR中只剩leader⾃⼰。
基于此，上述完全同步会出现的问题就不是问题了。
因为ISR的机制就保证了，处于ISR内部的follower都是可以和leader进⾏同步的，⼀旦出现故障或延迟，就会被踢出ISR。
ISR 的核⼼就是：动态调整
总结：Kafka采⽤的就是⼀种完全同步的⽅案，⽽ISR是基于完全同步的⼀种优化机制。
follower的作⽤
读写都是由leader处理，follower只是作备份功能，不对外提供服务。
什么情况ISR中的replica会被踢出ISR？
以前有2个配置
# 默认10000 即 10秒
replica.lag.time.max.ms
# 允许 follower 副本落后 leader 副本的消息数量，超过这个数量后，follower 会被踢出 ISR
replica.ssages
说⽩了就是⼀个衡量leader和follower之间差距的标准。
⼀个是基于时间间隔，⼀个是基于消息条数。
0.9.0.0版本之后，移除了replica.ssages 配置。
为什么？
因为producer是可以批量发送消息的，很容易超过replica.ssages，那么被踢出ISR的follower就是受了⽆妄之灾。他们都是没问题的，既没有出故障也没⾼延迟，凭什么被踢？
replica.ssages调⼤呢？调多⼤？太⼤了是否会有漏⽹之鱼，造成数据丢失风险？
这就是replica.ssages的设计缺陷。
replica.lag.time.max.ms的误区
【只要在 replica.lag.time.max.ms 时间内 follower 有同步消息，即认为该 follower 处于 ISR 中】
你去⽹上看博客，很多博客表达的就是这个意思，不过笔者认为这么描述很容易误导初学者。
那我是不是可以理解为，follower有个定时任务，只要在replica.lag.time.max.ms时间内去leader那pull数据就⾏了。
其实不是的。千万不要这么认为，因为这⾥还涉及⼀个速率问题（你理解为蓄⽔池⼀个放⽔⼀个注⽔
的问题）。
如果leader副本的消息流⼊速度⼤于follower副本的拉取速度时，你follower就是实时同步有什么⽤？
典型的出⼯不出⼒，消息只会越差越多，这种follower肯定是要被踢出ISR的。
当follower副本将leader副本的LEO之前的⽇志全部同步时，则认为该follower副本已经追赶上leader副本。
此时更新该副本的lastCaughtUpTimeMs标识。
Kafka的副本管理器（ReplicaManager）启动时会启动⼀个副本过期检测的定时任务，
会定时检查当前时间与副本的lastCaughtUpTimeMs差值是否⼤于参数replica.lag.time.max.ms指定的值。
所以replica.lag.time.max.ms的正确理解是：
follower在过去的replica.lag.time.max.ms时间内，已经追赶上leader⼀次了。
follower到底出了什么问题？
两个⽅⾯，⼀个是Kafka⾃⾝的问题，另⼀个是外部原因
Kafka源码注释中说明了⼀般有两种情况会导致副本失效：
1、follower副本进程卡住，在⼀段时间内根本没有想leader副本发起同步请求，⽐如频繁的Full GC。
2、follower副本进程同步过慢，在⼀段时间内都⽆法追赶上leader副本，⽐如IO开销过⼤。
1、通过⼯具增加了副本因⼦，那么新增加的副本在赶上leader副本之前也都是处于失效状态的。
2、如果⼀个follower副本由于某些原因（⽐如宕机）⽽下线，之后⼜上线，在追赶上leader副本之前也是出于失效状态。
什么情况OSR中的replica会重新加⼊ISR？
基于上述，replica重新追上了leader，就会回到ISR中。
相关的重要概念
需要先明确⼏个概念：
1、LEO（last end offt）：
当前replica存的最⼤的offt的下⼀个值
2、HW（high watermark）：
⼩于 HW 值的offt所对应的消息被认为是“已提交”或“已备份”的消息，才对消费者可见。
假设ISR中⽬前有1个leader，3个follower。
1、leader接收⼀个消息，⾃⼰保存后，马上发送3个请求通知3个follower赶紧保存
2、等待3个follower响应保存成功
3、响应producer，消息提交成功
你是这么想的么？反正当时我是这么想的。
实际上不是的，这个同步是follower主动去请求leader进⾏同步的。
因为是每个follower情况不⼀样，所以才会出现LEO和HW的概念。
简⾔之，⽊桶原理
replica⾥存了多少数据和consumer能消费多少数据，不是⼀回事。
所谓⽊桶原理，就是把每个replica当作⼀个⽊桶的板⼦，桶能装多少⽔只取决于最短的那块板⼦。
这就是也有些⼈把HW叫成 ⾼⽔位 的原因。
⽽ HW 的概念，也契合前⽂提到的【完全同步】，HW之前的所有消息，在ISR中是完全同步的。
写在最后的话
【推荐⼤家在看Kafka相关博客⽂章视频的时候，遇到任何问题不要纠结，赶紧翻书，Kafka相关的博客真的⼀⾔难尽】
就这块的知识点，⼤家请注意，你去看博客或者公众号或者培训机构的视频，介绍的五花⼋门， 含糊不清。
咱也不知道都是在哪学的.....笔者在Kafka官⽅⽂档中搜索关键字，并未搜索到，也可能是我的搜索⽅式不对，
总之那些⼜画线，⼜上⾊的，图整了不少，整的花⾥胡哨的，都TM不⼀样。
还俗称“⾼⽔位”，俩破单词不够你得瑟的了，你是不是觉得你讲的⽣动形象
前提是知识点要准确啊，瞎JB⽐喻！
如果你把consumer可见消息⽐喻成⽔，HW⽐喻“⽔位”，
那么HW就是consumer可见的那个最⼤的offt，因为⽔位就是⽔⾯，⽔⾯也是⽔。
⽽如果不是，那我宁愿把HW⽐喻成船。紧贴⽔⾯的就是船，船永远在⽔⾯之上，⽔涨⽽船⾼。
很多图，都把replica化成了数组的模样，offt好似数组的index，
如果是这样，我宁愿把LEO⽐喻成 C语⾔字符串中的 "\0"，就是标识位。
笔者猜测，LEO应该除了记录offt，还记录了⼀个像gment的index⽂件⾥的position⼀样。
指向最后⼀个消息有啥⽤，还不是要算⼀次偏移量，才能记录新消息。如果这个物理地址记录的是最后⼀个消息的后⾯的位置，那么新消息进来就能直接定位，直接写⽂件了。
【HW就是ISR中最⼩的LEO】有⼈也这么说的。有说HW <= LEO的，有说HW < LEO。爷吐了.....
随便截2篇博客，⼤家先尝尝。
我写的只是⼀个能说服我⾃⼰的概念知识点，对错我保证不了。
希望精通源码的⼤佬看到能在评论区解惑，不胜感激。
------- 路漫漫其修远兮，我求索NMLB。
