{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','https://www.manongdao.com/data/attach/logo/logo.png', '推荐 何必那么认真 的问题《Does Azure Event Hub guarantees at least once deli》','https://www.manongdao.com/q-1267579.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
I'm building an azure web application, I'd like to send the activity logs to Azure Event Hub. What happen if the connection between the application host and the event hub is lost? Does the Event Hub client implement some kind of local queue?
标签：
azure-eventhub
相关问题
- All instances are not running in Azure App Service
- Microsoft Azure Service Bus/Event Hub: No messages
- Event Hub input binding for Azure Functions
- Azure eventhub multiple partition key points to sa
- Azure Event Hub timeouts
相关文章
- Route events to eventhub EventProcessor
- Why not always configure for max number of event h
- Should the event hub have same number of partition
- Does Azure Event Hub guarantees at least once deli
- How can the serialized size of EventData be determ
- Azure IoT Hub, EventHub and Functions
- Azure DocumentDB Read Document Resource Not Found
- Azure的功能 - 事件集线器没有触发功能(Azure Functions - Event Hub
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
These were documented on the official microsoft page. You can find the official details here : https://docs.microsoft.com/en-us/azure/event-grid/compare-messaging-services