學習swoole需要的前置知識
學習一項新的技術，最重要的就why、what、how。
這門技術是什麼，為什麼用它，要怎麼用它。這篇文件的作用就是為了解釋what與why。
php-fpm與swoole的異同
常駐記憶體
一個請求透過nginx轉發到php來執行，中間是透過php-fpm來溝通連線的，透過一種叫cgi的協議來通訊。
在php-fpm還未出現之前，php一般都是透過php-cgi這個php官方元件來與web server進行通訊的，它的特點是每次執行都需要重新載入一次php.ini中的配置，並且每有一個請求都會重新啟動一個程式來執行，執行完畢後再銷燬掉。
這種方式每次都會重新解析php.ini、重新載入全部擴充套件，並重新初始化全部資料結構，這無疑是對cpu效能的浪費行為，於是就出現了fast cgi。
fast cgi的應用體現便是php-fpm。透過一個master程式管理多個worker程式的方式，在主程式啟動時便將php.ini中的配置等資訊載入記憶體，worker程式建立時會繼承master程式的資料，並且worker程式處理完一個請求後不會銷燬，而是繼續等待下一個請求。所以只需要一次載入，php.ini與擴充套件和初始化資料這部分的效能便被節省出來了。雖然php.ini的配置初始化被節省掉了，但是我們平時使用的laravel等php開發框架中同樣有冗長的ioc容器初始化，依賴建立的過程，這個問題php-fpm就無能為力了。
那麼說完了php-fpm，這些和swoole又有什麼關係呢？相同點就在於，swoole也是常駐記憶體的，也是一個master管理多個worker程式，所以也節省掉了多次載入php.ini等配置的消耗。
並且，由於swoole本身就是一個PHP擴充套件，它的啟動是在php指令碼內開始的，因此可以看做是php開發框架的一部分，那麼php框架初始化的那一系列重複初始化便同樣被節省掉了。這便是swoole高效能的原因。
swoole在宣傳上寫的是為了解決傳統php-fpm模式併發慢的問題而誕生的，那麼就帶來一個問題：
php-fpm模式為什麼慢？
php-fpm模式是以多程式方式來執行的，一個master程式建立並管理多個work程式。master程式只負責接收請求和返回響應，剩下的執行工作交給work程式來執行。
也就是說每一個請求都對應一個work程式，同一時刻，伺服器上有多少work程式，這臺伺服器就可以處理多少的併發。
這麼一看是不是覺得php-fpm的併發能力特別差？假設不考慮伺服器配置問題，預設的400個程式數同時就只能支援400的併發。
實際情況肯定沒有這麼差，假設很多的指令碼只需要0.001秒就處理完成了，如果所有的請求都可以快速處理的話，那麼我們可以說1秒鐘的併發數就等於400*1000=40萬的併發。
這麼一看是不是覺得php-fpm的效能也沒這麼差了？
但是，如果你的業務資料量很大，mysql的查詢效率不高，每次請求都需要花費1秒鐘的時間才能返回響應的話呢？
那麼每秒鐘的併發數就從40W又下降回400了。
而swoole，就是為了解決這個問題所開發出來的一個php擴充套件，它使得每個worker程式不會因為1秒鐘的io阻塞而白白讓cpu浪費1秒鐘的效能。
swoole的執行方式
按照剛剛的那個例子來解釋的話，swoole的處理方式就是在一個worker程式開始進行mysql io查詢的時候就將這個請求任務暫時掛起，立馬開始執行下一個請求，然後等到第一個請求中的mysql io資料返回之後，再切換回第一個請求中繼續執行程式碼返回響應。這樣一來，對於cpu來說，它一直在執行程式碼，沒有因為請求中mysql的1秒io耗時處於空閒狀態。
那麼,既然那1秒的io耗時沒有對cpu產生影響，那麼對於伺服器來說，每一秒鐘的併發數和之前一樣仍然是40W，只不過由於每個請求還是有1秒的耗時，所以單個請求的響應時間依然是1秒鐘，但是對於cpu來說，它每秒處理的請求數量並沒有減少，因為對於cpu來說一個請求的io耗時是1秒，1000個請求的總耗時依舊是1秒。
同步與非同步
什麼是同步
我們平時編寫的php程式碼就是同步程式碼。php直譯器一行一行的編譯執行我們的程式碼，碰到資料庫查詢，或者第三方介面呼叫，或者系統磁碟讀寫。這些不歸php當前程式管轄的部分都是io操作，它們可能是磁碟io，可能是網路io。而同步的程式碼一旦碰到這些io操作，它們就會停下來等待，等待mysql返回查詢結果，等待第三方介面返回響應，等待linxu檔案系統返回磁碟讀取結果。在等待的過程中，cpu的效能就被浪費掉了。
什麼是非同步
非同步程式碼就是說程式碼在執行到一個需要等待的io操作時，不在原地傻等，而是繼續向下執行其他程式碼，等到io操作有返回結果通知的時候再回過頭來執行處理邏輯。
一個簡單的例子就是js中的Ajax，下面這個例子當中，js把Ajax請求傳送出去就開始執行下一行程式碼了，所以是先alert 2，然後等到Ajax響應返回再執行回撥函式alert1。
$.ajax({
url:"http://www.test.com/get_data",
success: function (result) {
alert(1);
}
});
alert(2);對於生活中的例子來說，非同步就是一個人同時使用洗衣機洗衣服與使用電飯煲做飯，假設洗衣機洗一次衣服要40分鐘，電飯煲煮飯也需要40分鐘，那麼這兩件事都完成需要多長時間呢？
是的，也是40分鐘（最多多出一些把衣服和米分別放進機器的可以忽略不計的時間），因為人把衣服放進洗衣機就可以去做其他事了，不會守在洗衣機旁傻等，可以去開電飯煲了。而洗衣機洗好衣服以後，會有滴滴聲提示人衣服已經洗好了。
回到一開始那個swoole併發數的例子，那些需要1秒鐘來查詢mysql資料的請求，它們的那1秒io操作也沒有讓cpu進行傻等，所以對於cpu來說，io操作已經無法影響它的併發數了，因為它始終在工作，並沒有浪費等待時間。
解析一下，如果使用非同步的方式，那麼會有兩個比較關鍵的點：
- 發起io操作，新增回撥函式
- 等任務完成後執行回撥函式
非同步程式設計完全沒有浪費cpu一點效能，那如果所有的io耗時操作都用非同步操作會怎麼樣呢？
瞭解node.js的朋友可能經常聽見一個詞回撥地獄。
前端開發中很少會有人在Ajax中巢狀Ajax，但是如果你想透過非同步的方式來提升程式碼的效能，那麼不可避免的，只要你的程式中有多個io操作，那它們就會向下面這段程式碼一樣變成層層巢狀，很快這段程式碼就變得不可維護了，甚至是修改的時候都會讓人十分頭疼。
login(user => {
getStatus(status => {
getOrder(order => {
getPayment(payment => {
getRecommendAdvertisements(ads => {
setTimeout(() => {
alert(ads)
}, 1000)
})
})
})
})
})
而swoole的出現，就是為了解決同步程式碼浪費效能的問題，讓同步執行的程式碼變為非同步執行，同時使用協程降低非同步回撥程式設計時的心智負擔。
cpu上下文切換
現在的電腦，一邊寫程式碼，一邊查文件，一邊聽音樂都是很常見的，因為cpu 的核心數很多可以同時做好幾件事。但是你在一開始學習for迴圈的時候一定聽老師說過，當年的單核cpu寫迴圈一定要小心，因為一旦出現死迴圈了，那麼整臺電腦都會卡死只能重啟了。
cpu在執行程式碼的時候是同步的，所以理論上來講同一時刻只能做一件事，哪怕不進行死迴圈，按理說之前的老電腦也沒辦法做到同時寫程式碼與查文件以及聽音樂這些事才對，並且就算是現在的四核八核cpu，那我也是可以同時開十幾個網頁，同時播放影片的。
讓單核cpu同時執行多工的魔法就是上下文切換了，主要的原理就是cpu在同時進行玩遊戲與播放音樂時，先執行一會遊戲，然後馬上切到音樂程式上執行一會，不斷地在這些應用之間來回切換執行，因為cpu的計算速度是遠超人腦反應時間的，所以在人類眼中，這些應用就像是在同時執行一樣。
那到底什麼是上下文呢？就是程式執行中所需要的資料，包括儲存在記憶體中的，以及cpu多級暫存器中的這些資料。線上程與程式切換的時候，需要把這些資料儲存起來，等到它們恢復執行的時候再把資料讀取回程式來執行。
本文主要是介紹swoole的，swoole的重點在於非同步與協程，為什麼要提到上下文切換呢？因為不論是多程式、多執行緒還是協程，它們本質上都需要用到上下文切換來實現的。
多程式模式，是由系統來決定每個程式的執行分片時長。而多執行緒由於它們一定有一個父級程式，所以每個執行緒的執行分片時長則是由程式來決定的。這也是為什麼多執行緒語言的教程裡都會提到不是執行緒開的越多越好的原因，多執行緒會有執行緒爭搶和系統排程的開銷。同時，由於cpu同一段時間內運算速度的總量是固定的，所以執行緒只需要儘量把cpu空閒的算力佔滿就好，開過多的執行緒反而會因為增加系統執行緒排程開銷造成業務部分執行緒效能的下降。
那麼協程與多執行緒多程式又有什麼不同呢？透過例項來對比：
- php-cgi便是多程式的一種體現，每個請求對應一個cgi程式，帶來的缺點是程式頻繁建立銷燬的開銷以及每次都需要載入php.ini配置的效能浪費。
- php-fpm多程式模式的改良，透過master/worker的模式，讓多程式少了重新載入配置與頻繁建立銷燬程式的開銷。
- 假設php有多執行緒，省略多次php.ini的載入，省略多次開發框架初始化，相應的帶來執行緒排程開銷，多執行緒搶佔式模型需要注意資料訪問的執行緒安全，需要給資料加鎖，並帶來鎖爭搶與死鎖問題。
- 協程，省略多次php.ini載入，省略多次開發框架初始化，由於協程是使用者態的執行緒，所以由程式碼來控制什麼時候進行切換，沒有執行緒排程開銷。並且swoole以同步的方式編寫非同步程式碼，協程的切換由底層排程器自行切換，開發者無需關注執行緒鎖與死鎖問題。
swoole的協程切換是基於io來排程的，也就是說它只會在遇到io操作的時候才會進行切換，透過節省io等待時間來提高伺服器效能，因此swoole的協程是無法進行併發計算的。不過遇到需要平行計算的場景，swoole也提供了多程式的執行方式，如果需要多程式協同操作同一個資料，就需要加程式鎖了。
事件迴圈–非同步是如何實現的
現在我們已經知道多程式，多執行緒，協程都是非同步的程式設計方式了，那麼非同步是怎麼實現的呢？
這是一個大問題，先從最基礎的看起，基礎非同步程式設計就是非同步回撥模式，也就是在執行任務的同時傳入一個回撥函式，等到任務執行完畢，回撥函式自然而然的就開始執行了。類似js的Ajax一樣，發起一個Ajax請求的時候便是發起了非同步任務，同時在$.ajax方法的第三個引數傳入一個匿名函式，等到後端返回響應以後再繼續執行回撥函式中的程式碼。
那麼就出現了一個問題，是誰來通知當前程式非同步任務已經完成了的呢？
做過im通訊朋友都知道，兩個客戶端的對話除了傳送訊息，最難實現的還是接收訊息，因為需要服務端主動做推送。如果不使用WebSocket的話，要實現服務端推送就只能使用長連線+輪詢的方式了。接收訊息的那一方客戶端需要每隔一段時間就請求一次伺服器，看看有沒有訊息傳送給自己。對於非同步回撥來說，它的實現方式也是有異曲同工之處。
處理非同步回撥的部分叫做事件迴圈，可以理解為每個程式有一個死迴圈，不斷的檢視當前有沒有待執行的任務、已經執行完需要通知的回撥。當我們進行非同步任務呼叫的時候，就是向這個迴圈中投遞了一個任務與對應的回撥。當任務完成的時候，迴圈便把任務從監聽陣列中去除，並執行回撥。
下面來看一個簡單的事件迴圈的例子。
可以看到，EventLoop類中維護了一個event陣列，用來儲存需所有需要監聽的事件。在呼叫addEventHandler方法時,則需要將事件的型別、引數，以及回撥函式一同傳入。
當呼叫run方法時，這個迴圈就被開啟了，可以看到run方法中是一個while死迴圈，用來不斷的檢測是否有已完成的任務。而while迴圈內層的foreach則是為了檢視所有事件中是否有已完成的單個任務。
而processTimers與processIOEvents方法則代表了swoole中典型的兩種事件，io事件與定時器。由於linux系統中萬物皆檔案的特性，很多看似是網路io的功能，其實都要用到檔案系統來實現，所以processIOEvents方法需要傳入fp檔案指標以及read與write兩種讀寫事件。例如假設我們投遞的是讀取事件，那麼就呼叫fread函式來讀取檔案，並把讀取到的資料傳遞給回撥函式來執行。這就是一個事件迴圈的回撥過程了。
<?php
class EventLoop
{
private $event_handlers = [];
public function addEventHandler($event_type, $handler)
{
$this->event_handlers[$event_type][] = $handler;
}
public function run()
{
while (true) {
foreach ($this->event_handlers as $event_type => $handlers) {
switch ($event_type) {
case 'timer':
$this->processTimers($handlers);
break;
case 'io':
$this->processIOEvents($handlers);
break;
// 可以根據需求新增更多事件型別
}
}
}
}
private function processTimers($handlers)
{
$now = time();
foreach ($handlers as $timer) {
if ($now >= $timer['time']) {
$timer['callback']();
if ($timer['interval']) {
$timer['time'] = $now + $timer['interval'];
} else {
unset($this->event_handlers['timer'][array_search($timer, $handlers)]);
}
}
}
}
private function processIOEvents($handlers)
{
foreach ($handlers as $io_event) {
$fp = $io_event['fp'];
$callback = $io_event['callback'];
$events = $io_event['events'];
$read = in_array('read', $events);
$write = in_array('write', $events);
if ($read) {
$read_data = fread($fp, 8192);
if ($read_data) {
$callback($read_data);
} else {
unset($this->event_handlers['io'][array_search($io_event, $handlers)]);
fclose($fp);
}
}
if ($write) {
$callback();
unset($this->event_handlers['io'][array_search($io_event, $handlers)]);
fclose($fp);
}
}
}
}
// 使用示例
$loop = new EventLoop();
// 新增定時器
$loop->addEventHandler('timer', [
'time' => time() + 5,
'interval' => 0,
'callback' => function () {
echo "5 seconds have passed\n";
},
]);
// 新增 IO 事件
$fp = fopen(__FILE__, 'r');
$loop->addEventHandler('io', [
'fp' => $fp,
'events' => ['read', 'write'],
'callback' => function ($read_data = null) {
if ($read_data) {
echo "read data: $read_data";
} else {
echo "io event has occurred\n";
}
},
]);
// 啟動事件迴圈
$loop->run();
在理解了時間迴圈以後，那麼事件迴圈與swoole與多程式、多執行緒、協程之間有什麼關係呢？
沒錯，無論是多程式、多執行緒還是協程，它們底層都依賴事件迴圈來實現非同步，例如程式與執行緒之間切換的時候如何通知對應的程式與執行緒？依賴系統級事件迴圈。例如協程之間多個協程的切換要如何通知對應的協程？也是依賴事件迴圈。不過swoole為了降低上下文切換帶來的消耗，沒有依賴系統級事件迴圈而是自己實現了一套，swoole的協程上下文切換都是記憶體讀取，避免了cpu暫存器、堆疊以及系統核心態與使用者態之間的切換，因此切換開銷極小。
總結
說了這麼多概念，那麼swoole到底是什麼呢？它融合了php-fpm的結構模式，最佳化了單程式的效能浪費，弱化了多執行緒的排程開銷，遮蔽了非同步回撥的複雜邏輯，是一個常駐記憶體的高效能web擴充套件。
做一個不嚴謹的類比，你也可以認為swoole是一個語言層面實現的php-fpm，畢竟swoole也支援完全的多程式模式，這種模式下與php-fpm的執行方式大同小異。不過由於在語言層面便常駐記憶體了，所以帶來的福利便是在啟動php指令碼的開發框架時，只需要一次載入便儲存在記憶體中了，避免了php-fpm每個請求都重新初始化框架的效能浪費。那麼同樣的由於服務常駐記憶體了，所以哪怕是在開發過程中，程式碼相關的改動都需要重啟一下swoole服務。
而swoole的架構，對應下面這張圖，便是master、manager、worker的結構，在swoole服務啟動時，master程式便fork出manager程式來對worker程式進行建立和管理，master程式自己則透過reactor執行緒來接受與分發請求，master程式接收到的請求透過reactor執行緒直接傳送到worker程式中，而worker程式負責對請求進行具體的處理。如果開啟了協程模式，並且程式碼也是以協程的方式執行，則一個worker可能會一段時間內(例如1s)處理多個請求。因為每個請求遇到io等待時，worker便切換協程直接開始處理下一個請求了，直到io任務返回結果，worker再切換回上一個請求將響應返回給master程式。
swoole對效能的提升帶來的代價是程式設計思維的轉變，因為常駐記憶體了，所以編寫業務程式碼時，對記憶體變數的使用就需要更加小心，避免造成記憶體洩露。因為基於非同步程式設計，所以要理解非同步的思想，避免寫出同步阻塞的程式碼。
本作品採用《CC 協議》，轉載必須註明作者和本文連結