每秒处理40000条消息的系统的模式和技术

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

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

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

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

编辑:

在这种情况下,我无法充分强调负载测试的好处。做一个简单的原型和负载测试。优化原型,直到获得所需的结果。然后根据原型构建最终的解决方案。在您测试所需的性能级别之前,您需要对解决方案进行猜测。

4K*40.000/s=160MB/s是相当大的带宽。

您可能需要在两个方向都有带宽,因为无消息丢失要求意味着所有通信方都发送和接收两个方向。

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

您还需要对您的数据库操作和每个消息的计算进行基准测试,乘以40000(或一天35亿),以获得所需硬件的估计值。

我想.NET需求将是您遇到的最小问题。

我要做的第一件事就是努力找出你的需求到底是什么意思。”在任何软件或硬件故障的情况下都不能丢失任何信息”是不可能的。假设您将消息写入5000个不同位置的5000个不同磁盘。如果 全部的 在这些磁盘同时发生故障的情况下,您将不可避免地丢失数据。

同样地,如果你 做 在某个地方有一个bug,可能会丢失数据。能够设计一个解决方案的想法是不可能的,这个方案在系统中任何地方的bug面前总是有效的。

一旦你决定了你真正需要的冗余度和可靠性,帮助你就更可行了。你也会更容易有信心你已经达到了这样的可靠性水平。

如果您在Microsoft堆栈上,几乎肯定需要使用msmq(Microsoft消息队列)。它有许多选项可以配置为可靠性或性能。看看 MSMQ FAQ .

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

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

如果使用msmq并将消息标记为可恢复的,则要非常小心地可靠地将消息从队列中删除。使这个过程尽可能的安全,因为如果出了什么问题,消息可能堆积得太快,驱动器将在一秒钟内填满,并使系统崩溃。然后所有传入的消息都将丢失。问我怎么知道。(我没有创建它,我只是需要支持它。不好玩。

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

如上所述,磁盘和数据库将成为瓶颈。我认为msmq可以处理该卷,特别是在避免触发器等情况下。

IBM的MQ可能更适合该任务。

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