workman 服務(wù)端處理大量業(yè)務(wù)邏輯阻塞
本機(jī)用workman 做了服務(wù)端與客戶端，
客戶端起定時(shí)器去通知服務(wù)端與做業(yè)務(wù)處理，
我的業(yè)務(wù)處理是定時(shí)從表內(nèi)讀取機(jī)器人curl調(diào)用一系列的接口發(fā)送一些數(shù)據(jù)。
我想問(wèn)下，我這種會(huì)導(dǎo)致阻塞嗎？
客戶端時(shí)間到了去通知服務(wù)端去處理。服務(wù)器業(yè)務(wù)處理時(shí)間比較長(zhǎng)。等第二個(gè)通知到了可能第一個(gè)還沒(méi)處理完，這種情況也會(huì)導(dǎo)致阻塞貌似
有什么比較好的解決方案嗎？
5個(gè)回答
workerman并沒(méi)有多線程的概念，是多進(jìn)程模型，單進(jìn)程內(nèi)調(diào)用curl請(qǐng)求會(huì)造成業(yè)務(wù)阻塞的，但是從多進(jìn)程角度看這個(gè)可看做是并行運(yùn)行的，如果任務(wù)特別繁忙，可以考慮使用:
http://doc.workerman.net/faq/async-task.html
1、關(guān)于curl部分：既然 curl 部分存在阻塞并且你無(wú)法忍受這部分阻塞，那么可以考慮非阻塞版的curl， 或者干脆就這部分阻塞代碼再抽出來(lái)放在另外一組獨(dú)立worker來(lái)處理，然后同樣可以考慮利用 AsyncTcpConnection 進(jìn)行通信；
2、關(guān)于服務(wù)端部分：服務(wù)端已經(jīng)剝離出來(lái)的這部分已經(jīng)處于異步架構(gòu)模式，所以這點(diǎn)肯定沒(méi)問(wèn)題，如果業(yè)務(wù)處理還是很慢，那么就得考慮多進(jìn)程，甚至是分布式集群處理，讓機(jī)器處理的更快一些；
總之繁重的業(yè)務(wù)或者說(shuō)存在阻塞地方，使用異步架構(gòu)肯定沒(méi)錯(cuò)。
-
caption 2019-12-13
我現(xiàn)在就是把阻塞的代碼放到單獨(dú)的work服務(wù)端去處理，服務(wù)端開(kāi)多進(jìn)程去處理，但是還是會(huì)慢，麻煩看下這個(gè)。https://wenda.workerman.net/question/4791
-
phpcreeper 2019-12-13
我覺(jué)得阻塞和慢并不能簡(jiǎn)單的等同，你原先的慢有一部分是因?yàn)閏url的阻塞，采用異步架構(gòu)后，現(xiàn)在的慢應(yīng)該說(shuō)的是你業(yè)務(wù)本身處理的慢吧。
