我们需要构建一个每秒能够处理 40,000 条消息的系统。 在任何软件或硬件故障的情况下都不会丢失任何消息。
每条消息大小约为 2-4Kb。
消息的处理包括验证消息、进行一些简单的算术计算、将结果保存到数据库以及（有时）向其他系统发送通知。
首选的软件技术是 .Net。
哪些软件和硬件模式最适合此类任务？
需要多少硬件？
【问题讨论】：
标签： .net hardware design-patterns failover high-load
我要做的第一件事是将通知排队。然后我将所有不需要返回值的数据库写入排队。然后我会考虑向外扩展。
其他注意事项： * 避免使用一个笨重的框架，它在幕后做的工作比你可能需要的要多。 * 尽可能使用缓存和静态变量。
每秒 40,000 条消息是可行的，但是当您将 IO 添加到混合中时，即使在具有大量内存的超快速硬件上也可能无法预测。尽可能多地进行带外处理。如果失败，请查看您是否可以运行多个线程（在多核或多进程机器上）并在需要时查看集群中的多个服务器。
编辑：
在这种情况下，负载测试的好处再怎么强调也不为过。做一个简单的原型和负载测试。完善原型，直到获得所需的结果。然后基于原型构建最终解决方案。在您测试所需的性能水平之前，您只能猜测解决方案。
【讨论】：
4k * 40.000/s = 160MB/s 是相当大的带宽。
您可能需要双向带宽，因为不丢失消息的要求意味着所有通信方都可以双向发送和接收。
将该数字除以网卡的平均吞吐量或硬盘的写入速度，可以发现这将是一个高度并行和冗余的系统。
您还需要对您的数据库操作和每条消息的计算进行基准测试，乘以 40.000（或一天 35 亿），以估算所需的硬件。
我想 .Net 要求将是您遇到的最少的问题。
【讨论】：
我要做的第一件事是尝试找出您的要求的确切含义。 “在任何软件或硬件故障的情况下不会丢失任何消息”是不可能的。假设您将消息写入 5000 个不同位置的 5000 个不同磁盘。如果所有这些磁盘同时发生故障，您将不可避免地丢失数据。
同样，如果您确实在某处有错误，可能会丢失数据。能够设计一个解决方案，在系统中的任何地方出现错误时始终有效的想法是不可能的。
一旦您确定了您真正需要的冗余级别和可靠性，就可以为您提供帮助。您还可以更轻松地确信自己已达到该级别的可靠性。
【讨论】：
如果您使用 Microsoft 堆栈，则几乎可以肯定需要使用 MSMQ（Microsoft 消息队列）。它有很多选项可以配置以提高可靠性或性能。看看MSMQ FAQ。
瓶颈不是处理，而是磁盘 I/O。拥有大量 RAM 并尽可能多地在内存中执行操作。
MSMQ 在内存中管理其队列，但如果硬件出现故障，内存中的所有内容都会丢失。如果您将消息标记为可恢复，它们会被写入磁盘，但您很容易遇到瓶颈。
【讨论】：
如果您使用 MSMQ 并将消息标记为可恢复，请非常小心可靠地将消息从队列中取出。尽可能使该过程具有故障安全性，因为如果出现问题，消息会堆积得如此之快，以至于驱动器会在几分之一秒内填满并导致系统崩溃。然后所有传入的消息都将丢失。问我怎么知道的。 （不是我创造的，我只是支持它。不好玩。）
我从来没有弄清楚如何告诉 MSMQ 将消息持久保存到 C: 以外的驱动器，但这是必要的。至少这样系统才能告诉你有问题。
如上所述，磁盘和数据库将成为瓶颈。我认为 MSMQ 可以处理这个量，特别是如果你避免触发等。
IBM 的 MQ 可能更适合这项任务。
【讨论】：
我的建议是聘请已经构建了类似系统的人。让他们选择架构和开发工具。处理如此高的交易率需要专业的硬件和软件知识，而获取此类知识的最便宜的方法是花钱购买。
【讨论】：