.net - 持久消息/服务总线 - 自己动手还是冒险学习曲线？

Question

我们有一个客户端应用程序需要将消息发送到服务器以获取各种通知。为了客户端可以偶尔连接运行，我将采用消息队列方法。队列处理将从队列中取出消息并调用 Web 服务，该服务将把它们放在另一个队列中以进行最终处理。这个问题是关于客户端环境的；服务器环境已经确定。

我不想使用 MSMQ，因为我们无法控制所有客户端 PC 以正确安装/配置和保护 MSMQ，而且由于用于调查 MSMQ 队列内容的工具的质量，支持更具挑战性. SQL Server 2005 Express 安装在所有机器上，用于为我们的应用程序存储数据。

我目前有两种选择:

编写一个相当基本的持久消息队列，将消息序列化后存储在表中，然后使用 ThreadPool.QueueUserWorkItem让它们由针对每种消息类型配置的处理程序进行处理。尽在 System.Transactions.TransactionScope因此，只有在成功处理它们后，它们才会从持久队列中删除。

在客户端上使用 NServiceBus(这是我们作为一个团队使用的服务总线，因此 MassTransit 等不是选项)，以及使用本地数据库的 Service Broker 传输。

我对服务总线的经验很少(我仍然没有真正获得服务总线术语)所以我担心学习曲线与编写更简单的东西相比，以满足我需要的方式(部署是一个 大 考虑)。

有人有想法吗？

Answer 1

好吧，我不知道我会推荐 MSMQ，但我会建议有很多边缘情况需要考虑“自己动手”。

即使使用线程池方法，请注意，如果您关心，可能会存在排序问题 - 由于线程池处理工作项的方式，顺序发布到线程池的两个项目可能不会按顺序执行。

您还需要考虑消息的持久性、它们应该存在多长时间、如何检测“致命”未传递状态以及在这种情况下该怎么做。

在您的应用程序在排队消息的同时停机的情况下，还有许多潜在的边缘情况 - 例如，它可能无法确认消息已排队，即使它已排队。是的，你可以 ack 队列确认，但你可以无休止地进入 ack 圈子......

为什么不让应用程序检测它何时连接，并在那时发送所有数据？