1、名词解释
1. 基本名词
- 主题：topic。逻辑概念，用于区分业务
- 服务器：broker。接收持久化消息，管理topic，权限管理，consumer重平衡等等
- 分区：partition。一个有序的消息序列，一个topic对应多个分区
- 消息：record。不做解释
- 消息位移：Offset。分区中每条消息的位置
- 生产者：producer。不做解释~~~~
- 消费者：consumer。不做解释
2.副本与ISR
这两个是broker里面的两个概念名词。
所谓_副本_，就是kafka为了提高可用性，将同一个parition数据分散到不同broker的数据备份。同时kafka会选出一个leader副本用于对外读，follower则需要主动向leader副本请求同步kafka日志，以保证主从副本数据保持一致。
所谓_ISR_，就是有资格能被评选为leader副本的follower副本集合。只有leader和ISR中所有副本都同步状态了，才会被kafka认为该消息已经提交。
3、副本中的概念
起始位移（ base offset ）：该副本第一条消息的位移
高水印值（ high watermark, HW ）：该副本最新一条_已经提交_的消息位移。_如果某个消息的offset小于该值，则所有的副本都已经同步这条消息了；如果某个消息的offset大于该值，则肯说明些副本还没同步到这条消息_。换一种说法，所有offset小于该值的消息对consumer是可见的；而大于该值的是不可见的。该值非常重要，他的值影响到副本主从同步的位置，影响到consumer消费数据的位置。应该注意的是，HW不止在leader里存在，在follower里也存在，其原因就是为了防止leader崩溃，follower也能立即顶替leader进行正常工作（最终一致性）。
日志末端位移 （Clog end offset, LEO ）：该副本最后一条信息的位移
2、消息同步流程
1、整体流程
①broker1上的 leader 副本接收到消息，把自己的 LEO 值更新为 1 。
②broker2 和 broker3 上的 follower 副本各自发送请求给 broker 1。（一般情况下，是follower定时给leader发送fetch请求的，就好像heartbeat心跳）
③broker1收到fetch请求后，主动分别把该消息推送给 follower 副本 。
④follower 副本接收到消息后各自更新自己的 LEO 为 1，并返回response。
⑤leader 副本接收到其他 follower 副本的数据请求响应（ response ）之后，更新 HW 值为 1 。 此时位移为 0 的这条消息可以被 consumer 消费。
2、流程细节
_原则：HW是当前已知的所有LEO的最小值_。为什么呢？正常情况下，各个broker的partition数据都是顺序写入的，最小的LEO意味着所有的副本都同步到了这个LEO以前的所有数据，就满足了“HW之前的消息都已经同步完成”的要求。
为了便于描述，我们假设有两个副本在同步数据，一个leader一个follower
第一轮fetch
在某一时刻，leader收到了一条信息，写入了底层数据，接下来就是数据同步的过程了。
1、leader的LEO +1，好理解，有了一条信息，尾数需要加一。
2、leader尝试更新HW，取所有副本LEO最小值，本例是0。那么，哪里获取各个副本最小值呢？leader副本本地有个地方专门负责缓存这个数据，其他follower通过fetch请求告知leader
这个时候，follower发送了fetch（fetch请求里会带着自己现在的LEO，现在是0），leader收到了fetch
3、leader收到了fetch，尝试更新HW。所有副本LEO最小值。自己的是1，fetch里是0，那么是0。
4、获取offset ＞follower LEO的数据放到response里，同时将自己的HW(注意！！此时是全局LEO最小值)放到response里，本例里是0
5、follower接受到了response，将数据写入，同时更新LEO，本例里+1
6、follower尝试更新HW，是全局LEO最小值，比较response里的HW和自己的LEO取最小值即可（上面红字的特性，这里就用到了）。本例里更新后是0
此时第一轮fetch结束，应该注意到，第一轮fetch完成后，数据虽然同步过去了，但是还不可见，因为leader此时还不知道follower是不是同步成功了
第二轮fetch
1、follower发送了fetch请求，携带自己的LEO=1
2、leader尝试更新HW，全局LEO的最小值，因此是1
3、获取offset ＞follower LEO的数据放到response里，这次没有数据，同时将自己的HW=1放到response里
4、follower收到信息，没数据写入，然后尝试更新自己的HW，全局最小值，本例HW=1
此时第二轮fetch结束，此时此刻，数据同步才真正结束，这条新数据对外可见了
3、数据丢失问题
综合上面的论述，经过两轮fetch过程后才会对外可见。这个时间差就容易导致数据丢失或者不一致的问题
场景一：两轮fetch中间发生follwer和leader先后崩溃，前提：leader写入完成即认为已提交
如图，假如第二轮fetch发生，A已经更新了HW，但是还没有包装response返回给B，此时B发生了崩溃。重启后的B会将LEO调整成崩溃前的HW值，那么后面的数据就被删除了（看，此时出现了一次数据不一致）。这个时候B想要向A发起fetch，如果这个时候恰好A挂掉了，B被选为leader，A重启回来后就会fetch取leader的HW和自己的LEO比较取最小值，最后得到HW=1，这样原来HW=2的数据就永久丢失了。
场景二：两轮fetch中，follower和leader同时崩溃
还是上面那种情况，第二轮fetch发生，A已经更新了HW，但是还没有包装response返回给B。这个时候leader和follower同时崩溃，然后B先重启成为leader了。这个时候，producer发送了一个消息记录到B，此时因为没有follower，因此直接更新HW到2。而后A回来成为follower，这时，A发现自己的HW和B的HW相等，因此不做变更。但是A的HW指向的消息和B的HW指向的消息并不是一回事，这显然就不是我们想要的了。
4、数据丢失问题的解决
kafka 0.11版本之后引入了leader epoch（我理解其实就是带有版本信息的HW）来取代HW，同时重启后的follower增加了一种请求，解决了这个问题。（这也是为啥商业使用基本上都用0.11之后的版本）。epoch实际上是一对值（epoch,offset）。 epoch 表示 leader 的版本号，offset表示本次写入的位置。比如（0,0）就代表这是第一次写入，写入位置是0 。(1,120)就代表，这是第二次写入，写入位置是120（前面已经写了119个数据）
场景一的解决：
场景二的解决：
**附录：leader 中HW的更新条件**
1. 副本成为leader副本的时候
2. 集群里有broker崩溃，退出ISR的时候
3. producer向leader推送数据的时候