1

我正在开发一个应用程序，该应用程序可能会在客户端上以相当紧凑的循环生成数千条消息，并在服务器上进行处理。事件链类似于：

  1. 客户端处理项目，放置在本地队列中。
  2. 本地队列处理拾取消息并调用 Web 服务。
  3. Web 服务在服务器上的服务总线中创建消息。
  4. 服务总线将消息处理到数据库。

这个想法是所有通信都是异步的，因为 Web 服务将有许多客户端。我知道 MSMQ 可以直接执行此操作，但我们并不总是在客户端上拥有那种管理能力来设置安全等内容。

我的问题是关于每个阶段消息的粒度。最简单的方法意味着客户端上处理的每个项目都会生成一个客户端消息/Web 服务调用/服务总线消息。这很好，但我知道如果可能的话，最好对 Web 服务调用进行批处理，除非在大粒度 Web 服务 DTO 与数据库上的短期运行事务之间进行权衡。这个特定场景不需要“业务事务”，其中处理所有或不处理任何项目，我只是希望在消息大小与 Web 服务调用数量与数据库事务之间实现最佳平衡。

有什么建议吗？

4

3 回答 3

2

聊天界面（即大量消息）往往会在将传入消息（以及客户端上的回复）分派到正确的代码以处理消息（这将是每条消息的固定成本）方面产生高开销. 虽然大消息倾向于使用资源来处理消息。

此外，大量正在进行的 Web 服务调用将意味着需要管理大量 TCP/IP 连接，并发问题（包括锁定数据库）可能会成为问题。

但是，如果没有消息处理的一些细节，就很难具体说明，除了由于固定开销而针对聊天界面的一般建议。

于 2009-06-15T11:25:51.333 回答
2

先测量，后优化。除非您可以粗略估计，表明最简单的解决方案会产生不可接受的高负载，否则请尝试它，建立良好的监督测量，看看它如何执行和扩展。然后开始考虑要批处理多少以及在哪里。

当然，这种方法要求您能够在部署后更改 Web 服务接口，因此您需要一种版本控制方法来处理可能没有重新设计的客户端，同时支持多个 WS 版本。但无论如何，不​​考虑版本控制几乎总是会让您陷入次优界面。

于 2009-06-15T11:46:54.373 回答
2

抽象消息队列

并有一个可交换的消息队列后端。通过这种方式，您可以测试许多后端，并在您选择错误的后端或逐渐喜欢出现的新后端时给自己一个轻松的救助。消息传递的开销通常是打包和处理请求。随着时间的推移，不同的系统被设计用于不同级别的流量和不同的对称性。

如果您抽象出基本功能，您可以根据您的需求变化或更准确地评估这些机制。

您还可以在应用程序或消息路由的不同部分转换来自不同队列类型的消息，因为接收者的压力会发生变化，因为他们正在处理，例如 1000:1/s 与更高级别的 10:1/s。

祝你好运

于 2009-06-15T11:56:25.783 回答