Kafka数据可靠性的保证

Kafka如何保证数据可靠性

---

1、可靠性策略

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

---

2、同步策略的问题

• Partition到底什么时候发送这个ack？

  确保有follower与leader同步完成， leader再发送ack，这样才能保证leader挂掉之后，能在follower中选举出新的leader。

• 多少follower与leader同步完成我们才发送ack？

  • 半数以上
  • 全部

现在我们就第二个问题,也就是副本同步策略，做以简单评估。

解决方案	优点	缺点
半数以上follower同步完成后发送ack	效率高，低延迟	若leader宕机，选举新leader时，如果考虑到N台机器故障，我们需要2N+1个副本
全部follwer同步完成后发送ack	若leader宕机，选举新leader时，如果考虑到N台机器故障，我们只需要N+1个副本	延迟高

TIPS：关于上述优缺点的简单解释。

• 半数以上方案的缺点解释：宕机的N个机器，它们可能是同步好数据的那部分，也可能是没有同步好的那部分。如果坏掉的是同步好的那部分，那我们只需要N+1个副本(多出来的这个副本是仅仅或者说专门用来备份的节点机器，懂我意思吧)，如果坏掉的不是同步好的那部分，本身没有同步的数据，而且还缺一份备份，所以需要2N+1
• 全部同步才发送ack的方案：因为是所有的follower都同步好了，参照上面的解释，我们就仅仅需要N+1个副本就好。

Kaffka最后选择了哪种方案作为同步策略呢？

Kafka选择了第二种全部同步完成后再发送ack的策略。

• 第一种方案会造成大量数据冗余
• 第二种方案虽然可能延迟高，但是这种延迟对于Kafka来说影响其实不大。

---

3、ISR (in-sync replica set 和leader保持同步的follow集合)

在我们采用第二种全部同步完成后再发送ack的策略后，会出现一个新问题。

生产者发送消息，leader接收数据，所有的follower开始同步数据，但是其中某一个follower可能因为某种故障，迟迟无法同步完成，基于第二种策略来思考，leader就会一直等下去直到这个follower完成同步才能发送ack。设想如果故障的follower同步一分钟、一小时、一天、一年才完成呢？leader要一直等下去吗？

为了解决这样一个问题，Kafka有这样一个策略。

• Leader其实会维护一个动态的in-sync replica set(ISR)，即和leader保持同步的follower集合。如果某个follower长时间没有向leader同步数据，则该follower踢出ISR，其中这个同步时间可由replica.lag.time.max.ms参数来设定。

🐕TIPS：leader挂了就是从ISR中重新选举的。

---

4、ACK应答机制

在实际环境中，数据有重要和不重要这样一个区别。对于不重要的数据，可以容忍有少量数据丢失的情况下，其实没有必要等ISR中全部同步成功的。

基于此，Kafka为用户提供了三种可靠级别，我们就可以根据实际可靠性和延迟的要求进行权衡。

我们可以通过设置acks参数来选择，下面简单介绍acks参数的配置：

• 0：producer不等待broker的ack，可想而知，这样做延迟会是最低的，broker一接收到就返回，不管你是否已经写入磁盘做好备份等数据可靠性的操作，那么当broker故障时就有可能数据丢失。
• 1：producer等待broker的ack，partition的leader写盘成功后返回ack，如果在follower同步成功之前leader故障，那么将会丢失数据。
• -1/all：producer等待broker的ack，partition的leader和follower全部落盘成功后才返回ack。但是如果在follower同步完成后，broker发送ack之前，leader发生故障，那么会造成数据重复。