Kafka到底会不会丢数据
来源:互联网 发布:董伟淘宝店 编辑:程序博客网 时间:2024/06/04 19:54
转自:http://www.cnblogs.com/huxi2b/p/6056364.html
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. Producer端
目前比较新版本的Kafka正式替换了Scala版本的old producer,使用了由Java重写的producer。新版本的producer采用异步发送机制。KafkaProducer.send(ProducerRecord)方法仅仅是把这条消息放入一个缓存中(即RecordAccumulator,本质上使用了队列来缓存记录),同时后台的IO线程会不断扫描该缓存区,将满足条件的消息封装到某个batch中然后发送出去。显然,这个过程中就有一个数据丢失的窗口:若IO线程发送之前client端挂掉了,累积在accumulator中的数据的确有可能会丢失。
Producer的另一个问题是消息的乱序问题。假设客户端代码依次执行下面的语句将两条消息发到相同的分区
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 关闭自动提交位移
- 在消息被完整处理之后再手动提交位移
- Kafka到底会不会丢数据
- kafka connect到底会不会重写/丢失数据
- iOS面试题之加载单张图片到底会不会崩溃?
- 狼来了:AI到底会不会抢走我们的工作?
- kafka丢数据和数据重复
- kafka丢数据、重复数据分析
- sqlserver 存储过程中使用临时表到底会不会导致重编译
- flume 读取kafka 数据
- kafka迁移数据目录
- kafka 数据删除策略
- 大数据Kafka
- kafka数据导入hbase
- storm消费kafka数据
- Kafka之数据存储
- Kafka---数据持久化
- kafka清理数据
- Gobblin采集kafka数据
- kafka清理过期数据
- HashTable哈希表改进
- 小白学分布式程序开发9-三阶段提交
- phpredis connect 与 pconnect
- 并查集 判环
- 如何在你的应用中调用其它已知包名的应用?
- Kafka到底会不会丢数据
- 整合53种纯CSS3炫酷loading指示器动画特效
- 【C#】byte[]数组中有值大于127时与string之间的相互转化
- 8.3 F
- C语言(12)蛋蛋的问题(一)
- [Zabbix] IPMI 监控
- sort的基本用法
- 特殊回文数 --枚举
- 接上一篇6代cpu装win7