Database MessageBroker与数据库和监控

我的问题与这个问题有些相似之处：

在我目前的（半专业）项目中，我还需要决定是选择基于MessageBroker的数据库（例如，使用RabbitMQ）还是完全不同的解决方案

让我们想象两个工具，工具A和工具B。 每当工具A运行并完成时，可能会为工具B做一些事情。工具A的执行需要一段安静的时间（>60秒），并且通常对工具B没有任何事情可做。工具A为工具B提供一些元数据，以便工具B知道该做什么

基于消息的解决方案：建立工具B正在使用的消息队列。如果工具A已执行且工具B应运行，则工具A将消息（包括元数据）发布到工具B接收的队列，以便工具B将使用消息中的元数据运行

数据库解决方案：每当工具A运行时，它都会添加一条带有时间戳、元数据和状态“running”的数据库记录。如果工具A已执行且工具B应运行，则它会将数据库记录状态更新为“下一个工具B”。工具B不断向数据库查询“下一个工具B”状态的记录。如果发现了什么，工具B将使用数据库记录中的元数据运行

虽然我知道数据库解决方案的缺点，例如来自工具B的持续轮询，但我错过了基于消息的解决方案中的一个功能：

每当第三个工具（如工具C，例如控制面板UI）想要知道当前状态时，它也可以随时查询数据库，如果工具a仍在工作，它将找到“运行”状态。在消息解决方案中，我真的看不到“监视”状态的方法，除非完成消息在队列中

---

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

问题中描述的场景是一个系统，它由多个不同的部分组成，这些部分一起工作以实现一个功能。在本例中，您有三个不同的进程

{A、B、C}

，以及一个数据库和可选的消息队列。所有系统，作为其存在目的的一部分，接受一个或多个输入，执行一些过程，并产生一个或多个输出。在您的情况下，您需要的输出之一是系统的状态及其处理，这并不是一件完全不合理的事情

队列还是数据库？

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

数据库就像仓库——它们被设计用来存放许多不同的东西，并使它们保持相对整齐。良好的仓库使用户能够快速找到仓库中的物品，并避免丢失零件和材料。如果它进入，它可以很容易地回来，但不是立即

另一方面，消息队列类似于装配线中位于操作员站附近的搁板。从上一次操作中积累的零件等待运行该站的人员消耗。这些架子被设计用来存放少量相同的东西，就像软件系统中的消息队列一样。他们离工人很近，所以当下一部分准备好工作时，可以很快地检索到它（而不是去仓库，这可能需要几分钟或更长时间）。此外，工人可以立即看到架子上的东西——如果架子是空的，工人可以休息一下，等待它再次积累一两部分

最后，如果工厂的一部分生产严重过剩（我们不喜欢这种情况，因为这表明浪费），那么货架将被压垮，过剩的部分将需要放入仓库。信不信由你，这种情况在工厂里经常发生——有时车站会在短时间内关闭，而仓库则起到了长期缓冲的作用

何时使用其中一种？

回到问题上来。当您希望生成的消息通常与消息的使用量相匹配，并且需要加快检索速度时，可以使用消息队列。你不希望事情在队伍中停留太久。软件队列系统（如RabbitMq）也执行一些非常特定的功能，比如确保一个作业只由一个处理器处理，并且如果第一个处理器出现故障，它可以由另一个处理器处理

另一方面，对于需要跨多个处理步骤持久化状态的事物，可以使用数据库。您的工作状态是应该存储在数据库中的内容的完美示例。要继续进行工厂类比，请将其视为一份报告，在每个步骤完成后发送回生产计划员。生产计划员将把它保存在数据库中

当队列可能已满时，或者当数据在一个作业步骤和另一个作业步骤之间不丢失非常重要时，您还需要使用数据库。例如，制造厂通常会将其成品储存在仓库中，等待装运给客户。使用数据库满足应用程序中的所有长期（几秒钟以上）存储需求

底线

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

---

希望这有一定的意义。

您可以让队列的生产者和消费者更新NoSQL数据库或RDBMS中的表。这将允许您查看状态