主题：[求助]流程审批并发处理

服务器接收到审核意见以后，要判断有些环节能不能继续进行（比如环节X的前置审核环节有两个，环节MN都通过了X才能进行），如果异步处理，M和N同时处理，可能就停在那里不动了。

所以，每一个项具体的业务，要单独开一个线程来执行下一步是否可以执行

而不是说，每一个终端用户提交审批意见以后，都单独开一个线程来处理，如果终端用户甲提交审批意见以后，服务器要看甲的业务有没有正在处理，正在处理，甲就得排队

只要审批不是在做同一个业务，都可以单独线程处理。

但如果是多人在做同一个业务的审批，就得排队

这就是我所想说的，如果是同一个业务ID，服务器要处理多人审核意见时，就要排队；如果不是同一个业务ID时，就不需要排队

这个没问题，可以理解，这个不需要排队处理，每接收到一条信息，就插入数据。

我现在要做的事情是：服务器接收到客户端的用户张三传来的某一个环节A的审核信息，包括业务ID、流程环节ID、审核意见，然后就要调用函数去判断张三审核以后，下一步应当执行什么，是回退到以前的某一个环节，还是继续执行下一步X

同理，接收到李四的环节B的审核信息、王五的环节C的审核信息，都要这么处理。

假如X要执行，是取决于张三、李四、王五分别处理的ABC三个环节都同意才可以，否则就不可以。（如果张三同意，李四还没审或不同意，都不可执行）

如果张三、李四、王五间隔很长时间审核，就没什么问题。

假如张三、李四、王五同时审核完成（假如都同意），服务器是要排队处理的吧，依次把张三、李四、王五的审核意见传进函数，才能最终确定X能不能执行啊。

如果异步处理，会不会出问题？－－得到一个结论：X不能执行？

客户端审核完成以后，由客户端往数据库里写审核流水也没有问题，把审核的详细信息通过消息发给服务器，由服务器往数据库里写审核流水也可以。

如图的X必须三个黄色的环节都审核同意才可以执行

但是判断下一步能不能执行，肯定是交给服务器来执行的。
此主题相关图片如下：流程.png

消息处理确实是需要排队的，这种情况只能把接收的客户端审核数据保存到数据库里，然后在调用异步函数里通过查询数据库的时候数据是否完整来决定下一步

－－－因为流程审核可能会被退回再审，也就是同一个环节可能会走多次。比如某个环节审核不同意，退回去重新处理，再走到这个环节的时候，还不同意，又退回，又又又……

所以，我的想法是，如果是同一个业务ID（比如3月份给供应商甲的供货对账），如果有多人同时审，就排队处理这个业务ID的审核流水；如果不是同一个业务ID（比如3月份审供应商甲的对账、供应商乙的对账、……）就开启多线程处理。一个业务ID开启一个线程

如果没有上面这个处理过程。K打回U，U环节改了数据，再走到下一步（要K、B再审），K同意了，如果这时候BM（或N）不再审，数据库直接判断说K、P、Q都通过了，就直接往下走，这肯定是不行的。

所以，审核流水信息虽然重要（但它只是记录性质的），更重要的是下面这一点