首先要考虑这么几个问题:
消息丢失是什么造成的?(从生产端和消费端两个角度来考虑) 消息重复是什么造成的?(从生产端和消费端两个角度来考虑) 如何保证消息有序? 如果保证消息不重不漏,损失的是什么? |
下面是文章详情,这里先简单总结一下:
消费端重复消费:很容易解决,建立去重表。 消费端丢失数据:也容易解决,关闭自动提交offset,处理完之后受到移位。 生产端重复发送:这个不重要,消费端消费之前从去重表中判重就可以。 生产端丢失数据:这个是最麻烦的情况。 |
kafka动态维护了一个同步状态的副本的集合(a set of In-Sync Replicas),简称ISR。 在这个集合中的节点都是和leader保持高度一致的,任何一条消息只有被这个集合中的每个节点读取并追加到日志中,才会向外部通知说“这个消息已经被提交”。 只有当消息被所有的副本加入到日志中时,才算是“committed”,只有committed的消息才会发送给consumer,这样就不用担心一旦leader down掉了消息会丢失。 消息从leader复制到follower, 我们可以通过决定producer是否等待消息被提交的通知(ack)来区分同步复制和异步复制。 同步发送: 发出消息后,必须阻塞等待收到通知后,才发送下一条消息。 特点:同步发送模式虽然吞吐量小,但是发一条收到确认后再发下一条,既能保证不丢失消息,又能保证顺序。 异步发送: 一直往缓冲区写,然后一把写到队列中去。 特点:异步的可能会丢失数据。 |
如何保证有序: 如果有一个发送失败了,后面的就不能继续发了,不然重发的那个肯定乱序了。 生产者在收到发送成功的反馈之前,不能发下一条数据,但我感觉生产者是一个流,阻塞生产者感觉业务上不可行,怎么会因为一条消息发出去没收到反馈,就阻塞生产者。 |
解决策略: 1.异步方式缓冲区满了,就阻塞在那,等着缓冲区可用,不能清空缓冲区。 2.发送消息之后回调函数,发送成功就发送下一条,发送失败就记在日志中,等着定时脚本来扫描。 注意:发送失败可能并不真的发送失败,只是没收到反馈,定时脚本可能会重发。 |
ack: ack确认机制设置为0,表示不等待响应,不等待borker的确认信息,最小延迟,producer无法知道消息是否发生成功,消息可能丢失,但具有最大吞吐量。 ack确认机制设置为-1,也就是让消息写入leader和所有的副本,ISR列表中的所有replica都返回确认消息。 ack确认机制设置为1,leader已经接收了数据的确认信息,replica异步拉取消息,比较折中。 ack确认机制设置为2,表示producer写partition leader和其他一个follower成功的时候,broker就返回成功,无论其他的partition follower是否写成功。 ack确认机制设置为 "all" 即所有副本都同步到数据时send方法才返回, 以此来完全判断数据是否发送成功, 理论上来讲数据不会丢失。 min.insync.replicas=1 意思是至少有1个replica返回成功,否则product异常 |
===================Kafka消息保证生产的信息不丢失和重复消费问题===================
Kafka到底会不会丢数据(data loss)?
通常不会,但有些情况下的确有可能会发生。
下面的参数配置及Best practice列表可以较好地保证数据的持久性(当然是trade-off 即权衡利弊,牺牲了吞吐量)。
笔者会在该列表之后对列表中的每一项进行讨论,有兴趣的同学可以看下后面的分析。
没有银弹(彻底消除软件危机,带来软件研发的变革的神奇武器)。
如果想要高吞吐量就要能容忍偶尔的失败(比如重发漏发无顺序保证)。
block.on.buffer.full = true acks = all retries = MAX_VALUE max.in.flight.requests.per.connection = 1 使用KafkaProducer.send(record, callback) callback逻辑中显式关闭producer:close(0) unclean.leader.election.enable=false replication.factor = 3 min.insync.replicas = 2 replication.factor > min.insync.replicas enable.auto.commit=false 消息处理完成之后再提交位移 |
产生数据丢失的两种情况: 1)同步模式:有3种状态保证消息被安全生产,但是在配置为1(只保证写入leader成功)的话,如果刚好leader partition挂了,数据就会丢失。 2)异步模式:当缓冲区满了,如果配置为0(还没有收到确认的情况下,缓冲池一满,就清空缓冲池里的消息),数据就会被立即丢弃掉。 |
在数据生产时避免数据丢失的方法: 1)同步模式:确认机制设置为-1,也就是让消息写入leader和所有的副本。 2)异步模式:如果消息发出去了,但还没有收到确认的时候,缓冲池满了,在配置文件中设置成不限制阻塞超时的时间,也就说让生产端一直阻塞,这样也能保证数据不会丢失。 在数据消费时,避免数据丢失的方法:如果使用了storm,要开启storm的ackfail机制。 如果没有使用storm,确认数据被完成处理之后,再更新offset值。低级API中需要手动控制offset值。 |
消息队列的问题都要从源头找问题,就是生产者是否有问题。 讨论一种情况: 如果数据发送成功,但是接受response的时候丢失了,机器重启之后就会重发。 重发 解决: 消费端增加去重表就能解决,但是如果生产者丢失了数据,问题就很麻烦了。
重复消费 解决: (1)去重:将消息的唯一标识保存到外部介质中,每次消费处理时判断是否处理过。 (2)不管:大数据场景中,报表系统或者日志信息丢失几条都无所谓,不会影响最终的统计分析结果。 |
给出列表之后,我们从两个方面来探讨一下数据为什么会丢失:
1. Producer端
问题1:丢失消息 目前比较新版本的Kafka正式替换了Scala版本的old producer,使用了由Java重写的producer。新版本的producer采用异步发送机制。 KafkaProducer.send(ProducerRecord)方法仅仅是把这条消息放入一个缓存中(即RecordAccumulator,本质上使用了队列来缓存记录),同时后台的IO线程会不断扫描该缓存区,将满足条件的消息封装到某个batch中然后发送出去。显然,这个过程中就有一个数据丢失的窗口:若IO线程发送之前client端挂掉了,累积在accumulator中的数据的确有可能会丢失。 问题2:消息乱序 假设客户端代码依次执行下面的语句将两条消息发到相同的分区 producer.send(record1); producer.send(record2); 如果此时由于某些原因(比如瞬时的网络抖动)导致record1没有成功发送。 同时Kafka又配置了重试机制和max.in.flight.requests.per.connection大于1(默认值是5,本来就是大于1的)。 那么重试record1成功后,record1在分区中就在record2之后,从而造成消息的乱序。 很多某些要求强顺序保证的场景是不允许出现这种情况的。 发送之后重发就会丢失顺序。 解决: 鉴于producer的这两个问题,我们应该如何规避呢?? 对于消息丢失的问题,很容易想到的一个方案就是: 既然异步发送有可能丢失数据, 我改成同步发送总可以。比如这样:producer.send(record).get(); 这样当然是可以的,但是性能会很差,不建议这样使用。 因此特意总结了一份配置列表: 个人认为该配置清单应该能够比较好地规避producer端数据丢失情况的发生。 特此说明一下:软件配置的很多决策都是trade-off(平衡,权衡,按实际情况权衡一下,得到最终决策)。 下面的配置也不例外: 应用了这些配置,你可能会发现你的producer/consumer 吞吐量会下降,这是正常的,因为你换取了更高的数据安全性。
block.on.buffer.full = true 尽管该参数在0.9.0.0已经被标记为“deprecated”(不赞成,反对的意思),但鉴于它的含义非常直观。 所以这里还是显式设置它为true,使得producer将一直等待缓冲区直至其变为可用。否则如果producer生产速度过快耗尽了缓冲区,producer将抛出异常。缓冲区满了就阻塞在那,不要抛异常,也不要丢失数据。 acks=all 很好理解,所有follower都响应了才认为消息提交成功,即"committed"。 retries = MAX 无限重试,直到你意识到出现了问题 max.in.flight.requests.per.connection = 1 限制客户端在单个连接上能够发送的未响应请求的个数。设置此值是1表示kafka broker在响应请求之前client不能再向同一个broker发送请求。注意:设置此参数是为了避免消息乱序 使用KafkaProducer.send(record, callback)而不是send(record)方法 自定义回调逻辑处理消息发送失败,比如记录在日志中,用定时脚本扫描重处理。 callback 逻辑中最好显式关闭producer:close(0) 注意:设置此参数是为了避免消息乱序(仅仅因为一条消息发送没收到反馈就关闭生产者,感觉代价很大)。 unclean.leader.election.enable=false 关闭unclean leader选举,即不允许非ISR中的副本被选举为leader,以避免数据丢失。 replication.factor >= 3 这个完全是个人建议了,参考了Hadoop及业界通用的三备份原则 min.insync.replicas > 1 消息至少要被写入到这么多副本才算成功,也是提升数据持久性的一个参数。与acks配合使用。 保证 replication.factor > min.insync.replicas 如果两者相等,当一个副本挂掉了分区也就没法正常工作了。 通常设置 replication.factor = min.insync.replicas + 1 即可。 |
|
2. Consumer端
consumer端丢失消息的情形比较简单: 如果在消息处理完成前就提交了offset,那么就有可能造成数据的丢失。 由于Kafka consumer默认是自动提交位移的,所以在后台提交位移前一定要保证消息被正常处理了,因此不建议采用很重的处理逻辑,如果处理耗时很长,则建议把逻辑放到另一个线程中去做。 为了避免数据丢失,现给出两点建议: enable.auto.commit=false 关闭自动提交位移,在消息被完整处理之后再手动提交位移。 |
-------------------------------------------------------------------------------------------------------------------------------------------------------
总结1:
消息的完整性和系统的吞吐量是互斥的,为了确保消息不丢失就必然会损失系统的吞吐量 producer: 1、ack设置-1 2、设置副本同步成功的最小同步个数为副本数-1 3、加大重试次数 4、同步发送 5、对于单条数据过大,要设置可接收的单条数据的大小 6、对于异步发送,通过回调函数来感知丢消息 7、配置不允许非ISR集合中的副本当leader 8、客户端缓冲区满了也可能会丢消息;或者异步情况下消息在客户端缓冲区还未发送,客户端就宕机 9、block.on.buffer.full = true consumer: 1、enable.auto.commit=false 关闭自动提交位移 同一分区消息乱序: 假设a,b两条消息,a先发送后由于发送失败重试,这时顺序就会在b的消息后面,可以设置max.in.flight.requests.per.connection=1来避免 max.in.flight.requests.per.connection:限制客户端在单个连接上能够发送的未响应请求的个数。设置此值是1表示kafka broker在响应请求之前client不能再向同一个broker发送请求,但吞吐量会下降 |
总结2:
生产者如何保证数据的不丢失 kafka的ack机制: 在kafka发送数据的时候,每次发送消息都会有一个确认反馈机制,确保消息正常的能够被收到。 同步模式: ack机制能够保证数据的不丢失,如果ack设置为0,风险很大,一般不建议设置为0 producer.type=sync request.required.acks=1 //只leader # 当所有的follower都同步消息成功后发送ack request.required.acks=-1 异步模式: 通过buffer来进行控制数据的发送,有两个值来进行控制,时间阈值与消息的数量阈值,如果buffer满了数据还没有发送出去,如果设置的是立即清理模式,风险很大,一定要设置为阻塞模式。 结论: 生产者如何保证数据的不丢失: producer有丢数据的可能,但是可以通过配置保证消息的不丢失。 producer.type=async 异步模式 request.required.acks=1 需要ack校验机制 queue.buffering.max.ms=5000 队列最大缓存时间大一些5秒 queue.buffering.max.messages=10000 队列最大缓存消息数量大些10000 queue.enqueue.timeout.ms = -1 进入队列超时时间设置为永不超时 batch.num.messages=200 每一批处理消息的数量设置小些200 消费者如何保证数据的不丢失 设置不自动提交,通过offset commit 来保证数据的不丢失,kafka自己记录了每次消费的offset数值,下次继续消费的时候,接着上次的offset进行消费即可。 集群监控工具 ganglia |