如何在 C# 中设计多实例应用程序？答案

【问题标题】：How to design a multiple instance application in C#?如何在 C# 中设计多实例应用程序？
【发布时间】：2012-11-12 19:14:16
【问题描述】：

任务：需要使用 c#.net 创建一个可以在多个实例上运行的控制台应用程序。（出于可扩展性目的）

现在，如果您创建一个简单的应用程序，这很容易。我现在的问题是在我的应用程序上我有一个全局变量。让您了解这个应用程序是什么。这是一个接收 JSON 消息的小程序（我使用 RabbitMQ 作为消息传递部分）。然后它将接收到的消息存储在全局变量中。现在，这使得在多个实例上运行应用程序变得困难。因为如果您运行超过 1 个应用程序实例，则可能会在另一个应用程序上收到消息。这是因为 RabbitMQ 的循环行为。（不能创建 Exchange 或路由密钥。）

我尝试过使用共享内存或 MemoryMappedFile，但这也不起作用。

我想到的另一件事是使用数据库。但我需要好的设计来做到这一点。如果有人知道一种模式、一个例子或任何参考资料。让我知道。

非常感谢您的回复。

【问题讨论】：

您能否提供更多有关您的意图的信息？您是否希望处理具有多个实例的消息？你想并行化一些东西吗？
嗨@Dusan，更像是在多个实例上处理消息。（在某种方式）。所以事情就是这样，我正在使用 RabbitMQ。我的应用程序正在从队列中使用。如果您运行应用程序的多个实例，这意味着您的队列中将有 2 个消费者。现在，当消息进入该队列时。它将转到您的第一个应用程序，当另一条消息进来时，它将转到第二个应用程序。（轮循时尚）。现在可能是您将在第二个应用程序上收到的消息是相同的消息，因此我需要一种方法来查找该消息是否已使用 ID 存在。
如果消费者以 RR 方式接收消息，那么第二个应用程序如何以与第一个应用程序相同的消息结束？我错过了什么吗？
很抱歉回复晚了。所以它是这样的，当消息到达应用程序时，它有一个唯一的 ID。这就是我与其他一些数据一起保存的内容。现在将出现另一条消息，该消息可能是相同的唯一 ID，但具有不同的状态。顺便说一句，谢谢您的回复。

标签： c# .net design-patterns rabbitmq

【解决方案1】：

我会使用MemoryMappedFiles，它们看起来是最简单的方法（忽略数据库）。我不知道为什么没有为你做这项工作？

应用程序的每个实例都会在此文件中“注册”自身并分配要写入数据的文件部分。收到消息后，检查文件中存储的其他实例的数据。

您可以将 Mutex 用于所有操作（实例寄存器、写入、读取） - 这将保证您拥有一致的数据图片。

【讨论】：

嗨，Dusan，我认为 MemoryMappedFiles 不适合我。即使我可以使我的第一次尝试工作，它仍然不会更可取。因为该应用的另一个实例可能在不同的机器上运行。
你好沉。在这种情况下，您将不得不使用某种共享资源。在我看来，数据库将是最轻松、最简单的方法，因为它们可以开箱即用地解决并发访问问题。
但是，如果您希望使用自定义解决方案，那么在某些情况下，您需要以适当的方式处理并发数据。我建议您以 Petreson 算法为起点 - 它可能会以一种简单易行的方式解决并发问题：en.wikipedia.org/wiki/Peterson%27s_algorithm

【解决方案2】：

如果内存映射文件真的不适合你，那么稍微改变一下架构怎么样。拥有主控制台应用程序（某种服务器），这可以根据需要生成其他控制台应用程序（某种客户端）。然后，他们可以使用Anonymous Pipes for Local Interprocess Communication（或任何其他进程间通信机制）与服务器检查消息是否已被处理，如果没有，则将其添加到列表中或其他任何内容。

【讨论】：

【解决方案3】：

你需要的架构是：

1 个控制器。这负责从队列中读取消息并分配它。

1+ 处理程序。控制器将根据您的负载实例化一个或多个处理程序。处理程序应该有一个明确的开始/结束。这意味着您执行一个，将消息传递进去，一旦该消息被正确处理，它就会完全退出。

或者，只是去购买 Biztalk 或类似的消息处理应用服务器。这就是这些东西的目的。

您真正关心的是可靠性；具体来说，知道一条消息实际上已被处理。因此，您将需要一种能够在硬件故障（例如数据库）中幸存下来的存储机制、控制器和处理程序（可以是任何东西）之间的通信机制以及假设长时间运行的进程的某种响应方式。可能是一个心跳片，以确保其中一个处理程序没有刚刚倒下。当然是一种重新处理消息的方法，也许是自动的，以防失败。最后，您需要一种限制处理程序的方法，以便您只能同时运行 X 个数，以防止系统不堪重负。

简而言之，这不是一个“简单”的应用程序，除非消息可以被删除、忽略或以其他方式不处理。

【讨论】：