码迷,mamicode.com
首页 > 其他好文 > 详细

2.kafka架构深入——生产者

时间:2019-12-06 00:31:27      阅读:192      评论:0      收藏:0      [点我收藏+]

标签:通过   top   ade   总数   没有   容错   绑定   不重复   大量   

一个topic有多个partition,每个partition又有多个副本,在这些副本中又有一个leader和多个follower。

1)分区的原因

(1)方便在集群中扩展,每个Partition可以通过调整以适应它所在的机器,而一个topic又可以有多个Partition组成,因此整个集群就可以适应任意大小的数据了;
(2)可以提高并发,因为可以以Partition为单位读写了。

2)分区的原则
我们需要将producer发送的数据封装成一个ProducerRecord对象。

(1)指明 partition 的情况下,直接将指明的值直接作为 partiton 值;
(2)没有指明 partition 值但有 key 的情况下,将 key 的 hash 值与 topic 的 partition 数进行取余得到 partition 值;
(3)既没有 partition 值又没有 key 值的情况下,第一次调用时随机生成一个整数(后面每次调用在这个整数上自增),将这个值与 topic 可用的 partition 总数取余得到 partition 值,也就是常说的 round-robin 算法。

生产者发送到topic的数据可靠性保证

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

设想这样一种场景:
Producer向partition中的leader发送消息,在leader收到消息后,向Producer发送ack表示已经收到消息。然后leader开始准备向同一个partition中的其他的follower同步消息,假如这个时候leader突然挂掉,那么集群中开始选举其他的follower成为leader,其他的follower成为leader之后,内部并没有刚刚发来的那条消息,而producer已经收到了之前leader发来的ack,也不会发送这条消息了,这就造成了消息漏消费的情况,那如何解决这个问题呢?很简单,等leader给follower同步消息之后再给Producer发送ack确认通知就可以了,那么就产生一个问题:同步到什么地步或者说同步几台follower之后发送ack?

多少个folower同步完成之后发送ask?有两个方案:


第一个方案:半数以上的follower同步完成,即可发送ack

第二个方案:不用选举,全部的follower同步完成,才可以发送ack

1、为什么要获取半数以上的投票才能成为新的leader?
防止脑裂。半数以上的话只能有一个

2、参与投票的至少几个?
半数以上

3、如何才能确保一定能够选出一个合格的leader
半数以上的同步完成。
9个副本,有5个同步完成的,如果挂掉4个节点,根据2中可知:参与投票的至少是5个,里面至少会有一个同步完成的,(选举的规则是选举同步完成的),那肯定可以保证选举成功。

所以说第一个方案:半数以上的follower同步完成,即可发送ack


第一种方案:优点:延迟低
缺点:选举新的leader时,容忍n台节点的故障,需要2n+1个副本。(如果集群有2n+1台机器,选举leader的时候至少需要半数以上即n+1台机器投票,那么能容忍的故障,最多就是n台机器发生故障)容错率:1/2

第二种方案:优点:选举新的leader时,容忍n台节点的故障,需要n+1个副本。(如果集群有n+1台机器,选举leader的时候只要有一个副本就可以了)容错率:1
缺点:延迟高

Kafka选择了第二种方案,原因如下:

1.同样为了容忍n台节点的故障,第一种方案需要2n+1个副本,而第二种方案只需要n+1个副本,而Kafka的每个分区都有大量的数据,第一种方案会造成大量数据的冗余。
2.虽然第二种方案的网络延迟会比较高,但网络延迟对Kafka的影响较小。

2)ISR

采用第二种方案之后,设想以下情景:leader收到数据,所有follower都开始同步数据,但有一个follower,因为某种故障,迟迟不能与leader进行同步,那leader就要一直等下去,直到它完成同步,才能发送ack。这个问题怎么解决呢?

Leader维护了一个动态的in-sync replica set (ISR),意为和leader保持同步的follower集合。当ISR中的follower完成数据的同步之后,leader就会给producer发送ack。如果follower长时间未向leader同步数据,则该follower将被踢出ISR,该时间阈值由replica.lag.time.max.ms参数设定。Leader发生故障之后,就会从ISR中选举新的leader。

3)ack应答机制


对于某些不太重要的数据,对数据的可靠性要求不是很高,能够容忍数据的少量丢失,所以没必要等ISR中的follower全部接收成功。
所以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和ISR中的follower全部落盘成功后才返回ack。但是如果在follower同步完成后,broker发送ack之前,leader发生故障,那么会造成数据重复

4)故障处理细节

Log文件中的HW和LEO
LEO:(Log End Offset)每个副本的最后一个offset
HW:(High Watermark)所有副本中最小的LEO

技术图片

(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同步数据。

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

生产者幂等性

将服务器的ACK级别设置为-1,可以保证Producer到Server之间不会丢失数据,即At Least Once语义。相对的,将服务器ACK级别设置为0,可以保证生产者每条消息只会被发送一次,即At Most Once语义。
At Least Once可以保证数据不丢失,但是不能保证数据不重复;相对的,At Most Once可以保证数据不重复,但是不能保证数据不丢失。但是,对于一些非常重要的信息,比如说交易数据,下游数据消费者要求数据既不重复也不丢失,即Exactly Once语义。在0.11版本以前的Kafka,对此是无能为力的,只能保证数据不丢失,再在下游消费者对数据做全局去重。对于多个下游应用的情况,每个都需要单独做全局去重,这就对性能造成了很大影响。

0.11版本的Kafka,引入了一项重大特性:幂等性。所谓的幂等性就是指Producer不论向Server发送多少次重复数据,Server端都只会持久化一条。幂等性结合At Least Once语义,就构成了Kafka的Exactly Once语义。即:
At Least Once + 幂等性 = Exactly Once
要启用幂等性,只需要将Producer的参数中enable.idompotence设置为true即可(kafka自动将acks属性设为-1,并将retries属性设为Integer.MAX_VALUE。)。Kafka的幂等性实现其实就是将原来下游需要做的去重放在了数据上游。开启幂等性的Producer在初始化的时候会被分配一个PID,发往同一Partition的消息会附带Sequence Number。而Broker端会对<PID, Partition, SeqNumber>做缓存,当具有相同主键的消息提交时,Broker只会持久化一条。
Producer重启,PID就会变化,所以幂等性只能保证单会话的Exactly Once。

Kafka生产者事务

Kafka从0.11版本开始引入了生产者事务,事务可以实现生产者向不同分区、不同topic发送的多条消息的原子性。
为了实现跨分区跨会话的事务,需要引入一个全局唯一的Transaction ID,并将Producer获得的PID和Transaction ID绑定。这样当Producer重启后就可以通过正在进行的Transaction ID获得原来的PID,开启事务后,生产者能够实现跨会话的幂等性。

2.kafka架构深入——生产者

标签:通过   top   ade   总数   没有   容错   绑定   不重复   大量   

原文地址:https://www.cnblogs.com/zhqin/p/11992707.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!