kafka中的HW、LEO、LSO、LW等分别代表什么？

​ ISR与HW和LEO也有紧密的关系，HW是High Watermak的缩写， 俗称高水位，它表示了一个特定消息的偏移量（offset），消费之只能拉取到这个offset之前的消息。

​ 如下，它代表一个日志文件，这个日志文件中有9条消息，第一消息的offset（LogStartOffset）为0，最后的一条消息offset为8，offset为9的消息用虚线框表示，代表下的一个待写入的消息。日志文件的HW为6.表示消费者只能拉取到offset0至5之间的消息，而offset为6的消息对消费者而言是不可见的。

如下图 :

leader副本的LEO为9，follower副本的LEO为7，而follower2副本的LEO为6，如果判定这三个副本都处于ISR集合中，那么分区的HW为6，如果follower3已经判定失效副本被剥离出ISR集合，那么此时分区HW为leader副本和follower副本中LEO的最小值，即为

LEO是Log End Offset的缩写，它表示了当前日志文件中下一条待写入消息的offset，如上图offset为9的位置即为当前日志文件LEO,LEO的大小相当于当前日志分区中最后一条消息的offset值加1。分区ISR集合中的每个副本都会维护自身的LEO，而ISR集合中最小的LEO即为分区的HW，对消费这而言只能消费HW之前的消息。

​ 如下图，假设某个分区的ISR集合中有三个副本，即一个leader副本和两个follower副本，此时分区的LEO和HW都为3。消息3和消息4从生产者发出之后会被先存入leader副本。

在消息写入leader副本之后，follower副本会发送拉取请求来拉取消息3和消息4以进行消息同步。

​ 在同步过程中，不同的follower副本的同步效率也不尽相同。如下图，在某一时刻follower1完全跟上了leader副本而follower2只同步了消息3，如此leader副本的LEO为5，follower1的LEO为5，Follower2的LEO为4。那么当前分区的HW最小值4，此时消费者可以消费到offset为0-3之间的消息。

​ 写入消息如下图，所有的副本都成功写入了消息3和消息4，整个分区的HW和LEO为5，因此消费者可以消费offset为4的消息了。

分区中的所有副本统称为AR（Assigned Repllicas）。所有与leader副本保持一定程度同步的副本（包括Leader）组成ISR（In-Sync Replicas），ISR集合是AR集合中的一个子集。消息会先发送到leader副本，然后follower副本才能从leader副本中拉取消息进行同步，同步期间内follower副本相对于leader副本而言会有一定程度的滞后。前面所说的“一定程度”是指可以忍受的滞后范围，这个范围可以通过参数进行配置。与leader副本同步滞后过多的副本（不包括leader）副本，组成OSR(Out-Sync Relipcas),由此可见：AR=ISR+OSR。在正常情况下，所有的follower副本都应该与leader副本保持一定程度的同步，即AR=ISR,OSR集合为空。

数据一致性保障:

request.required.acks：该参数在producer向leader发送数据时设置。

0：producer无需等待来自broker的确认而继续发送下一批消息。这种情况下数据传输效率最高，但是数据可靠性确是最低的。1（默认）：producer在ISR中的leader已成功收到数据并得到确认。如果leader宕机了，则会丢失数据。-1：producer需要等待ISR中的所有follower都确认接收到数据后才算一次发送完成，可靠性最高。但是这样也不能保证数据不丢失，比如当ISR中只剩下一个leader时，这样就变成了acks=1的情况。min.insync.replicas：该参数在broker或者topic层面进行设置，设定ISR中的最小副本数是多少，默认值为1，当且仅当request.required.acks参数设置为-1时，此参数才生效。如果ISR中的副本数少于min.insync.replicas配置的数量时，客户端会返回异常：org.apache.kafka.common.errors.NotEnoughReplicasExceptoin: Messages are rejected since there are fewer in-sync replicas than required。

unclean.leader.election.enable：

true：默认值，所有replica都有成为leader的可能。false：只有在ISR中存在的replica才有成为leader的可能。要保证数据写入到Kafka是安全的，高可靠的，需要如下的配置：

topic的配置：replication.factor>=3,即副本数至少是3个；2<=min.insync.replicas<=replication.factorbroker的配置：leader的选举条件unclean.leader.election.enable=falseproducer的配置：request.required.acks=-1(all)，producer.type=sync

案例分析:

https://baijiahao.baidu.com/s?id=1649059417410404542&wfr=spider&for=pc