kafka学习_kafka学习（第三篇 kafka producer续）

整理的第三篇读书笔记，整理的过程是一个温故知新的过程，这里不会涉及代码，学习的过程中，源码直接看的是kafka python版本的源码：https://github.com/dpkp/kafka-python/releases，github上有源码、安装方法和使用的API，为了保障和公司开发环境一致，学习过程中安装的版本是2.2.1。

上一篇中讲过producer消息提交后有三种确认机制，一般生产过程中使用的都是ack=all，这种安全性最高，数据最不容易丢失，但是这种的效率最低。ack=all时，发送消息过程中如果某个follow宕机(如下图)，整条消息生产通道会被阻塞，但是实际使用中机会不会出现follow宕机，消息生产通路阻塞的情况，为什么呢？

消息发送流程

今天这篇笔记主要原因。

Kafka在0.8版本之后，优化了数据复制的机制，并不是所有副本全部复制成功之后才返回commit消息给producer端，而是每个leader动态维护一个待同步的副本列表(ISR)，只要保障消息同步至ISR中的所有follower，即返回commit消息给producer。

什么是ISR？

ISR：In Sync Replica，能和leader 副本基本保持一致的follower副本集合，如果follower副本同步消息过慢，会被从ISR副本集合中剔除。

这么看动态的副本管理机制就可以解决follower宕机后，消息通路阻塞问题了。那follower副本消息同步过慢的标准是什么呢？

副本落后的标准：Kafka server端通过两个配置判断follower是否出现滞后，这个两个参数根据系统的要求进行实际配置，如下：

1. replica.lag.max.messages=5000，是指follower消息落后leader超过设置条数时，leader会将其从ISR中剔除
2. replica.lag.time.max.ms=10000，是指follower超过设定时间没有发送fetch请求给leader，leader会将其从ISR中剔除

这样就能保障producer发送消息的时候，不会因为follower原因导致通路阻塞，如果ISR之外的副本满足这两个条件时，会被加入到ISR列表。

实际生产过程中，follower和leader均会出现宕机的情况，宕机后经常出现的问题就是数据一致性的问题。

kafka如何保证生产消息时，服务器宕机后消息的一致性呢？

ISR中有两个重要的概念：HW、LEO

1. LEO：Log End Offset，当前日志文件中下一次待写入消息的offset
2. HW：high water，ISR集合中最小的LEO即为分区的HW，对于消费者而言，只能消费HW之前的消息这样可以保障，leader宕机消费者消费的消息也不会出现不一致；

同时根据每个replica的LEO，可以判断该replica是否需要从ISR中剔除。

HW & LEO

上面是从消费者消费的角度来讲数据一致性的保障，那么从生产者角度来讲，怎么保kafka server宕机后，生产消息的一致性呢？

以leader宕机为例，如下图：

leader宕机

因为kafka中和外界进行消息交互均是由leader负责，那么一旦leader宕机，必须快速选举出一个新的leader，保障leader失效后可以快速恢复并且恢复后消息不丢失。

leader选举机制：

1.Leader选举原则，宕机后只能从ISR列表中选取新的leader，这样无论哪个副本当选，新leader的HW是已知的并且和宕机前保持一致，这样消费者消费数据前后一致；2.HW截断机制：选举新leader，新leader不能保障已完全同步之前leader的数据，所以所有副本数据均需截断到HW(即LEO均变为HW)，重新同步新leader的数据，保障生产数据一致性；

ISR中选举新leader & 截断至HW

小白一枚，可能有些问题说的不准确，欢迎大家留言交流，一起学习。