消息队列。数据库与专用MQ

我正在寻求有关消息队列的建议。我们要求将“职位”发布到消息队列中。

最初的建议只是使用SQL Server实例并处理来自该实例的消息。我在互联网上阅读的所有内容都表明，将数据库用于Message Queue并不是可扩展的解决方案。因此，建议使用RabbitMQ或其他第三方的MQ。

要考虑的另一件事是“作业处理”的要求不会低于30秒，因此执行作业的过程将每30秒轮询一次数据库。在我看来，这似乎还不错，并且在不向数据库中添加大量负载的情况下可以正常工作。

我们已经在客户端上建立了一个数据库，我们可以为此使用它，因此它不会为客户端增加太多额外的支持，而如果我们添加了一个第三方MQ，则会对网络配置等提供额外的支持。考虑到有很多用户，这相当可观。

我正在考虑的另一个选项是允许用户在两​​者之间进行选择。如果他们是小用户，则可以使用Sql Server解决方案，但如果他们是大用户，则可以允许他们配置第三方MQ解决方案。

我没有出售任何解决方案，我想知道是否有人有我应该考虑或建议的东西。

我在互联网上阅读的所有内容都表明，将数据库用于Message Queue并不是可扩展的解决方案。

“ 不使用X，因为它不会缩放 ”（链接包含一些可能会令人反感的语言）的人群经常忽略了这个现实，那就是缩放并不总是很重要。我要说的是，如果您总体上看一下地球表面上的每个应用程序，那么规模几乎都不重要。

您的评论引用了每天20,000条消息的速度，这意味着您需要支持平均每秒0.23条消息的速度（每4.3秒发送一次）。如果您的项目成功比您预期的成功了两个数量级，那么您的需求就会跳到每秒处理23条消息，这是我很乐意为我的四岁手机或Raspberry提供的一项任务皮。即使您再加上几个数量级，这仍然不是一个大规模的应用程序。

我已经看到（不幸的是，从旁观中看）项目的结局很糟糕，因为它们要么花太多时间太早地迷恋不会发生的规模问题，要么根本就没有时间，最终被最终的规模压垮了。像其他所有东西一样，有一个快乐的媒介。如果您认为针对应用程序进行大规模扩展是切实可行的，那么就不难做一个业务案例，即进行少量的额外工作，以围绕现在廉价部署的不可扩展部分构建足够的抽象。这样做意味着以后，如果需要扩展规模，您便有一种方法（可能还有收益）可以批量更换那些零件，而无需重新考虑整个系统。

尽管您的应用程序的消息量不会使数据库或消息队列系统变得疲惫不堪，即使在适度的硬件上也是如此，但是您可能还对如何处理消息事务有其他要求，这使一个或另一个成为更好的选择。这些要求是您应该评估的。

当您有许多消息队列并在它们之间路由消息，将消息扇出到多个使用者等时，消息队列才真正进入它们自己。

如果您只有一个“工作队列”，您想处理“脱机”，那么使用SQL表就可以了。

不要忘记确保您有某种方式标记正在进行的作业，清除旧作业并在系统停止时发出警报。但是对于单个队列，手动管理这些事情要比维护单独的排队解决方案少。

正如其他人提到的那样，规模在这里可能并不重要。使用两种不同的存储机制的问题是事务完整性。

如果使用专用消息队列，则在发生故障时需要选择以下选项之一。

1. 允许数据可以在mb上，但不能在db中
2. 允许数据可以在db中但不能在mb中
3. 在db和mq之间设置两阶段提交或分布式事务

如果仅使用常规事务将数据保存在一个地方，那么所有这些问题都会消失。因此，将db用作任务队列是一个很好的解决方案。

出于实用性考虑，我使用消息队列的主要原因是：

• 我不必重新发明轮子。使用数据库设计最简单的消息队列至少需要花费几个小时的思考，几个小时的编码等等。与实现消息队列相比，配置和/或自动配置所需的时间微不足道。
• 消息队列为生产者和使用者提供了清晰美观的界面。这可能是编写应用程序中最重要的事情。没有接口，消息队列基本上只是数据的集合
• 消息队列提供了将来可能需要的更多功能

关于允许用户选择，这实际上是用户不关心的实现细节。用户应该具有相同的界面，并且如果使用数据库或消息队列，则用户应该没有任何区别。设置单一设计后，用户可能的选择是需要部署多少个节点以满足他们的需求。

根据性能测试，我已经创建了一个Mssql消息队列解决方案，该解决方案每秒可以处理20k次操作，并且大多数时候我们需要10 / sec。我认为实际上可以拥有内置优先级的事实是专用消息队列缺少的功能。这是我的主要要求。