3、高效的事件處理模式reactor 模式
1、傳統架構php-fpm 程序模型
屬於預派生子程序模型，來乙個請求就 fork(復刻) 乙個子程序來處理，程序的開銷比較大。程式啟動後就會建立n個程序。每個子程序進入accept，等待新的連線進入。當客戶端連線到伺服器時，其中乙個子程序會被喚醒，開始處理客戶端請求，並且不再接受新的tcp連線。當此連線關閉時，子程序會釋放，重新進入accept，參與處理新的連線。（通俗來說，就是提前安排好了固定的數量的子程序來處理）
缺點：這種模型嚴重依賴程序的數量解決併發問題，乙個客戶端連線就需要占用乙個程序，工作程序的數量有多少，併發處理能力就有多少。
作業系統可以建立的程序數量是有限的。
php框架初始化會占用大量的計算資源，每個請求都需要初始化。
啟動大量程序會帶來額外的程序排程消耗。數百個程序時可能程序上下文切換排程消耗佔cpu不到1%可以忽略不計，如果啟動數千甚至數萬個程序，消耗就會直線上公升。排程消耗可能佔到 cpu 的百分之幾十甚至 100%。
如果請求乙個第三方請求非常慢，請求過程中會一直占用 cpu 資源，浪費了昂貴的硬體資源
2、io 多路復用
這的復用指的是復用的執行緒，其實io復用的歷史和多程序一樣長。linux很早就提供了 select 系統呼叫，可以在乙個程序內維持1024個連線。
後來又加入了poll系統呼叫，poll做了一些改進，解決了 1024 限制的問題，可以維持任意數量的連線。
但select/poll還有乙個問題就是，它需要迴圈檢測連線是否有事件。
這樣問題就來了，如果伺服器有100萬個連線，在某一時間只有乙個連線向伺服器傳送了資料，select/poll需要做迴圈100萬次，其中只有1次是命中的，剩下的99萬9999次都是無效的，白白浪費了cpu資源。
（2）epoll
直到linux 2.6核心提供了新的epoll系統呼叫，可以維持無限數量的連線，而且無需輪詢，這才真正解決了 c10k 問題。現在各種高併發非同步io的伺服器程式都是基於epoll實現的，比如nginx、node.js、erlang、golang。像 node.js，redis 這樣單程序單執行緒的程式，都可以維持超過1百萬tcp連線，全部歸功於epoll技術。
在這就不得不提，基於 epoll 實現的 reacter 模型，io復用非同步非阻塞程式使用經典的reactor模型，reactor顧名思義就是反應堆的意思，它本身不處理任何資料收發。只是可以監視乙個socket控制代碼的事件變化。
3、高效的事件處理模式reactor 模式
主程序/執行緒往epoll核心亊件中註冊socket上的讀就緒亊件。
主程序/執行緒呼叫epoll_wait等待socket上有資料可讀。
當socket上有資料可讀時，epoll_wait通知主程序/執行緒。主程序/執行緒則將socket可讀事件放人請求佇列。
睡眠在請求佇列上的某個工作執行緒被喚醒，它從socket讀取資料，並處理客戶請求， 然後往epoll核心爭件表中註冊該socket上的寫就緒事件。
主線程呼叫epoll_wait等待socket可寫。
當socket可寫時，epoll_wait通知主程序/執行緒主程序/執行緒將socket可寫事件放人清求佇列。
睡眠在請求佇列上的某個工作執行緒被喚醒，它往socket上寫人伺服器處理客戶淸求
swoole 的 reacter 執行緒 也是基於 reacter 模型實現的
第8章節 程序控制
1.每乙個程序都有唯一的乙個非負整數程序id 2.核心態 程序呼叫了系統api 注意不是標準庫函式 正在執行核心 的狀態 使用者態 正在執行的是使用者編寫的 狀態 3.核心自舉 自舉是指上電自檢，即核心檢查硬體平台都擁有什麼硬體，為硬體載入驅動，最終載入根文 件系統並執行第乙個程序。程序id 1的程...
C primer 第8章節 函式探幽
1.內聯函式比一般的函式執行速度要稍快，但是代價是需要付出更多的記憶體。如果程式在10個地方呼叫同乙個內聯函式，那麼該程式將包含該程式的10個副本。2.使用內聯函式，可以有三種方法 1 在函式宣告的時候，加上關鍵字inline.2 在函式定義的時候，加上關鍵字inline.3 類中實現的函式，將自動...
第8節 C 檔案的直接讀寫
檔案流技術 1 查詢計算機所有的可用編碼。2 直接讀取資料檔案。3 直接寫入資料檔案。using system using system.collections.generic using system.io using system.text namespace io目錄管理 displaynam...