We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
流式消息投递,为了保证消息不丢,出现网络问题就需要重试。既然重试,就有重复投递消息的可能性,那么怎么做消息去重呢?
这被称为“恰好一次” (exactly-once messaging) 。要实现“恰好一次”语义分为两个部分:
消息生产期间获得“恰好一次”语义的 2 种方法:
按照以上任意一种方法,Kafka 托管的消息都将不重复。然而,要不重复消费,也需要消费者的一些配合。如果消费者周期性的检查其消费偏移量,当它失败重启后,会从最近一个检查的位置继续。因此,消费读取和偏移量检查点没有原子写入,也可能造成消息重复。这些问题也取决于你的存储系统。例如,如果你使用数据库,就可以把这些在一次事物中提交。LinkedIn 编写的 HDFS loader Camus 就为 Hadoop 负载做了这样的事。其他不需要事物的替代方案是使用 topic / partition / offset 的组合将偏移量与加载的数据存储并进行去重。
有两项改进可以使这更容易:
幂等生产者保证,如果生产者内部重试,单条消息最终不会重复。 事务生产者允许你原子地将多条消息写入多个 topic 的不同 partition 。 注意:你使用事物,也会自动获得幂等写入。
The text was updated successfully, but these errors were encountered:
经过我的实验,幂等生产者只是用于保证内部重试机制不产生重复的消息写入。
而我要处理的问题是,传递给生产者的消息可能是重复的。那么这种情况只有从消费端通过消息中的唯一字段做去重了。
Sorry, something went wrong.
No branches or pull requests
如何从 Kafka 恰好取得一次消息?
流式消息投递,为了保证消息不丢,出现网络问题就需要重试。既然重试,就有重复投递消息的可能性,那么怎么做消息去重呢?
这被称为“恰好一次” (exactly-once messaging) 。要实现“恰好一次”语义分为两个部分:
消息生产期间获得“恰好一次”语义的 2 种方法:
按照以上任意一种方法,Kafka 托管的消息都将不重复。然而,要不重复消费,也需要消费者的一些配合。如果消费者周期性的检查其消费偏移量,当它失败重启后,会从最近一个检查的位置继续。因此,消费读取和偏移量检查点没有原子写入,也可能造成消息重复。这些问题也取决于你的存储系统。例如,如果你使用数据库,就可以把这些在一次事物中提交。LinkedIn 编写的 HDFS loader Camus 就为 Hadoop 负载做了这样的事。其他不需要事物的替代方案是使用 topic / partition / offset 的组合将偏移量与加载的数据存储并进行去重。
有两项改进可以使这更容易:
幂等生产者(idempotent producer) 和 事务生产者 (transactional producer)的区别?
幂等生产者保证,如果生产者内部重试,单条消息最终不会重复。
事务生产者允许你原子地将多条消息写入多个 topic 的不同 partition 。
注意:你使用事物,也会自动获得幂等写入。
参考
The text was updated successfully, but these errors were encountered: