asynchronous - 如何使用消息队列设计多步骤流程？

Question

假设我有一个多步骤异步过程，但有以下限制：


任何工人都可以执行单独的步骤
步骤必须按顺序执行


我正在考虑的方法：


插入一个代表整个过程的数据库行，并在“步骤已完成”列中跟踪进度。
订阅队列，当整个过程完成时，该队列将接收消息。
完成每个步骤后，更新db行并将该过程的下一步排队。
最后一步完成后，将“过程已完成”消息排队。
删除数据库行。


有什么想法吗？陷阱？聪明的方法吗？

Answer 1

我已经建立了一个非常类似于您在大型，任务密集型文档处理系统中所描述的系统的系统，并且在过去的7年中，这两个系统都必须兼顾其优缺点。您的方法是可靠且可行的，但我看到了一些缺点：


可能容易受到状态更改的影响（即，如果在所有步骤都排队之前流程输入发生了变化，那么后面的步骤输入可能与前面的步骤不一致）怎么办？
比您想要的更多基础设施，包括数据库和队列=更多的故障点，更难设置，需要更多的文档=不太正确
如何避免多个工人同时执行同一步骤？换句话说，数据库行说完成了4个步骤，工作进程如何知道是否可以执行＃5？是否不需要知道其他进程是否已经在进行此工作？您需要以其他方式（DB或MQ）包括用于锁定的其他状态。
您的示例对失败具有鲁棒性，但没有解决并发问题。当您添加状态以解决并发问题时，失败处理将成为一个严重的问题。例如，过程执行步骤5，然后将数据库行置于“工作”状态。然后，当该过程失败时，步骤5将停留在“工作”状态。
您的协调器有点繁重，因为它正在执行许多同步的数据库操作，并且我担心它可能无法像其他体系结构那样扩展，因为只能有一个...这取决于关于将您的步骤与数据库事务进行比较的时间-这可能只会成为一个非常大的问题。


如果我要再做一次，那么我肯定会把更多的编排推到工作流程上。因此，编排代码是通用的，可以由任何工作进程调用，但是我将保持中央控制进程尽可能的轻便。我也将只使用消息队列，而不使用任何数据库来保持体系结构简单和不同步。

我将创建一个具有2个队列的交换：IN和WIP（正在进行中）

中央流程负责订阅流程请求，并检查WIP队列中的超时步骤。

1）当中央进程收到对给定处理（X）的请求时，它将调用业务流程代码，并将第一个任务（X1）加载到IN队列中

2）第一个可用的工作进程（P1）事务性地将X1出队，并以保守的生存时间（TTL）超时值将其排队到WIP队列中。这种出队是原子的，IN中没有其他X任务，因此没有第二个进程可以处理X任务。

3）如果P1突然终止，那么除了超时，地球上没有任何架构可以保存此过程。在超时时间结束时，中央进程将在WIP中找到超时的X1，并将以事务方式从WIP出队X1并将其排队回到IN，从而提供适当的通知。

4）如果P1异常但正常终止，则工作进程将以事务方式从WIP出队X1并将其排队入IN，并提供适当的通知。根据异常，工作进程还可以选择重置TTL并重试该步骤。

5）如果P1无限期挂起或超过其TTL，则结果与＃3相同。中央进程将处理它，并且大概在某个时候将回收工作进程，或者规则可能是在超时的任何时候回收工作进程。

6）如果P1成功，则工作进程将确定下一步，即X2或X-完成。如果下一步是X2，则工作进程将以事务方式将X1从WIP出队，并将X2入队。如果下一步是X-完成，则处理完成，并且可以采取适当的措施，也许这会将X-完成排队到IN中，以供编排器进行后续处理。

我建议的方法的好处是：


指定工作进程之间的争用
处理所有可能的失败方案（崩溃，异常，挂起和成功）
使用RabbitMQ无需数据库即可完全实现简单的体系结构，从而使其更具可扩展性
由于工作人员可以确定下一步并入队，因此有一个更轻巧的编排器，从而可以扩展系统


唯一真正的缺点是它很容易受到状态更改的影响，但这通常不必引起关注。只有您知道这在您的系统中是否会成为问题。

我对此的最终想法是：编排应该有充分的理由。毕竟，如果进程P1完成了任务X1，现在是时候让某个进程对下一个任务X2进行工作了，那么看起来P1将是一个很好的候选者，因为它刚刚完成了X1并且现在可用。按照这种逻辑，流程应该只完成所有步骤，直到完成为止-如果需要按顺序完成任务，为什么要混搭流程？唯一的异步边界实际上是在客户端和工作进程之间。但是我会假设您有充分的理由这样做，例如，进程可以在不同的和/或资源专用的计算机上运行。