前言

目前我是一名Golang/Python開發(fā)工程師，之前是主要使用PHP進行開發(fā)的傳統(tǒng)web后端工程師，后面因為工作原因開始接觸并使用Python和Golang來做一些開發(fā)工作，涉及到數(shù)據(jù)分析數(shù)倉建設相關及部分游戲相關的開發(fā)；也因為工作原因接觸到了很多其他語言的特性或者是其他語言團體推崇的技術(shù)方向方案。

我非常喜歡PHP，生活中工作中幾乎是能用PHP解決的都盡可能使用PHP，同時也很推崇PHP-cli的開發(fā)模式，尤其喜歡workerman/webman，早期webman還未誕生的時候我在公司曾使用workerman自建了一套框架，與現(xiàn)在的webman非常相似。

今天我要分享的主要是我所理解的協(xié)程相關的分享內(nèi)容，內(nèi)容會涉及到進程和線程相關的內(nèi)容點，主要目的是為大家揭開協(xié)程神秘的一些面紗，讓大家知道協(xié)程并沒有那么的難，它其實是一種非常簡單易懂的編程方式方案。

在閱讀本分享前，建議先閱讀之前的分享 趣談程序演變的過程，有助于理解本分享內(nèi)容。

阻塞/非阻塞

在文章趣談程序演變的過程中我曾提到兩個概念內(nèi)容，阻塞與非阻塞；如何理解阻塞與非阻塞呢？很簡單：

1. 阻塞

我去超市買一袋橘子：我需要穿好衣服、下樓、走路、到超市挑選橘子、付款、走路、上樓、到家；在這個流程中，我在買好橘子之前全程被占用，需要做的所有事都需要為買橘子服務，當我做完這一系列事情之后才可以干下一件事情，比如寫代碼，比如拉屎等等。

我們可以發(fā)現(xiàn)阻塞是一種非常簡單且占用資源比較少的情況，因為全程只需要占用我一個人，只是需要花費的時間比較長。

2. 非阻塞：

我通過外賣來實現(xiàn)去超市買一袋橘子：我只需要通知外賣員告知他去xx超市幫我買橘子僅此而已，然后等待外賣員將橘子送達我住處即可；在這個流程中，我在買好橘子之前全程沒有被占用，我隨時都可以干任何事情，比如吃飯、寫代碼、拉屎，隨意做我想要做的事情。
但是這里其實要注意，為了實現(xiàn)這種情況，我們必須要有一個外賣員來幫我們實現(xiàn)，同時我們在告知外賣員的這個過程中其實是被阻塞的，我們在和外賣員溝通的這個過程中。是沒辦法做其他事情的。

我們由此可以發(fā)現(xiàn)，非阻塞在某一個微觀內(nèi)其實多多少少包含了阻塞的部分存在的，并且整體是通過消耗更多的資源（人），從而減少時間的消耗。

進程/線程

上面講了非阻塞，講了資源，那么資源在系統(tǒng)里面如何實現(xiàn)如何使用呢？答案就是進程或者線程（關于進程和線程的概念我這里就不多贅述了，百度都有，可以自行百度）。

PHP中通常來說不使用多線程進行編程，通常來說都是使用多進程來實現(xiàn)一些并發(fā)效果的，比如workerman/webman就是用了fork來進行多進程的處理，通過不同的onWorkerStart的業(yè)務邏輯來實現(xiàn)不同的業(yè)務進程，每種業(yè)務進程都可以有自己的單/多進程處理方案。

協(xié)程

我們現(xiàn)在常談的“協(xié)程”，實際上嚴格意義上來說叫“協(xié)程方案”，它包含了三樣東西在其中：

1. 協(xié)程
2. 協(xié)程調(diào)度
3. 協(xié)程執(zhí)行

協(xié)程在一些語言實現(xiàn)中或者在一些文章中又叫纖程，PHP中的fiber、yield分別是有棧協(xié)程和無棧協(xié)程（關于這個概念可以自行百度，不影響本次分享的內(nèi)容理解）；協(xié)程本身不具備并發(fā)并行能力，它只是一種代碼執(zhí)行的方案，它僅僅需要實現(xiàn)中斷、喚醒即可，這也是fiber、yield的基本功能。

這么看來，好像協(xié)程并沒有什么用對吧，它好像只能暫停/繼續(xù)，為什么我們非要實現(xiàn)這樣的功能呢？

如果這么想，其實我們就陷入了阻塞模式的思維方式，我們盲目的把寫的代碼跟獨自買橘子聯(lián)系在了一起，從上往下讀，在哪暫停就在那繼續(xù)；看似沒用，但假設我們用非阻塞模式去思考它，把我們整體的行為按照更小的顆粒度拆分成不同的小行為，交給不同的“外賣員”執(zhí)行，那么這樣，是不是就不一樣了？

由于外賣員數(shù)量可能存在限制，不可能是無限多個，那么外賣員就需要根據(jù)具體情況具體分析，暫時放下手中的小行為，換另一個小行為先行，同時外賣員也可能找其他外賣員代工，在這個過程中，如果合理利用時間差，那么每個人都不需要花費太多的時間，合理利用了已存在這世界上的其他外賣員。

對，這就是協(xié)程調(diào)度器要做的事情，通過一些合理的規(guī)劃來進行調(diào)度，而外賣員就是協(xié)程執(zhí)行單元！

這里有許許多多的調(diào)度規(guī)則，根據(jù)不同語言或者不同方案有各自的實現(xiàn)方式，這里可以自行百度時間分片，有助于理解調(diào)度規(guī)則。

至于外賣員，是多線程/單線程實現(xiàn)還是多進程實現(xiàn)都可以。

延申問題

上述內(nèi)容，其實我們可能會延申出來一些疑惑：

1. 如果不同的小行為之間需要存在關聯(lián)關系，外賣員又可能存在找其他外賣員代工的情況，怎么解決呢？

   1. 限制一些特殊情況的小行為不允許代工行為，在Golang中systemcall和netpoll的處理情況就各不同，systemcall不會存在跨線程執(zhí)行，它分配在A線程上執(zhí)行就不會被其他線程接管，而netpoll就可能會被其他線程接管。
   2. 通過上下文的包裹和限制，類似實現(xiàn)一個票據(jù)，交到外賣員手中，外賣員每次被調(diào)度執(zhí)行之時都會看一下票據(jù)來根據(jù)優(yōu)先順序執(zhí)行。

2. 那假設我通知完外賣員，我睡著了怎么辦？我壓根沒有接到外賣員回執(zhí)怎么辦？這種情況存在于主線程比協(xié)程執(zhí)行單元更先執(zhí)行完。

   1. 我每通知一個外賣員我就在本子上記下一筆，當我自己做完了自己的事情以后，我在房間里來回踱步，等待外賣員們的回執(zhí)，回執(zhí)一個我就劃掉一筆。直到劃完全部，然后再去睡覺；這就是waitGroup，簡單地可以通過一個循環(huán)來查詢某個計數(shù)器判斷跳出實現(xiàn)。

PHP如何實現(xiàn)協(xié)程方案

PHP常使用多進程，進程間通訊傳遞信息極為不方便，同時消耗資源會更多，通常來說不會用進程來實現(xiàn)協(xié)程的執(zhí)行單元；但是我們想到異步想到非阻塞，我們就會想到event-loop，對，我們可以通過event-loop來實現(xiàn)協(xié)程執(zhí)行單元，將協(xié)程執(zhí)行單元注冊在event-loop中來進行執(zhí)行。

但是要注意的是實現(xiàn)完整的協(xié)程方案除了協(xié)程、協(xié)程執(zhí)行單元外還需要一個協(xié)程調(diào)度器，所以在每個event-loop注冊執(zhí)行前后需要實現(xiàn)調(diào)度器和調(diào)度規(guī)則才可以，讓event-loop進行合理的回調(diào)的中斷和繼續(xù)，合理利用時間。

這樣做其實會讓event-loop變得比較臃腫和復雜，不是特別利于維護，整體思路其實和golang的systemcall實現(xiàn)方案是相似的，因為都是在同一個線程上進行執(zhí)行，不存在線程的切換。

簡單理解

最后呢，其實你把協(xié)程方案想象成是一個縮小的隊列系統(tǒng)，由一個程序A發(fā)布消息（協(xié)程），由一個程序B調(diào)度（隊列服務），再有另一個程序C進行消費，并在消費后通知來源程序，只不過ABC都是在一個線程或者一個程序內(nèi)執(zhí)行罷了，它們只是瘋狂利用了時間的空隙罷了。

暫時想到的只有這么多，如果想到其他的，再說

• 如有錯誤請指正！！