workman 服务端处理大量业务逻辑阻塞
本机用workman 做了服务端与客户端，
客户端起定时器去通知服务端与做业务处理，
我的业务处理是定时从表内读取机器人curl调用一系列的接口发送一些数据。
我想问下，我这种会导致阻塞吗？
客户端时间到了去通知服务端去处理。服务器业务处理时间比较长。等第二个通知到了可能第一个还没处理完，这种情况也会导致阻塞貌似
有什么比较好的解决方案吗？
5060 5 1
5个回答
相似问题
年代过于久远，无法发表回答
workman服务端不停的接受到 onMessage 消息，消息是多线程处理吗？还是要等上一次的处理完才能处理
workerman并没有多线程的概念，是多进程模型，单进程内调用curl请求会造成业务阻塞的，但是从多进程角度看这个可看做是并行运行的，如果任务特别繁忙，可以考虑使用:
http://doc.workerman.net/faq/async-task.html
我已经用了这个了，客户端AsyncTcpConnection 服务端通知服务端去处理业务。
知道怎么做了。没有多线程多进程处理吧
看来只能设置workman 的 count ，多进程来处理业务了。
1、关于curl部分：既然 curl 部分存在阻塞并且你无法忍受这部分阻塞，那么可以考虑非阻塞版的curl， 或者干脆就这部分阻塞代码再抽出来放在另外一组独立worker来处理，然后同样可以考虑利用 AsyncTcpConnection 进行通信；
2、关于服务端部分：服务端已经剥离出来的这部分已经处于异步架构模式，所以这点肯定没问题，如果业务处理还是很慢，那么就得考虑多进程，甚至是分布式集群处理，让机器处理的更快一些；
总之繁重的业务或者说存在阻塞地方，使用异步架构肯定没错。
我现在就是把阻塞的代码放到单独的work服务端去处理，服务端开多进程去处理，但是还是会慢，麻烦看下这个。https://wenda.workerman.net/question/4791
我觉得阻塞和慢并不能简单的等同，你原先的慢有一部分是因为curl的阻塞，采用异步架构后，现在的慢应该说的是你业务本身处理的慢吧。