我測試了一下確實(shí)是阻塞的，workerman是非阻塞的，為什么webman不搞成非阻塞的，就像golang的gin框架，來一個(gè)請求就分配一個(gè)協(xié)程去執(zhí)行，不阻塞其它請求的執(zhí)行

同問，我的項(xiàng)目現(xiàn)在沒問題，假如數(shù)據(jù)庫量大了，一個(gè)請求從50ms增加到300ms，那我項(xiàng)目的并發(fā)能力豈不是急劇下降，相當(dāng)于下降6倍

workerman和webman都是multi-reactor模型，基于event-loop的reactor，在單個(gè)event-loop中就是排隊(duì)執(zhí)行的，不論workerman還是webman；
golang下面分配的協(xié)程最后交給執(zhí)行線程來執(zhí)行，實(shí)際上是有一個(gè)線程池的；對于線程池來說，內(nèi)部的執(zhí)行也是排隊(duì)的，當(dāng)線程池占滿后，同樣會阻塞，不同的是對于協(xié)程來說，是有類似時(shí)間片算法的，是有最大占用時(shí)間的，當(dāng)達(dá)到了這個(gè)時(shí)間后，線程會將協(xié)程掛起，執(zhí)行下一個(gè)協(xié)程；但值得注意的是，如system call的操作，對于當(dāng)前執(zhí)行線程來說是同步阻塞的，也就是說不論是否超出了時(shí)間片，該協(xié)程也必須等待該行代碼執(zhí)行完才可以出讓當(dāng)前線程；
對于上述描述，我們其實(shí)可以把event-loop也看作是線程池（前提是這些服務(wù)是否本身支持非阻塞異步），比如steam相關(guān)的內(nèi)容，實(shí)際上就是支持非阻塞異步的，所以看起來和線程沒有兩樣；
PHP是沒有線程的，這里即便是有fiber可以中斷/恢復(fù)，但是沒有一個(gè)旁置的執(zhí)行單元來處理也始終會阻塞當(dāng)前；如果go沒有線程，那么他也和PHP一樣，只能依托生態(tài)中的包或者拓展的異步非阻塞能力+event-loop完成這樣的操作；
另外提一下，即便是swoole也是有一個(gè)獨(dú)立的線程來處理協(xié)程的；

composer組件99%都是基于阻塞式開發(fā)的，它們不支持異步或協(xié)程。

另外協(xié)程并不是萬能的，
看下 https://www.techempower.com/benchmarks 今年7月份最新壓測數(shù)據(jù)。webman和gin的對比，不管是單查詢、多查詢、更新、查詢+更新、純文本，所有指標(biāo)webman都比gin的QPS高1倍左右。你們還要啥自行車。

如果你們的數(shù)據(jù)庫慢，或者操作數(shù)據(jù)庫等存儲比較多，就多開一些進(jìn)程就好了。

另外說一句，PHP沒有線程，但C有，其實(shí)如果在這一塊想要研究的話，可以自己基于C11及以上的標(biāo)準(zhǔn)寫一下thread相關(guān)的api，編譯成動(dòng)態(tài)庫，通過PHP:FFI來進(jìn)行調(diào)用；這樣的拓展方式比傳統(tǒng)的PHP拓展要更簡單一些；
目前這一塊還是很多PHPer的盲區(qū)，也有很多可以探索和創(chuàng)造的輪子；
當(dāng)然，關(guān)于線程庫也有很多已經(jīng)成熟的，比如libpthread。

并發(fā)再高，解決不了這位朋友的問題，還是只能用go http://www.wtbis.cn/q/9057

目前的php生態(tài)及各種組件決定webman沒辦法完全支持異步或協(xié)程。

@ontheway 那位朋友的問題，假設(shè)他的這個(gè)請求是持續(xù)性的，那么使用go也解決不了，GPM的線程池是有上限的，占滿只是時(shí)間問題；另外線程開多了最后還會影響CPU；
但假設(shè)那位朋友的問題不是持續(xù)性的，即便是同步阻塞也有解決方案，就是多開進(jìn)程；
甚至業(yè)務(wù)可以拆分成異步的；
但如果業(yè)務(wù)一定要同步，并且換go來解決，我只能說治標(biāo)不治本；也僅僅只是把”能開10個(gè)進(jìn)程“的機(jī)器換成了”開20個(gè)線程”而已。

@ontheway，這個(gè)很好解決啊，慢請求直接開一組進(jìn)程去處理就好了，不影響其它請求。

@walkor 那位朋友的需求是調(diào)用端需要等待請求結(jié)果(似乎是QQ群里說過)...所以我才建議直接FPM

思維問題而已，就那個(gè)開幾個(gè)websocket就完全可以處理好，非要用http這種短協(xié)議當(dāng)然不好處理。
1 前端發(fā)起請求，生成一個(gè)請求ID，
2 后臺ws進(jìn)程保存好請求ID，異步請求接口
3 獲取到數(shù)據(jù)后，扣余額，響應(yīng)數(shù)據(jù)給前端，包括請求ID，前端再根據(jù)請求ID來判斷響應(yīng)的數(shù)據(jù)。

@2548a websocket和消息隊(duì)列，做過技術(shù)的一般都想的到，就看那位兄弟用不用而已

golang的對于網(wǎng)絡(luò)io來說的netpoll可以粗略的理解為線程+協(xié)程調(diào)度版的workerman，協(xié)程在線程+調(diào)度器之上做的并發(fā)，相當(dāng)于自行實(shí)現(xiàn)了http句柄掛起，無須自行開發(fā)；
golang的systemcall相關(guān)的內(nèi)容，比如文件io等操作，是阻塞的，并沒有利用reactor模型，只是線程池；
至于掃碼登陸或者其他長輪詢場景，可以使用websocket代替，php的socket、stream相關(guān)函數(shù)同樣是可以將句柄掛起；只是說某些場景下僅僅為一個(gè)接口實(shí)現(xiàn)一個(gè)websocket沒有必要，所以出現(xiàn)了http來實(shí)現(xiàn)服務(wù)端長輪詢；但如果有多種服務(wù)，個(gè)人覺得更為完善的websocket會比http更好；
golang較于workerman、swoole甚至java的優(yōu)勢，我認(rèn)為在于天生統(tǒng)一了event-loop、線程池、協(xié)程調(diào)度等并發(fā)場景所需要的組件和功能，并且它的生態(tài)也是圍繞這些組件和功能開發(fā)的，更為“工業(yè)化”和“統(tǒng)一”，反觀PHP、Java，歷史遺留的生態(tài)前者和后者都有大量同步阻塞的組件，workerman、swoole等reactor生態(tài)在PHP生態(tài)中僅占非常小的一部分，需要重復(fù)造輪子；Java甚至現(xiàn)在還有大量的JDK8，還有JDBC遺產(chǎn)始終是同步阻塞的，loom這樣的寫成特性，vertx、netty等reactor生態(tài)也同樣不火；node.js中雖然天生是異步，但因?yàn)槭菃尉€程，所以性能也同樣不如golang。