multithreading - 如何设计处理到达队列的消息的服务

Question

我有一个处理来自多个客户端的消息的多线程 Windows 服务的设计问题。
规则是

每条消息都要为一个实体处理一些事情(具有唯一的 id)并且可以不同，即 DoA、DoB、DoC 等。实体 id 位于消息的有效负载中。

处理可能需要一些时间(最多几秒钟)。

对于每个实体(具有相同的 id)，消息必须按照它们到达的顺序进行处理。

但是，可以同时为另一个实体处理消息(即，只要它们不是相同的实体 ID)

并发处理数可配置(一般为8)

消息不能丢失。如果在处理消息时出现错误，则必须存储该消息和同一实体的所有其他消息，以供将来手动处理。

消息到达事务性 MSMQ 队列。

你会如何设计服务。我有一个可行的解决方案，但想知道其他人将如何解决这个问题。

Answer 1

您要做的第一件事是退后一步，考虑一下该应用程序的性能有多重要。你真的需要同时处理消息吗？它是关键任务吗？或者你只是认为你需要它？您是否在您的服务上运行分析器以找到过程的真正瓶颈并对其进行优化？

我问的原因是因为你提到你想要 8 个并发过程 - 但是，如果你使这个应用程序单线程，它会 大大减少复杂性、开发和测试时间……而且由于您只想要 8 个，因此几乎不值得……

其次，由于您只能处理同一实体上的并发消息 - 您真正从客户端收到并发请求以处理同一个实体的频率 ?是否值得为可能不经常出现的用例添加这么多层复杂性？

我会亲吻。我会通过 WCF 使用 MSMQ，并将我的 WCF 服务保持为单例。现在您拥有了 MSMQ 的强大、有序的可靠性，并且您现在正在满足您的实际需求。然后我会用真实数据在高负载下测试它，如果我发现它太慢，我会运行一个分析器来找到瓶颈。只有这样，我才会经历构建一个更复杂的应用程序来管理特定用例的并发性的所有额外麻烦......

要考虑的一种设计是创建一个中央“看门人”或“服务总线”服务，它接收来自客户端的所有消息，然后将这些消息传递给实际的工作服务。当他收到一个请求时，他会发现他的另一个客户是否已经在处理同一实体的消息——如果是这样，他会将其发送到他将另一条消息发送到的同一服务。通过这种方式，您可以同时处理给定实体的相同消息，仅此而已……而且您可以轻松实现无缝可扩展性……但是，只有在绝对必要的情况下，我才会这样做，并且通过分析和测试证明了这一点，而不是因为“我们认为我们需要它”(参见 YAGNI 校长 :))