大佬教程收集整理的这篇文章主要介绍了Kafka生产者,大佬教程大佬觉得挺不错的,现在分享给大家,也给大家做个参考。
几个关键点
分区策略
分区原因
生产者往哪个分区写
可靠性保证(发送的环节)
ack机制&何时发送ack&同步几个发送ack
两种副本同步策略比较(全同步&半同步)
ISR待同步副本集合(小弟骨干集合)
acks的三种配置化和各自的问题
一致性保证(故障细节处理)
leader故障后带来的两个问题
Leo和HW的引入
Exactly Once语义和幂等性的实现
此处是先保证发数据这个环节的可靠性,也就是保证producer的数据可以可靠的发送到指定topic下的partition。
接收数据的单位是partition,则其每个partition收到数据后,需要像producer发送ack确认收到,producer收到ack后,就会开始下一轮的发送。
@H_673_94@问题来了:partition有多个副本,数据先写到leader,leader收到数据后还要再向各小弟follower同步数据,这样当自己挂的时候可以通过选主策略重新找到一个老大。
那么什么时候发送ack?要确保所有副本都同步到数据吗? 答:确保有 follower与leader同步完成,leade再发送ack,这样才能保证 leader挂掉之后,能在 follower中选举出新的leader。
多少个follower同步完成可以发ack?10个小弟的话要全部等同步完再发吗?会不会太慢了
答:现有方案:
a. 半数以上的 follower同步完成,即可发送ack
b. 全部的 Follower同步完成,才可以发送ack
@H_673_94@综上,ack的发送要等partition的的副本也收到后再发,那么leader与follower之间的副本数据同步就有了不同的方案。全同步和半同步。
同样为了容忍 n 台节点的故障,第一种方案需要 2n+1 个副本,而第二种方案只需要 n+1 个副本,而 Kafka 的每个分区都有大量的数据,@H_673_94@第一种方案会造成大量数据的冗余。
采用第二种方案全同步后的问题:
一个leader有10个小弟,但其中有一个小弟就是因为各种原因迟迟不能同步,那么leader就得一直等,
直到这个小弟同步完成才能发送ack。这个问题怎么解决?
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有10个小弟,他不是等所有小弟同步完消息,而是有一个叫ISR的集合,里面会加入一部分小弟,比如5个,他是等这个集合里的所有小弟同步完发ack。 后面如果leader出了事,选举新老大也是从这个集合里选。 这么一看,ISR妥妥的都是储备干部啊,那怎么才能加入这个集合呢?
原来的标准有2个,一个是小弟们保存的数据条数,看谁的offset最多,那如果出事选他们肯定相对丢的数据更少。另一个是小弟们的响应时间,响应时间超过某个阈值的就移除这个队伍。 最新的版本取消了条数的判断。因为这会导致很多follwer频繁的进出ISR,且涉及到zk的写数据。
上面讲leader要等ISR中的所有小弟都同步完才返回ack,但是吧,有些数据确实是不太重要,我们感觉这种数据丢了也没关系,好像也没必要等ISR中的所有小弟都接收完成。 基于这种情况,Kafka就给我们提供了可配置化的操作,提供了三种可靠性级别,让用户自己去权衡可靠性和延迟进行配置;
@H_673_94@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 发生故障,那么会造成数据重复。
@H_673_94@acks = 1 数据丢失案例
@H_673_94@acks = -1 数据重复案例
@H_673_94@参数大白话总结:
0就是producer直接不等ack; 1就是只要leader落盘成功就发ack; -1就是leader等所有小弟同步完再发ack。
1出问题的情况就是会数据丢失
-1出问题的情况(退化为配置1,也就是ISR中只剩leader):若ISR数量为3,一个leader2个follwer,结果两个follower太慢都被移出了ISR,导致里面只剩一个leader,那这种情况就退化成了参数为1的情况了。也就是只有leader收到了数据就立刻发送了ack。
-1的出问题另一种情况是重复数据问题:小弟都同步完成后,leader发ack之前挂了,然后producer又重发了,导致重复。
@H_673_94@有这样几个问题:
当leader挂掉以后,f1有10条,f2有9条,f3有8条,那么假设leader选的f3,因为f3最多到第8条,所以消费者拿第9个偏移量就拿不到了,这种情况怎么办? 答:引入高水位HW,只暴露高水位以前的偏移量
不同follwer的条数不一样,选f3以后,重发了9,但9同步到f1就变成了11,这不就重复了吗? 答:选举后阉割掉或截取掉所有高水位后面的偏移量。
那么这里引入了两个概念:HW高水位和Leo最后偏移量
大白话总结
HW是暴露给消费者的最大偏移量。因为HW是木桶里的短板。
@H_673_94@如下图
leader 故障 leader 发生故障之后,会从 ISR 中选出一个新的 leader,之后,为保证多个副本之间的数据一致性,其余的 follower 会先将各自的 log 文件高于 HW 的部分截掉,然后从新的 leader同步数据。
follower 故障 follower 发生故障后会被临时踢出 ISR,待该 follower 恢复后,@H_673_94@follower 会读取本地磁盘 记录的上次的 HW,并将 log 文件高于 HW 的部分截取掉,从 HW 开始向 leader 进行同步。 等该 follower 的 Leo 大于等于该 Partition 的 的 HW,即 follower 追上 leader 之后,就可以重新加入 ISR 了。
注意: 这只能保证副本之间的数据一致性,并不能保证数据不丢失或者不重复。
在 0.11 版本以前的 Kafka,对此是无能为力的,只能保证数据不丢失,再在下游消费者对数据做全局
去重。对于多个下游应用的情况,每个都需要单独做全局去重,这就对性能造成了很大影响。
0.11 版本的 Kafka,引入了一项重大特性:幂等性。所谓的幂等性就是指 Producer 不论向 Server 发送多少次重复数据,Server 端都只会持久化一条。幂等性结合 at least Once 语
义,就构成了 Kafka 的 Exactly Once 语义。
即:at least Once + 幂等性 = Exactly Once
at least Once + 幂等性 = Exactly Once
要启用幂等性,只需要将 Producer 的参数中 enable.idompotence 设置为 true 即可 !!
Kafka的幂等性实现其实就是将原来下游需要做的去重放在了数据上游。开启幂等性的 Producer 在
初始化的时候会被分配一个 PID,发往同一 Partition 的消息会附带 Sequence number。而
Broker 端会对<PID, Partition, Seqnumber>做缓存,当具有相同主键的消息提交时,Broker 只
会持久化一条。
但是 PID 重启就会变化,同时不同的 Partition 也具有不同主键,所以幂等性无法保证跨
分区跨会话的 Exactly Once。
同一次会话:session,也就是说producer启动起来后没有挂掉的情况下,然后同一分区内,都可以保证幂等性。
@H_673_94@精确一次语义的大白话总结
ack设置-1保证至少一次,这样起码不会丢,然后重复的问题靠幂等性来解决。而这里kafka的幂等性是选择的主键是三位一体的<生产者id,分区id,消息id>,这三个键来做主键。 不过Kafka挂了后分配的Pid会改变,所以不能保证跨session。不同分区主键不同,所以也不能跨分区。
以上是大佬教程为你收集整理的Kafka生产者全部内容,希望文章能够帮你解决Kafka生产者所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错,欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。