当C环节的审核信息为同意时，因为下一步是D，这时候系统找到了B环节同意的信息，就会向D环节的涉众发送信息，通知他们可以做D环节的审核工作了

系统是要向涉众推待办事务，而不是用户登录进来，点某一个单据的审核，然后系统不让他点，或者允许他点。

这个就不合适了。

最好是系统根据规则判断某一个环节X可以执行了，给这个环节的涉众发消息，然后涉众用户收到消息，再去办理审核事务

否则，就要用户自己去点，啊，点不了，估计是还没轮到我。

过了一天，又去点，啊，还是点不了

又过了一天，又去点，啊，还是点不了

这显然不人性化啊

我想的是客户端处理可能受制于网络条件等等因素，如果在服务器上统一处理可能在这方面的影响会小一些。

如果在服务器上处理的话，同一业务单据排队，不同业务单据开启多线程，该当如何做呢？

如果是在服务器处理，和数据库在同一台电脑的话，2个查询一个消息发送，估计也就100毫秒左右的事，这种还需要多线程？启动一个线程的消耗估计都不止100毫秒了。

不如具体举例说明，现在的实际执行操作会慢到什么程度，会需要使用多线程？

1、下一个环节是否可以执行（就象上面的例子说BC两个环节都通过，D环节才可以执行，这是简单的，实际的执行还有业务条件，例如金额<10万，要流转到D环节，如果<50万，要流转到E环节，如果<100万，要流转到F环节；还可能再附加通过率条件，如同一环节的审核通过率达到60%以上才允许流转到下一环节）

2、下一环节如果可以执行，要通知哪些人去执行下一环节的审批（也就是形成哪些人的待办任务）

有可能是我的代码判断效率不够高吧，执行耗时约1秒钟

正是因为耗时较长，所以才想到在服务器上统一执行

不一定要开启多线程执行，我只是举例。不过我的理解是子线程也是多线程的一种吧

用户点个按钮滴答2下，一秒，不算慢了吧。如果觉得慢，可以考虑把客户端的代码放到异步函数里处理。

何况在客户端，可以不同的用户都是并发操作的，不会互相影响。结果把审核都放到服务器排队，不把并发变相变成了顺序操作了吗，这样不更慢！

B环节张三在审，C环节李四在审，同时提交。

张三（结论为同意）提交时，从后台获取数据显示李四还没有提交，所以，D环节不能执行

而李四（结论也是同意）提交时，从后台获取数据张三还没有提交（因为各种原因，如网络传输数据，而实际上张三已经提交了），所以，D环节也不能执行。

但实际上，张三李四都同意且都提交了，D环节应当执行，但阴差阳错，整个流程停在那里不动了。

这种少数情况，如果要在服务端处理，需要有一个记录用户发送消息的表或者列。让服务器可以查询B或者C有没有发送过消息给D。然后服务端在计划管理里每10秒查询一次的话，按顺序查询发消息即可。其实没有什么必要多线程，除非在这10秒内会出现很多同时提交的并发处理。