在 IEventProcessor.ProcessEventsAsync 中重新传递未处理的 EventHub 消息答案

【问题标题】：Redeliver unprocessed EventHub messages in IEventProcessor.ProcessEventsAsync在 IEventProcessor.ProcessEventsAsync 中重新传递未处理的 EventHub 消息
【发布时间】：2016-04-07 12:14:57
【问题描述】：

在 IEventProcessor.ProcessEventsAsync 中，我想将事件存储在持久存储中。可能此存储不可用且消息无法持久化。如何签署这些消息以便稍后重新发送？

商店可能只关闭几个小时，但在它再次启动之前，每条消息都会受到影响并且无法持久化。

【问题讨论】：

您能否添加更多信息 - 底层持久存储的停机时间 - 5 分钟 - 1 小时 - 1 天需要多少容错？＆如果底层持久存储已关闭-您能否继续处理其余消息？因为，其他消息不会也遇到完全相同的问题，因为他们的商店已关闭 - 那么为什么要重新发送而不是等到底层商店可用？请。解释一下。
我不认为我可以使用 ProcessEventsAsync 中的某种重试策略停止处理消息并开始等待商店再次启动。租约可能同时到期。你的意思是调用 UnregisterEventProcessorAsync 然后等待一段时间？
这是一个实现细节——我能想到的一个解决方案是——你可以检查点相同的旧事件数据——这将保持租约而不是向前移动光标。
我的问题是您要解决的场景是什么 - a) 间歇性下游处理问题（或）b) 消息特定处理失败（毒消息）。如果它是下游处理 - 这对于所有消息都很常见 - 您需要停止处理，直到它备份。如果是有害消息 - 您需要推送到不同的 EventHub 以便稍后处理 - 或重新发送到当前的 EHub。
您的问题似乎正在解决 a) - 但您的解决方案是重新发送 - 而消息已经在您的记忆中。您需要做的就是 TryWriteToPerisistentStore - 如果失败 - 使用 OldCheckpointedEventData 伪造检查点

标签： azure-eventhub

【解决方案1】：

与 ServiceBus 队列不同，我认为您不能在 eventthub 中标记要传递的特定事件。但是，eventhub 确实为每个事件提供了保留策略和偏移量，这使得重新处理旧事件成为可能。您可以在本文档的“检查点”部分阅读更多内容：https://azure.microsoft.com/en-us/documentation/articles/event-hubs-overview/

【讨论】：

【解决方案2】：

除了 Tyler 的响应之外，我想您可以使用某种“毒药消息”/死信队列方法。事件中心没有该功能，但服务总线队列有。

无论如何，我认为它应该是一种程序化方法，而不是后端内部的东西。有一篇关于其他内容的好文章，但方法与我的意思相似： https://www.dougv.com/2015/07/handling-poison-messages-in-an-azure-service-bus-queue/

【讨论】：