Kafka如何保证数据可靠性

• 分区策略

（1）指明 partition 的情况下，直接将指明的值直接作为 partiton 值；

（2）没有指明 partition 值但有 key 的情况下，将 key 的 hash 值与 topic 的 partition 数进行取余得到 partition 值；

（3）既没有 partition 值又没有 key 值的情况下，第一次调用时随机生成一个整数（后面每次调用在这个整数上自增），将这个值与 topic 可用的 partition 总数取余得到 partition 值，也就是常说的 round-robin 算法。

• 数据可靠性保证

    正常情况下，为保证producer发送的数据，producer向Leader发送数据，leader收到后返回ack（acknowledgement确认收到），producer继续发下一条数据。如果等不到leader的ack回复，producer则在重复机制的作用下，向leader重复发送未成功发送的数据。

这样便会产生两个问题。

问题一：leader何时发送ack？

解答：leader需要确保有follower与之同步完成才发送ack，因为这样才能避免在leader宕掉后，能在follower·中选举出新的leader。

第二：需要多少个follower同步？（副本同步策略）

解答：现有两个方案。1：半数以上同步即可；2：全部同步

    1）针对以上两种方案提出优缺点对比，即副本数据同步策略

方案	优点	缺点
半数以上完成同步即发送ack	延迟低（可避免因某一台节点拖后腿）	选举新的leader时，容忍n台节点的故障，需要2n+1个副本
全部完成同步即发送ack	选举新的leader时，容忍n台节点的故障，需要n+1个副本	延迟高（必须等最慢的一台机器同步）

Kafka选择了第二种方案，原因如下：

1.同样为了容忍n台节点的故障，第一种方案需要2n+1个副本，而第二种方案只需要n+1个副本，而Kafka的每个分区都有大量的数据，第一种方案会造成大量数据的冗余。

2.虽然第二种方案的网络延迟会比较高，但网络延迟对Kafka的影响较小。

    2）ISR

    采用第二种方案之后，设想以下情景：如果因为某种原因导致某一台follower始终没有想leader同步，此时集群是否就此中断？就这个问题怎么解决呢？

    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。即在所有follower中圈出一些跟得上的机器，跟不上的先踢出去，让他慢慢恢复。（ISR为所有follower·的子集）

    3）ack应答机制

对于某些不太重要的数据，对数据的可靠性要求不是很高，能够容忍数据的少量丢失，所以没必要等ISR中的follower全部接收成功。

所以Kafka为用户提供了三种可靠性级别，用户根据对可靠性和延迟的要求进行权衡，选择以下的配置。

• acks参数配置：

acks：（0,1可能丢数据；2可能数据重复）

0：producer不等待broker的ack，这一操作提供了一个最低的延迟，broker一接收到还没有写入磁盘就已经返回，当broker故障时有可能丢失数据；（数据还没落盘呢）

1：producer等待broker的ack，partition的leader落盘成功后返回ack，如果在follower同步成功之前leader故障，那么将会丢失数据；（数据在leader落盘了，也确认了，但是follower尚未同步leader就宕掉了）

-1（all）：producer等待broker的ack，partition的leader和follower全部落盘成功后才返回ack。但是如果在follower同步完成后，broker发送ack之前，leader发生故障，那么会造成数据重复。（A数据在leader落盘成功，follower·同步成功，但leader尚未发送ack变宕掉了，此时选出新的leader（已经同步有A数据），producer向新的leader重新发送A数据，导致数据重复）

    4）故障处理细节

（1）follower故障

follower发生故障后会被临时踢出ISR，待该follower恢复后，follower会读取本地磁盘记录的上次的HW，并将log文件高于HW的部分截取掉，从HW开始向leader进行同步。等该follower的LEO大于等于该Partition的HW，即follower追上leader之后，就可以重新加入ISR了。

（2）leader故障

leader发生故障之后，会从ISR中选出一个新的leader，之后，为保证多个副本之间的数据一致性，其余的follower会先将各自的log文件高于HW的部分截掉，然后从新的leader同步数据。

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

• Exactly Once语义

对于某些比较重要的消息，我们需要保证exactly once语义，即保证每条消息被发送且仅被发送一次。

在0.11版本之后，Kafka引入了幂等性机制（idempotent），配合acks = -1时的at least once语义，实现了producer到broker的exactly once语义。

idempotent + at least once = exactly once

使用时，只需将enable.idempotence属性设置为true，kafka自动将acks属性设为-1，还有失败重复次数设定为long类型的最大值。

（producer的id+消息id即可保证数据的唯一性，保证数据唯一性是根据两个id来确保重复数据不落盘，而不是数据落盘后去重）