本文将从消息的生产端和消息的消费端分析,数据是如何丢失的?数据是如何出现重复消费的,如何解决上述这种情况?
利用 Kafka 高吞吐、可分区、可复制的特性, 在实时数据流分析应用领域,Kafka 在此大展身手。
1/ 生产端 Producer
消息格式:每个消息是一个 ProducerRecord 对象,必须指定消息所属的 Topic 和消息值 Value ,此外还可以指定消息所属的 Partition 以及消息的 Key。Producer 生产数据默认是先写到内存(PageCache)中的,定期 flush 到磁盘上。默认的这个参数是:
![19859e026849b25376e1002861da5f7d.png](https://i-blog.csdnimg.cn/blog_migrate/68875e78a22bb223bac3ac1fd8145950.jpeg)
设置较小定期 flush 的时间,并不能真正保证数据不会丢失。通过查看官方提供的默认配置 Long.MaxValue 也可以看出,官方是不建议我们通过这个参数来改变什么的,也就是说设置 flush 的时间,不能从根本上保证我们的数据丢失问题。
前面一开始提到,kafka 作为一个可分区和可复制的消息队列。我们可以利用它的分区副本机制,为每一个 Topic 的数据分为多个分区,每个分区放在不同的节点上,每个分区默认只有一分数据,通过设置参数 --replication-factor 2 ,可以执行每个分区有三份数据,其中有两份是用来备份的。
分区有副本了,也会存在 leader 和 follower 的角色,zookeeper 中维护了一个 ISR 列表。
这时,生产者往 broker 中写入数据的时候,默认的消息确认级别是 request.required.acks = 0, 表示生产者发送消息之后,不会等待 leader的确认。
![b5d111c7252f54568106716e90a18aaf.png](https://i-blog.csdnimg.cn/blog_migrate/3e743f5da4c675616f71b41999acd2a6.jpeg)
所以,需要把这个设置为 -1 ,表示生产者发送消息要等到 leader 以及所有的副本都同步了,才会返回确认消息。当然,这种方案也不是非常万无一失的,官方提出的建议是,还需要配置 min.insync.replicas 最小同步的副本数,如果没有得到这个最小数的要求,生产者会抛出异常,本次写入不会成功。比如,我有三个副本,那么最好找个参数要设置成 2 ,要保证大部分的副本同步了数据。
官方原文:
![c228f5e98157a554139e828f28f7f19c.png](https://i-blog.csdnimg.cn/blog_migrate/b38523ee6dbe1e561f9521a6c7920d11.jpeg)
总结:request.required.acks = -1 虽然保证了数据的一致性,但是同时也影响了性能。在实际业务中应该考虑数据少量丢失对于业务的影响,要根据自己的情况来,结合业务来平衡数据一致性和系统的性能。
有兴趣的读者可以去研究一下 CAP, 分布式系统的三个指标,推荐阮一峰老师写的 -- CAP 定义的原理。
2/ 消费端 Consumer
消费端数据丢失的原因是 offset 的自动提交。
![67e9bc68d13b82b94fd67f0e762dcc86.png](https://i-blog.csdnimg.cn/blog_migrate/fb4274906499ebf87874f5087eabba07.jpeg)
由于在使用kafka的高级API时,消费者会自动每隔一段时间将offset保存到zookeeper上,此时如果刚好将偏移量提交到zookeeper上后,但这条数据还没消费完,机器发生宕机,此时数据就丢失了。
解决方法:关闭自动提交,改成手动提交,每次数据处理完后,再提交。
数据重复消费,在消费者自动提交offset到zookeeper后,程序又消费了几条数据,但是还没有到下次自动提交offset到zookeeper之时,如果机器宕机了,然后重启,此时消费者会去读zookeeper上的偏移量进行消费,这就会导致数据重复消费。 解决方法:关闭自动提交,改成手动提交。
这里再提一下 kafka 的两种方式API,以供大家选择合适的。
高级 API 的特点
优点
● 高级API写起来简单
● 不需要去自行去管理offset,系统通过zookeeper自行管理
● 不需要管理分区,副本等情况,系统自动管理
● 消费者断线会自动根据上一次记录在 zookeeper中的offset去接着获取数据
缺点
● 不能自行控制 offset(对于某些特殊需求来说)
● 不能细化控制如分区、副本、zk 等
低级 API 的特点
优点
● 能够开发者自己控制offset,想从哪里读取就从哪里读取。
● 自行控制连接分区,对分区自定义进行负载均衡
● 对 zookeeper 的依赖性降低(如:offset 不一定非要靠 zk 存储,自行存储offset 即可,比如存在文件或者内存中)
缺点
● 太过复杂,需要自行控制 offset,连接哪个分区,找到分区 leader 等
本文就到这里,实际生产中需要结合自己的业务去选择。
推荐阅读
Kafka 遇上 Spark Streamingmp.weixin.qq.com![v2-2d9ceed78978badf52f685b50ced44c6_ipico.jpg](http://img-01.proxy.5ce.com/view/image?&type=2&guid=6cfa6420-5931-eb11-8da9-e4434bdf6706&url=https://pic3.zhimg.com/v2-2d9ceed78978badf52f685b50ced44c6_ipico.jpg)
![v2-2d9ceed78978badf52f685b50ced44c6_ipico.jpg](http://img-01.proxy.5ce.com/view/image?&type=2&guid=6cfa6420-5931-eb11-8da9-e4434bdf6706&url=https://pic3.zhimg.com/v2-2d9ceed78978badf52f685b50ced44c6_ipico.jpg)
![v2-2d9ceed78978badf52f685b50ced44c6_ipico.jpg](http://img-01.proxy.5ce.com/view/image?&type=2&guid=6cfa6420-5931-eb11-8da9-e4434bdf6706&url=https://pic3.zhimg.com/v2-2d9ceed78978badf52f685b50ced44c6_ipico.jpg)
![c69e762599ae77ae2f8c308aede31dfc.png](https://i-blog.csdnimg.cn/blog_migrate/9c61a8c67d0bc9057362f594b87eb4d0.jpeg)