.net - 每秒能够处理 40,000 条消息的系统的模式和技术

Question

我们需要构建一个每秒能够处理 40,000 条消息的系统。在任何软件或硬件故障的情况下都不会丢失任何消息。

每条消息大小约为 2-4Kb。

消息的处理包括验证消息、进行一些简单的算术计算、将结果保存到数据库以及（有时）向其他系统发送通知。

优选的软件技术是.Net。

哪些软件和硬件模式最适合此类任务？

它需要多少硬件？

Answer 1

1. 消息队列。您的流程听起来像是它的主要目标。
2. 集群/负载平衡。
3. 简化您的代码

我要做的第一件事是排队通知。然后我将所有不需要返回值的数据库写入排队。然后我会考虑扩大规模。

其他注意事项： * 避免使用比您可能需要的幕后工作更多的大而笨重的框架。* 尽可能使用缓存和静态变量。

每秒 40,000 条消息是可行的，但是当您将 IO 添加到混合中时，即使在具有大量内存的超快速硬件上也可能无法预测。尽可能多地进行带外处理。如果失败，请查看您是否可以运行多个线程（在多核或多进程机器上）并在需要时查看集群中的多个服务器。

编辑：

在这样的场景中，我怎么强调负载测试的好处都不为过。做一个简单的原型和负载测试。完善原型，直到获得所需的结果。然后基于原型构建最终解决方案。在您测试所需的性能水平之前，您只能猜测解决方案。

Answer 2

4k * 40.000/s = 160MB/s 是相当多的带宽。

您可能需要在两个方向上都有该带宽，因为不丢失消息的要求意味着所有通信方都可以双向发送和接收。

将该数字除以网卡的平均吞吐量或硬盘的写入速度，可以发现这将是一个高度并行和冗余的系统。

您还需要对您的数据库操作和每条消息的计算进行基准测试，乘以 40.000（或一天 35 亿），以估算所需的硬件。

我想 .Net 要求将是您遇到的最少的问题。

Answer 3

我要做的第一件事是尝试找出您的要求的确切含义。“在任何软件或硬件故障的情况下不会丢失任何消息”是不可能的。假设您将消息写入 5000 个不同位置的 5000 个不同磁盘。如果所有这些磁盘同时发生故障，您将不可避免地丢失数据。

同样，如果您在某处确实存在错误，则可能会丢失数据。能够设计一个解决方案，在系统中的任何地方遇到错误时总是能正常工作的想法是不可能的。

一旦您确定了您真正需要的冗余和可靠性级别，帮助您将更加可行。您也更容易确信自己已经达到了该级别的可靠性。

Answer 4

如果您使用 Microsoft 堆栈，则几乎可以肯定需要使用 MSMQ（Microsoft 消息队列）。它有很多选项可以配置以提高可靠性或性能。查看MSMQ 常见问题解答。

瓶颈不是处理，而是磁盘 I/O。拥有大量 RAM 并尽可能多地在内存中执行操作。

MSMQ 在内存中管理其队列，但如果硬件出现故障，内存中的所有内容都会丢失。如果您将消息标记为可恢复，它们会被写入磁盘，但您很容易遇到瓶颈。

Answer 5

如果您使用 MSMQ 并将消息标记为可恢复，请非常小心可靠地将消息从队列中取出。尽可能使该过程具有故障安全性，因为如果出现问题，消息会堆积得如此之快，以至于驱动器将在几分之一秒内填满并导致系统崩溃。然后所有传入的消息都将丢失。问我怎么知道的。（不是我创造的，我只是支持它。不好玩。）

我从来没有弄清楚如何告诉 MSMQ 将消息持久保存到 C: 以外的驱动器，但这将是必要的。至少这样系统就能告诉你有问题。

如上所述，磁盘和数据库将成为瓶颈。我认为 MSMQ 可以处理该量，特别是如果您避免触发器等。

IBM 的 MQ 可能更适合这项任务。

Answer 6

我的建议是雇用已经建立了类似系统的人。让他们选择架构和开发工具。处理如此高的交易率将需要专业的硬件和软件知识，而获得此类知识的最便宜的方法是为此付费。