Kafka数据可靠性保证
Kafka数据可靠性保证
-Kafka 采用ACK 应带机制来保证数据的安全性。
生产者发送数据到topic Partition的可靠性保证
-
为保证producer发送的数据能可靠的发送到指定的topic,Topic的每个partition收到producer发送的数据后,都需要向producer发送ack如果producer收到ack,就会进行下一轮的发送,否则重新发送数据。
-
发送ack时间的选择:确保在follower完成从leader的数据同步后，leader再向Producer发送Ack,只有这样才能保证leader挂掉后,从follower中选出来的leader不会有数据丢失。
说明：Kafka不支持读写分离，只有leader支持读写操作，而follower负责备份，数据会先写到leader,然后follower自己去同步。
Topic Partition 存储数据的可靠性保证
- 多少follower同步完成后发送ack的选择:半数以上完成同步发送ack、全部完成同步后发送ack(默认)。
- 半数:延时低,但是选举新的leader时,如果容忍n台节点故障,需要 2n+1 个副本。
- 全部:延时高,但是选举新leader时,容忍n台节点故障,只需要 n+1 个副本即可。
- 由于网络延时对Kafka影响较小,并且在容忍相同节点的故障时,后者只需要 n+1 个副本即可,所以选择了全部同步发送ack。
- 由于需要全部的follwer对leader信息进行同步,如果有一个follwoer节点因为故障迟迟不能与leader进行同步,就会导致leader
持续等待,直到它完成同步后，leader才能发送ack。- 为了解决因为某个follower故障导致的leader迟迟等待不能发送ack的情况,Kafka维护了动态ISR,用来存储与leader保持同步的follower,如果某个follower长时间没有完成同步,会被踢出ISR,该时间阈值由配置文件中的 replica.lag.time.max.ms 参数设定,如果leader故障,就会从ISR中选出新的leader。
ACK应答级别
- 0:这一操作提供了一个最低的延迟,Partition的leader接收到消息还没有写入磁盘就已经返回ack，当leader故障时有可能丢失数据。
- 1：Partition的leader落盘成功后返回ack，如果在follower同步成功之前leader故障，那么将会丢失数据。
- -1：Partition的leader和follower全部落盘成功后才返回ack。但是如果在follower同步完成后，Broker发送ack之前，Leader发生故障，那么会造成数据重复。
Leader和 Follower故障处理
- LEO:指的是每个副本最大的offset。
- HW高水位:指的是消费者能见到的最大的offset,ISR队列中最小的LEO。
-
Follower故障:
Follower 发生故障后会被临时踢出ISR，待该follower恢复后，follower 会读取本地磁盘记录的上次的HW，并将log文件高于HW的部分截取掉，从HW开始向leader进行同步。等该follower的LEO大于等于leader的HW，即follower追上leader之后，就可以重新加入ISR了。
说明：HW之前的数据一定是相应过Ack的。 -
Leader故障:
Leader 发生故障之后,会从ISR中选出一个新的leader,为保证多个副本之间的数据一致性,其余的follower会先将各自的log文件高于HW的部分截掉,然后从新的leader同步数据。新leader的选取时根据Replicas的顺序进行选择。
注意:
HW和LEO只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复。并且新选出来的leader并不能保证HW之后数据的顺序。如果在ack响应等待时间之内,leader 出现故障,生产者会继续发送消息,所以新的leader的HW之后会先接收新的消息,并且没有ack响应生产者会重新发送原来数据,如果HW之后本来就有数据,这部分数据就会重复,如果在ack响应时间之外leader异常,新的leader会重新接收原来的消息,并且HW之后本来就有数据,这部分数据仍就会重复。
