服务总线。当消息太多时？答案

【问题标题】：NServiceBus. When there are too many messages?服务总线。当消息太多时？
【发布时间】：2014-08-25 02:37:19
【问题描述】：

我们正在研究使用 NServiceBus 进行数据集成。我们收到带有数据的传入 xml 文件，需要将它们处理成几个子系统/数据库。我们最初的方法不是将数据放入消息体中，而是将其提取到数据库中，然后发送带有文件 ID 的消息。

现在我正在考虑发送消息正文中的每一行数据（将字段复制到消息属性）并独立处理每一行。

我对这种方法的担忧是，这种设计是否可以通过大量传入数据进行维护？假设每天有数百万条记录？生产这么多按摩是否有意义，或者最好将它们分成几批？将数据放入消息中是否有意义，还是使用 ID 更好？

【问题讨论】：

如果可能的话，我会说批处理而不是单个消息，但是您为什么要使用消息传递来同步数据？正在捕捉事件并做其他工作？通常数据库有一套数据同步工具。如果您沿着消息传递路线走，我会考虑该消息作为命令或事件的作用是什么？并根据该决策模型将在消息中包含什么内容。
NServiceBus 本身能够轻松地跟上每天数百万条消息。性能不应该是您最关心的问题。

标签： transactions integration nservicebus messaging

【解决方案1】：

我们的应用程序使用 NServiceBus 和 MSMQ，我们使用单个服务器和单个线程处理 50-10 万条消息。

我会使用两种类型的消息：

分解消息，它将读取主记录 ID 并将其分解为单个消息
Item Process 消息，我将使用至少 5 个线程并坚持插入数据库处理类型

随意创建某种服务，将初始数据保存到数据库中，并简单地将数据库中记录的 ID 作为消息类型 #1 传递，然后依次创建类型 2 的所有消息. 这样可以确保隔离和事务的使用。

你可以变得花哨并使用 Sagas，但你真的不需要

http://docs.particular.net/nservicebus/sagas-in-nservicebus

【讨论】：

【解决方案2】：

Евгений,

您会选择使用 DataBus 吗？您得到文件，实际上不需要分解它并将记录逐个发送到其他系统，因为听起来这些系统对整个文件感兴趣。此外，它将大大减少您必须发送/处理的消息数量。在此处查看文档，这可能是您要查找的内容。 http://docs.particular.net/nservicebus/attachments-databus-sample

肖恩

【讨论】：