首先我们知道在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了。
注意:这只能保证副本之间的数据一致性,并不能保证数据不丢失或者不重复。