我有一个服务代理应用程序，目前在两台服务器上有 5 或 6 个队列。
一般的工作流程是：
服务器 A
- 用户填充一些表
- 用户触发存储过程，将消息放入标头队列中，指示有工作要做
- Broker 从这个头队列中读取数据并创建大量消息发送到服务器 B
服务器 B
- 消息全部进入 1 个队列
- 在这个队列中，消息被检查和解绑，有效负载被运行，并且从我们与之交互的另一组过程/表中收集响应
- 创建响应消息并将其发送回服务器 A
服务器 A
- 响应消息进入一个特殊队列并用于更新用户在顶部填充的表
- 结束对话消息从发起者队列中读取，并用于更新另一个跟踪标头记录进度的表（即处理的 100 条消息中的 50 条）
- 当我们检测到标头记录已被完全处理时，一条新消息被发送到另一个发送通知电子邮件的队列
我建议在服务器 A 上整合其中一些队列，但我不确定最佳实践是什么。其中两个队列将具有相对较高的消息处理量，而电子邮件队列将非常慢。
我们（我认为）在管理消息类型方面做得很好，所以理论上我们可以将它们全部放入一个队列中，并且应用程序仍然可以运行。
在这种情况下何时维护单独的队列以及何时合并是否有最佳实践？
这是一个悬而未决的问题，没有明确的选择。YMMV 所以你必须测试。以下是我的看法：
如果您希望能够控制激活任务的数量，那么拥有一个队列来处理所有事情是一个不错的选择，因为没有全局 max_queue_readers。除此之外，我没有看到很多优点。有人可能会争辩说，单个激活的过程更易于维护，但我认为在创建 SSB 激活过程时应该使用某种模板/代码生成，因为通常大部分是千篇一律的代码，很少特定于服务业务逻辑。
但是，我可以看到单个队列的几个潜在问题，并且它们都是仅在事情已经变得糟糕（即在压力/负载下）时才会出现的问题：
一般来说，我的建议是为每个服务设置一个队列。