内容简介:在New Relic,我们使用Apache Kafka构建了管道的一些关键部分。多年来,我们遇到了我们遇到的一个基本问题涉及Kafka的消费者自动提交配置 - 特别是当消费者服务遇到让我解释一下这种行为及其对Kafka用户意味着什么。
在New Relic,我们使用Apache Kafka构建了管道的一些关键部分。多年来,我们遇到了 很多问题, 并设计了管理Kafka集群的 最佳实践 。我们已经从中学到了很多关于Kafka如何有效而不是那么有效地工作的知识。
我们遇到的一个基本问题涉及Kafka的消费者自动提交配置 - 特别是当消费者服务遇到 内存不足(OOM) 或其他类型的硬关机时,如何发生数据丢失或数据重复。
让我解释一下这种行为及其对Kafka用户意味着什么。
问题
生产者发送给Kafka分区的每条消息都有一个偏移量:用于标识每条消息的顺序索引号。要跟踪已处理的消息,您的消费者需要提交已处理消息的偏移量。
除非您手动触发提交,否则您最有可能使用Kafka使用者自动提交机制。自动提交是开箱即用的,默认情况下每五秒提交一次。
卡夫卡的消费者不知道你对这个消息做了什么,而且对于提交补偿更加冷漠。就消费者而言,只要收到消息,就会被“处理”。
所以现在想象一下,你的消费者已经吸收了1000条消息并将它们缓存到内存中。然后自动提交触发,提交这1,000条消息的偏移量。但是,假设您的服务现在使用了太多内存,并且在处理完所有消息之前会被OOM终止信号强行关闭。这样就永远不会处理剩余的可能是数百条消息,这就是数据丢失。
相反的情况也是可能的。您可以成功处理这1,000条消息,然后在提交偏移量之前发生问题如硬件故障等。在这种情况下,您将在 消费者重新平衡 后重新处理另一个实例上的数百条消息,这就是数据重复。
该怎么办呢?
坏消息是这里没有任何简单的修复。从根本上说,这是一致性保证较弱的问题。所有Kafka用户想要的只是 一次处理 - 保证您只需消费和处理一次消息。Kafka 0.11版试图解决这个问题,并使事情略微好转。 可以使用Kafka 0.11编写一次精确的管道 ,但要完全消耗一次,您需要在消费者中实现自己的事务语义,以便在完成处理时告诉Kafka(如果出现问题则回滚) 。
此外,在我们的测试中,我们发现Kafka 0.11中消息生成的事务模型没有像我们需要的那样快速处理消息,每条消息最多需要10-100毫秒。这是我们无法承受的额外延迟。
不过,你确实还有一些选择。只要您处于这些框架的限制范围内,几个流式解决方案(如 Flink 或 Kafka Streams )就可以提供一次性处理。
另一种选择是“滚动你自己的”一次性策略,它只会自动为已经到达处理管道末尾的消息提交偏移量。这只是对那些最勇敢的类型的建议,因为这样做很难,你可能会遇到比你解决的问题更多的问题。
并且始终可以选择接受数据丢失或重复的风险。可悲的是,这是许多Kafka用户选择的选项,但并不总是一个不合理的选择。您在其中一个场景中实际丢失或重复的数据量相对较小; 自动提交应该只比实际上次提交的消息少几秒。发生的频率也应该很低 - 理想情况下,您的Kafka消费者服务不会获得通常的OOM终止信号。
因此,与在您的所有Kafka消费者服务中解决此问题的工程成本相比,如果您使用的数据允许少量损失,这可能只是您所面临的风险。当然,您始终可以通过构建可靠的服务来降低风险。
向前进
正如我所说,我们在New Relic管理Kafka集群方面拥有丰富的经验。我们发现,随着我们扩展以处理大量数据量,构建高度可靠的服务变得更加困难,我们已经就如何处理Kafka中的这一特定缺陷做出了一些实际的决定,如果我们的某个服务经历过硬关机就执行这些决定。
如果您接受数据丢失的风险,请采取以下步骤将其最小化:
- 请注意此问题,并将其记录在风险矩阵中。
- 确保您的服务稳定。提醒您服务的 SIGKILL 和OOM。
- 在构建新服务时,请考虑使用直接解决此问题的流媒体系统。
以上所述就是小编给大家介绍的《Kafka消费者自动提交配置会导致潜在的重复或数据丢失!》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 免费开源软件的潜在安全风险
- 教你在Python中实现潜在语义分析
- MySQL--更新自增列的潜在风险
- Graudit 2.3 发布,代码潜在安全漏洞检查
- 邮件服务器安全性:潜在漏洞和保护方法
- Gmail也出漏洞,邮件潜在的安全风险不得不防
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。