1
为什么数据库作为队列那么糟糕？[关闭]
我刚刚读了这篇文章，我很困惑。 假设有1个webapp和1个不同的应用程序充当“工作者”，它们共享同一个数据库。 哦，我说“分享” ..但是这篇文章警告了什么？： 第四，在应用程序（或服务）之间共享数据库是一件坏事。在其中放置无定形共享状态太诱人了，在您不知道它的情况下，您将拥有一个巨大的耦合怪物。 =>不同意。在某些情况下，不同的应用程序仍然是同一单元的一部分，因此，在这种情况下，“耦合问题”的概念毫无意义。 让我们继续：Web应用程序处理客户端HTTP请求，并可能随时更新某些聚合（DDD术语），从而生成相应的域事件。 工作人员的目标是通过处理所需的作业来处理那些域事件。 重点是： 事件数据应如何传递给工作人员？ 正如阅读的文章所提倡的那样，第一个解决方案是使用RabbitMQ，它是一款出色的面向消息的中间件。 工作流程将很简单： 每当Web dyno生成事件时，它都会通过RabbitMQ发布该事件，从而为工作人员提供帮助。 缺点是，如果不处理潜在的发送失败或硬件问题，则无法保证提交汇总更新和事件的发布之间的即时一致性。这是另一个主要问题。 示例：发布事件可能没有成功进行汇总更新...导致事件代表域模型的错误表示。 您可能会争辩说存在全局XA（两阶段提交），但这不是适合所有数据库或中间件的解决方案。 那么，什么是确保这种即时一致性的好的解决方案？： IMO，将事件存储在数据库中，并且与聚合更新在同一本地事务中。 将创建一个简单的异步调度程序，并负责从数据库查询当前未发布的事件，并将其发送到RabbitMQ，后者再填充工作程序。 但是，为什么还要在webapp端并需要一个额外的调度程序：为什么在这种情况下需要RabbitMQ？ 通过这种解决方案，在逻辑上似乎可以不需要RabbitMQ，尤其是因为数据库是共享的。 确实，无论如何，我们都看到即时一致性涉及从数据库进行轮询。 因此，为什么工人不直接对这次投票负责？ 因此，我想知道为什么网络上有那么多文章在推广面向消息的中间件时几乎没有批评数据库排队。 文章摘录： 简单，使用正确的工具完成工作：这种情况正在引起消息传递系统的注意。它解决了上述所有问题；不再需要轮询，高效的消息传递，无需从队列中清除已完成的消息以及没有共享状态。 和即时的一致性，被忽略了吗？ 综上所述，实际上无论情况如何，无论是否共享数据库，我们都需要数据库轮询。 我错过了一些批评观念吗？ 谢谢