我相信您正在从错误的一端接近解决方案。您绝对可以使用 ServiceStack 进行 Web Hook 调用 - 最好使用 JSON。
您真正应该研究的是消息队列,因为它们展示了实现 Web Hook 调用所需的所有特性(持久性、消息清除策略、消息过滤、传递策略、路由策略、排队标准)
在 Wikipedia 上阅读有关消息队列属性的更多信息
事件将跟进到调用 Web Hook 的工作流:
- 系统发生事件;为确保调用 Web Hook,您必须持久地将事件排入队列以进行处理(通过 RabbitMq、MassTransit、NServiceBus 等服务总线)。让我们调用目标队列EventsQueue
- 然后应用程序将连接到EventsQueue并通过以下方式处理消息:
- 找出谁订阅了这个特定的事件
- 对于每个订阅者,将包含事件数据副本和订阅者详细信息(例如回调 URL)的新消息排队到具有初始生存时间(消息的有效时间)的WebHookQueue
- 然后应用程序将连接到WebHookQueue并通过回调来处理消息。
所以现在你有了一个基本的通知系统,它应该确保消息至少被传递一次。
这是一篇很棒的文章,详细介绍了如何使用 TTL(生存时间)间隔重试消息
我会采取一些不同的方法:
- 创建不同的重试级别队列(例如WebHookRetryQueue = WebHookQueue的死信队列,WebHookRetryLvl1Queue = TTL 5 分钟,WebHookRetryLvl2Queue = TTL 15 分钟)。诀窍是将这些重试级别队列的死信队列设置为WebHookQueue并使排队的消息过期(这意味着一旦消息在重试级别队列中到期,它就会重新排队进入WebHookQueue)。
- 然后,您需要跟踪WebHookRetryQueue中消息的当前重试级别,然后将消息排入适当的重试级别队列 - 此后 TTL 到期后,将重新插入WebHookQueue。
示例工作流:最大重试次数的WebHookQueue:2,TTL:1 天
示例消息:{'event_type': 'Email_Reply', 'callback_url': '...', 'reply_level': 0, 'queued_at': '2013-09-25T22:00:00Z', data: 'json 编码' }
Message -> WebHookQueue (fail) -> WebHookQueue (fail) -> WebHookRetryQueue (incr.reply_level=1 + enqueue) -> WebHookRetryLvl1Queue (5 mins-expire) -> WebHookQueue (fail) -> WebHookQueue (fail) -> WebHookRetryQueue ( incr.reply_level=2 + enqueue) -> WebHookRetryLvl2Queue (15 mins-expire) -> WebHookQueue (fail) -> WebHookQueue (fail) -> WebHookRetryQueue (drop message)
编辑
单击此处查看使用WebHookQueue和使用 RabbitMQ 的消息级别 TTL 的WebHookRetryQueue的简单示例。由于消息级别的 TTL;没有必要创建不同的重试级别队列——这对于功能较少的消息队列可能是必需的。
如果您必须实现这样一个能够使单个消息过期(而不是通过清除策略)或使用重新安排/过期选项提前安排消息的队列 - 您很可能不得不选择基于数据库的队列。
这是关于 CodeProject 的一篇很棒的文章,关于为 MSSQL Server 构建如此高性能的队列(努力移植到其他数据库,如 MySql/Postgresql/Mongodb/Couchbase 等)
希望您发现此信息有用。