【KAFKA】浅谈Kafka数据可靠性保证

首先我们知道在Kafka中

• 一台kafka服务器就是一个broker。
• 一个broker可以容纳多个topic。
• 一个topic可以分为多个partition。
• 一个partition有若干个副本（一个leader和若干个follower）。

生产者发送数据的对象，以及消费者消费数据的对象都是leader。

follower实时从leader中同步数据，保持和leader数据的同步。
leader发生故障时，某个follower会成为新的leader。

那么如何保证producer向kafka发送的数据已经被leader和follower都安全的写入到磁盘了呢？

答案是：ACK (acknowledgement确认收到)

为保证producer发送的数据，能可靠的发送到指定的topic，topic的每个partition收到producer发送的数据后，都需要向producer发送ack，如果producer收到ack，就会进行下一轮的发送，否则重新发送数据。

而Kafka也根据对数据的可靠性要求高或者低提供了三种可靠性级别

• acks = 0 时。producer不等待broker的ack。broker一接收到还没有写入磁盘就已经返回。提高了速度，但是数据可靠性极低，当broker发生故障会丢失数据。
• acks = 1 时。producer只等待broker中的leader的ack。当leader落盘成功发送ack后，表示数据传输完毕。效率中等，但若是此时follower还没有写入磁盘时leader故障，那么数据丢失。
• ack = -1 时。producer等待broker中所有分区的ack。提高了可靠性，降低了速度。如果在follower同步完成后，broker发送ack之前，leader发生故障，那么会造成数据重复。

那么，当Leader发生故障或者follower发生故障长时间不与leader同步数据，kafka如何解决呢？

答案是：ISR（in-sync replica set 同步副本集）

Leader维护了一个动态的in-sync replica set (ISR)，意为和leader保持同步的follower集合。当ISR中的follower完成数据的同步之后，leader就会给follower发送ack。如果follower长时间未向leader同步数据，则该follower将被踢出ISR，该时间阈值由replica.lag.time.max.ms参数设定。Leader发生故障之后，就会从ISR中选举新的leader。

• leader发生故障
  leader发生故障之后，会从ISR中选出一个新的leader，之后，为保证多个副本之间的数据一致性，其余的follower会先将各自的log文件高于HW的部分截掉，然后从新的leader同步数据。
• follower发生故障
  follower发生故障后会被临时踢出ISR，待该follower恢复后，follower会读取本地磁盘记录的上次的HW，并将log文件高于HW的部分截取掉，从HW开始向leader进行同步。等该follower的LEO大于等于该Partition的HW，即follower追上leader之后，就可以重新加入ISR了。

注意：这只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复。