代码之家 › 专栏 › 技术社区 › Neil Barnwell

消息队列和服务总线的消息粒度

servicebus message-queue c#

Neil Barnwell · 技术社区 · 15 年前

我正在开发一个应用程序,它可以在客户机的一个相当紧密的循环中生成数千条消息,并在服务器上进行处理。事件链是这样的:

客户机处理项目,放置在本地队列中。
本地队列处理接收消息并调用Web服务。
Web服务在服务器上的服务总线中创建消息。
服务总线将消息处理到数据库。

其思想是所有通信都是异步的,因为Web服务将有许多客户机。我知道msmq可以直接做到这一点,但我们并不总是在客户机上具有这种管理功能来设置安全性等。

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

有什么建议吗?

3 回复 | 直到 15 年前

Richard 15 年前

聊天界面(即大量和大量的消息)从将传入消息(以及在客户机上的回复)分派到正确的代码以处理消息(这将是每个消息的固定成本)会有很高的开销。而大消息倾向于在处理消息时使用资源。

此外,许多正在进行的Web服务调用意味着需要管理大量的TCP/IP连接,并发问题(包括锁定数据库)可能成为一个问题。

但是,如果没有消息处理的一些细节,很难具体说明,除了针对聊天界面的一般建议之外,因为有固定的开销。

Pontus Gagge 15 年前

先测量,后优化。除非你能做一个信封背面的估计,显示出最简单的解决方案会产生不可接受的高负载,否则试试看,建立良好的监控测量,看看它是如何执行的,以及它的规模。然后开始考虑批量生产的数量和地点。

当然,这种方法要求您能够在部署后更改Web服务接口,因此您需要 版本控制 处理可能尚未重新设计的客户机的方法,支持多个并行的WS版本。但不管怎样,不考虑版本控制几乎总是会把你困在次优的接口中。

Aiden Bell 15 年前

抽象消息队列

并具有可交换的消息队列后端。这样你就可以了测试如果你选错了一个,或者长得像一个新的出现的,很多人都会在后台给自己一个简单的纾困。消息传递的开销通常是打包和处理请求。随着时间的推移,不同的系统设计用于不同级别的流量和不同的对称性。

如果你抽象出基本的特性,你可以根据你的需求变化来交换这些特性,或者更准确地评估它们。

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

祝你好运