Message broker与数据库和监视

Question

数据库解决方案：每当工具A运行时，它会添加一个数据库记录，其中包括时间戳、元数据和状态“运行”。如果执行了工具A，而工具B应该运行，它会将DB记录状态更新为“NEXT_TOOL_B”。工具B经常查询DB中具有“NEXT_TOOL_B”状态的记录。如果它发现了一些东西，工具B将使用来自DB记录的元数据运行。

虽然我意识到数据库解决方案的缺点,例如从工具B进行持续轮询,但我错过了基于消息的解决方案中的一个特性：

当第三个工具，比如工具C，例如控制面板UI想知道当前状态时，它也可以随时查询数据库，如果工具a仍在工作，它会发现“运行”状态。在消息解决方案中，我没有真正看到“监视”状态的方法，除非finish消息将在队列中。

所以我的问题是，你能想出一种方法来实现这一点，使用消息或任何其他方法，而不是轮询？

Answer 1

问题中描述的场景是一个系统，该系统由多个不同的部件组成，这些部件协同工作以实现一个功能。在这种情况下，您有三个不同的进程{A,B,C}，连同一个数据库和可选的消息队列。所有系统，作为其存在目的的一部分，接受一个或多个输入，执行某些过程，并产生一个或多个输出。在您的情况下，您所希望的输出之一是系统及其处理的状态，这并不是一个完全不合理的事情。

队列还是数据库？

现在，进入你的问题。为什么使用消息队列而不是数据库？两者都是系统的相似html" target="_blank">组件，因为它们执行一些存储容量。在冰箱制造厂，你可能会问同样的问题--什么时候使用装配线上的货架比使用仓库更有意义？

最后，如果工厂的一个部分严重过量生产（我们不喜欢这种情况发生，因为这表明浪费），那么货架将会不堪重负，而过量的部分将需要放入仓库。信不信由你，这种情况在工厂里经常发生--有时工作站会在短时间内关闭，而仓库则充当一个较长期的缓冲。

什么时候使用一个或另一个？

所以-回到问题上来。当您期望您的消息生成通常将与消息的消耗相匹配，并且您需要检索速度时，您就会使用消息队列。你不会期望事情在排队的过程中停留很长时间。软件队列系统，如RabbitMq，还执行一些非常特殊的功能--比如确保一个作业只由一个处理器处理，如果第一个作业发生故障，它可以由另一个处理器拾取。

当队列可能会满时，或者当数据不能在一个作业步骤和另一个作业步骤之间丢失时，您还希望使用数据库。例如，一个制造厂经常将其成品存放在仓库中，等待发货给客户。使用数据库来满足应用程序中所有长期（超过几秒）的存储需求。

底线

大多数可伸缩软件系统都需要队列和数据库，关键是知道何时使用它们。