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

Question

3

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

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

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

首选的软件技术是.Net。

哪种软件和硬件模式最适合这样的任务？

需要多少硬件支持？

- Konstantin Spirin

40,000条2-4kb的消息是稳定模式还是突发模式？ - Lasse V. Karlsen

每秒高峰可达40,000条消息，持续约30分钟。在此期间，消息数量会显著降低，但处理需实时完成。 - Konstantin Spirin

6个回答

3

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

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

将该数字除以您的网络卡的平均吞吐量或硬盘的写入速度，以找出这将成为高度并行和冗余系统。

您还需要对您的数据库操作和每个消息的计算进行基准测试，并乘以40.000（或35亿用于单日），以获得所需硬件的估计。

我猜.Net要求将是您最不用担心的问题。

- devio

2

我会尽力帮助您理解所需的内容。"在任何软件或硬件故障的情况下都不能丢失消息"是不可能的。假设您将消息写入5000个不同位置的5000个不同磁盘中。如果所有这些磁盘同时失效，数据将无法避免地丢失。

同样，如果系统中存在错误，可能会导致数据丢失。设计一个能够在系统中的任何地方都能正常工作的解决方案是不可能的。

一旦您确定了所需的冗余和可靠性级别，我们就可以更容易地帮助您。这也将更容易让您确信已达到所需的可靠性级别。

- Jon Skeet

2

如果您使用的是微软技术栈，几乎肯定需要使用MSMQ（Microsoft Message Queueing）。它有很多选项可供配置以提高可靠性或性能。请查看 MSMQ FAQ。

瓶颈不在处理上，而在于磁盘I/O。拥有大量RAM并尽可能多地使用内存。

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

- aleemb

2

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

我从来没有弄清楚如何告诉MSMQ将消息持久化到除C：之外的驱动器上，但那将是必要的。至少这样系统将能够告诉您存在问题。

正如上面提到的，磁盘和数据库将成为瓶颈。我认为MSMQ可以处理那种数量，特别是如果避免触发器等。

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

- R Ubben

1

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

- anon

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Chris · Accepted Answer

首先我会将通知排队。然后我会将所有不需要返回值的数据库写入排队。然后我会考虑扩展。

其他考虑因素： * 避免使用过于笨重的框架，这些框架在幕后执行的工作可能比你需要的要多得多。 * 在尽可能的情况下使用缓存和静态变量。

每秒40,000条消息是可以实现的，但当你将IO加入到混合中时，即使在具有大量内存的超级快速硬件上，也可能是不可预测的。尽可能多地进行带外处理。如果失败，请尝试在多核或多处理器机器上运行多个线程，并考虑在集群中运行多个服务器。

编辑：

我再次强调在这种情况下进行负载测试的好处。制作一个简单的原型并进行负载测试。改进原型，直到达到所需结果。然后根据原型设计最终解决方案。在测试所需的性能水平之前，你只是在猜测解决方案。