当使用libredkafka时，使用交易时交付回调的预期行为是什么？
我正在使用librdkafka在Kafka的上下文中对Kafka进行一些实验，这是一次交货功能。
librdkafka具有一个名为“交付回调”的功能，来自文档：
rdkafka :: producer :: producer :: produce（）（et.al）带有rdkafka :: message :: message :: erry，送货报告回调一次。 （）设置以指示农产品请求的结果。 当消息被成功地产生或librdkafka遇到永久故障或临时错误的重试计数器已经用尽时，调用了回调。 申请必须定期致电rdkafka :: poll（）以服务排队的送货报告回调。
kafka Transactions的文档指定：
kafka消费者只有实际承诺，kafka消费者只会向应用程序传递交易消息。换句话说，消费者将不会传递开放交易一部分的交易消息，也不会传递属于流产交易的消息。
我觉得对预期行为的预期行为有些歧义交付回调是在交易的上下文中使用的。尝试过后，我认为这两个功能彼此独立，并且彼此兼容。
如果在交易期间，农产品呼叫请求送货回调，则交货回调会进行，并且在交易完成之前可能会被打电话。
如果交易中断，即使已经有送货回调，读取_Comment的消费者也不会看到相关的消息。
我想检查这是否是对这些功能如何共同工作的正确理解？ 而且，是否推荐行为（如果允许绩效标准允许并进行了调查），请在进行交易之前等待交货回调吗？
I'm doing some experiments with Kafka using librdkafka in the context of the kafka exactly once delivery feature.
Librdkafka has a feature called delivery callbacks, from the documentation:
The delivery report callback will be called once for each message accepted by RdKafka::Producer::produce() (et.al) with RdKafka::Message::err() set to indicate the result of the produce request.
The callback is called when a message is succesfully produced or if librdkafka encountered a permanent failure, or the retry counter for temporary errors has been exhausted.
An application must call RdKafka::poll() at regular intervals to serve queued delivery report callbacks.
Documentation for Kafka transactions states:
The Kafka consumer will only deliver transactional messages to the application if the transaction was actually committed. Put another way, the consumer will not deliver transactional messages which are part of an open transaction, and nor will it deliver messages which are part of an aborted transaction.
I feel there is some ambiguity as to what the expected behaviour of delivery callbacks is if they are used within the context of a transaction. Having tried it out I think that the 2 features are both independent of each other and also compatible with each other.
If a delivery callback is requested by a produce call during a transaction the delivery callback proceeds and may get called before the transaction is completed.
If a transaction aborts, even though there has been a delivery callback a read_committed consumer will not see the related message.
I'd like to check if this is the correct understanding of how these features work together?
And also is it then recommended behaviour (if performance criteria allow and poll is called correctly) to wait for the delivery callback before committing the transaction?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，您的理解是正确的。
交付报告在生产者级别运行，如果经纪人确认了一条消息，则该消息被生产者认为是由生产者生产的，并且触发了交付报告 - 无论交易状态如何，因为该消息实际上已写入日志。
对于标准的非交易生产商，交付报告是必不可少的，因为它是应用程序知道其生成的消息是否是事实生成的唯一途径。
但是对于交易生产商而言，您实际上不需要使用交付报告，因为您可以简单地依靠成功的commit_transaction（）隐式地报告所有消息是成功的。
现在，即使对于交易案例，也可能会使用交货报告，因为它们在交货失败的情况下会提供更多细粒度的错误报告，但并非严格需要像标准生产者案例。
考虑到这一点，我通常会发现编写交易生产商应用程序比标准应用程序更容易，因为本质上只有单个失败点-Inter_transaction（）调用。
Yes, your understanding is correct.
The delivery reports operates at the producer level, if a message has been acknowledged by the broker it is deemed produced by the producer, and the delivery report is triggered - regardless of transaction state - since the message has in fact been written to the log.
For a standard non-transactional producer the delivery reports are essential since it is the only way for the application to know whether its produced messages were in-fact produced or not.
But for the transactional producer you don't really need to use delivery reports since you can simply rely on a successful commit_transaction() to implicitly report all messages as successful.
Now, even for the transactional case there might be some use of the delivery reports in that they give more fine-grained error reporting in case of delivery failure, but they're not strictly needed as in the standard producer case.
With this in mind I typically find it easier to write transactional producer applications than standard ones, since there's in essence only a single point of failure - the commit_transaction() call.