内功提升-kafka producer 核心知识

目录

kafka producer

kafka 分区策略

kafka 数据可靠性保证 - ack

kafka 数据一致性保证 - Hw

消费一致性

存储一致性 同少同重复

1 kafka producer

1.1 分区策略

1.1.1 分区的原因

提高并发，以分区 partition 为单位进行读写操作

1.1.2 生产者生产消息进入的分区3种策略

这三种策略的前提都是明确知道具体的topic1. 明确知道partition index，则直接进入指定partition中2. 不知道partition index，给出了消息对应的key，则 hash(key)mod(num(partitions)) 获取对应的分区partition编号3. 不知道partition index, 但给出了消息的value，第一次调用时生成一个整数，并记录下来，后面每次调用在这个整数上自增，将这个值与topic 可用的partition 总数取余 得到partition值，也是常说的 round-robin 算法

1.2 数据可靠性保证(非常重要，强烈建议深刻理解)

kafka 通过 leader partition发送ack 机制实现消息的可靠传输；

1.2.1 leader partition 发送ack给producer的充要条件:

确保有follower与leader同步完成，leader 再发送ack, 这样能保证leader挂掉之后，follower可以容灾，并从follower中选举出新的leader;

与leader同步的follower个数也有两种不同的策略:

2.1 半数以上的follower同步完成，即可发送ack 优点: 延迟比较低 缺点: 选举新leader时，容忍n台节点故障，需要2n+1个副本

2.2 全部follower完成同步，才发送ack 优点: 容忍n台节点故障，需要n+1个副本 缺点，延迟比较高 kafka 选用全量同步，虽然延迟高，但是数据副本量比较少

1.2.2 kafka the ISR of leader partition - 解决全量同步过程中follower副本挂掉，leader长时间等待的场景

问题1

如果 follower 副本在同步leader 数据的过程中，有一个副本挂掉了，长时间不能跟leader同步，那么leader就要一直等下去，直到挂掉的follower也同步了leader 的数据，才发送ack，这个问题该如何解决?

kafka 通过在leader partition 维护一个动态的ISR即 同步副本（是个set）,来保存与leader保持同步的follower集合。

follower如何被选定为ISR?older version: 同步时间快慢 + 与leader 差异的数据条数 (尽最大努力同步)0.9 版本 new version 去掉了与leader 差异的数据条数因为会频繁操作zk（想象一下 batch_size > 差异数据num策略）,保留了同步时间策略，用来作为选取follower作为ISR元素的依据；默认10s

1.2.3 ack 应答机制

为什么需要ack应答机制在某些场景下可以容忍数据丢失的情况，对数据的可靠性要求不高，能够容忍数据的少量丢失，所有没有必要等待ISR中的Follower全部接收成功所以对于不同场景下的数据可靠性传输、与数据传输性能上的要求，kafka对应给出了如下三种ack应答机制配置策略。

1.2.3.1 acks = 0

0：producer 不等待 leader partition所在的broker 回传的ack，这个操作提供了一个最低的延迟，broker接收到(还没有写入磁盘的时候就已经返回返回)，当broker故障时有可能丢失数据 1：producer 等待 leader partition 所在的broker 回传的ack，leader partition 落盘成功后返回ack，如果follower同步之前leader故障，那么将会丢失数据。-1: producer 等待 leader partition 所在的broker 回传的ack，partition 的leader 和follower 全部落盘成功后才返回ack。

但是，注意在 acks = -1时，在极端情况下还是可能会出现数据丢失的情况(这种情况很少见，但不代表没有)，而且最容易出现的情况是数据重复下面简单清晰的描述下这两种场景:

acks = -1，数据丢失 ISR 中的follower副本数量恰好为0，即当前leader partition接收的数据，没有follower 需要同步，且leader partition 发完ack之后挂掉了，那数据就丢失了。acks = -1, 数据重复 如果ISR 中维护的 followers 同步完数据，leader 在发送ack给producer 之前挂掉了，那么producer就会重发数据给新晋升的leader。此时，数据就会重复发送。

1.3 数据一致性问题

1.3.1 保证消费数据的一致性

场景描述: leader 接收了新一批数据，但是ISR 中follower还未同步完之前就挂掉了，如下图所示，假如consumer已经消费到了19，那么接下来将消费18，此时leader挂掉，新的follower成为leader，那么去消费offset为18(当前最老的数据)就会报错。为应对以上问题，kafka通过 HW & LEO 的机制解决消费一致性问题:

解决方案:HW - High water 高水位 即ISR 中所有 follower 中最小的LEOLEO - 每个副本的最后一个offset

注意: HW 来保证数据一致性，高水位之前的数据是消费者可见的。

1.3.2 脑裂问题-存储的一致性

可能出现脑裂问题 ，leader 挂掉，follower 被选举为新leader， 先前挂掉的leader又重新活了起来，产生脑裂，如果此时producer又新发一批次数据，这两个leader都会接收到数据，那么数据就发生混乱且不一致了。将来消费的数据都不一样 。脑补一下场面就可以了，那么如何解决脑裂产生数据不一致问题呢?新官上任三把火: 告诉所有在ISR中记录的follower，将数据截取到HW, 跟新leader的存储数据保持一致注意 HW只能保证副本数据的一致性，并不能保证数据丢不丢失，或者重不重复，即要少都少，要多都多

以上问题讨论的都是ISR 记录的Follower 范围。