小编ara*_*ao6的帖子

我们正在考虑使用 RabbitMQ 每分钟排队数千个任务，然后从 300 多个虚拟机处理它们。我们有一个智能调度 Web API，可以根据业务需求智能地（公平地）将 100 多个队列中的任务分配到 VM。我们知道 RabbitMQ 绝对有能力处理这种负载。目前，我们每次都跨多个表查询数据库，这占 SQL Server 负载的 30-40%。相反，我们正在考虑设置一个触发器，然后在数据进入时将数据推送到 RabbitMQ（通过中间交换 API）。我意识到 SQL Service Broker 与 RabbitMQ 相比也是一个潜在的队列选择，所以我有关于 SQL Service Broker（SQL Server 2016 及更高版本）的几个问题，希望您能回答：

• 能否将队列数据持久化存储，然后根据业务需求从特定队列中获取任务？（我假设是的，但只是确认。）
• 100 多个队列的可靠性如何？我记得旧版本的 Service Broker 非常不稳定。
• 我们可以动态/以编程方式创建新队列吗？
• 我们可以创建最小优先级队列吗（即当任务被推入队列时，它是根据优先级排序的）？
• 对性能和负载有什么影响？至少使用 RabbitMQ，我们可以将队列管理责任卸载到 RabbitMQ 集群，让我们的 SQL Server 可以自由地处理其他查询。
• 我们真的需要在队列之间设置某种“对话”才能使其工作吗？
• 考虑一个与另一个，我们还需要注意其他任何差异/优点/缺点吗？