Does Azure Event Hub guarantees at least once delivery?

烂漫一生 提交于 2019-12-02 10:38:57

TLDR: Yes. EventHubs Offers atleast-once delivery. No queue is maintained by EventHub client SDK. It will throw and the dependent App will need to retry the Send.

EventHubs service guarantees atleast-once delivery. The send call will succeed only when client receives 'acknowledgement" from the EventHubs Service. EventHubs service will not wait for the client's 'acknowledgement' for the 'acknowledgement' it has sent. In simple words - it doesn't offer Only-Once/Exactly-once semantics.

Implementor perspective:

If you are familier with the Client SDK, EventHubs Service, do not even, have a way to Know that A message is being sent/delivered twice – because, there is no way currently built into it – to identify A message (for ex: there is nothing like a MessageID in EventData). So, the only guarantee that EventHubs Service can offer is – whatever data is sent to eventHub service – it will acknowledge back to the Client – only-and-only after persisting the message to a persistent store. That’s why, it’s called at least once. Same applies to receive. If a receiver client crashes, after recovering - come back with the offset that you last remember – EventHubs service will guarantee that it will replay the stream from that exact point.

The trade-off call: To offer any other semantics like ‘at-most-once’ or ‘exactly-once’ – message-level infrastructure (an identifier per-message and the Compute per-message to de-duplicate the Events) - will be needed. So, this nice to have feature at the Service level - will come with extra performance overhead.

As the purview of Event Hubs is to offer Stream-semantics and these are really at per-Message semantics – Event Hubs Service chose to push this to Client libraries. Clients libraries will need to build it – taking dependency on - the Exactly-once semantics that we offer.

HTH! Sree

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!