為了更加形象的說明同步非同步、阻塞非阻塞，我們以小明去買奶茶為例。
①同步與非同步的理解
同步與非同步的重點在訊息通知的方式上，也就是呼叫結果通知的方式。非同步呼叫，要想獲得結果，一般有兩種方式：
1、主動輪詢非同步呼叫的結果;
2、被呼叫方通過callback來通知呼叫方呼叫結果。
②：生活例項
同步買奶茶：小明點單交錢，然後等著拿奶茶；
非同步買奶茶：小明點單交錢，店員給小明乙個小票，等小明奶茶做好了，再來取。
非同步買奶茶，小明要想知道奶茶是否做好了，有兩種方式：
1、小明主動去問店員，一會就去問一下：「奶茶做好了嗎？」...直到奶茶做好。
2、等奶茶做好了，店員喊一聲：「小明，奶茶好了！」，然後小明去取奶茶。
①阻塞與非阻塞的理解
阻塞與非阻塞的重點在於進/執行緒等待訊息時候的行為，也就是在等待訊息的時候，當前進/執行緒是掛起狀態，還是非掛起狀態。②：生活例項
通過上面的分析，我們可以得知：
同步與非同步，重點在於訊息通知的方式;阻塞與非阻塞，重點在於等訊息時候的行為。所以，就有了下面4種組合方式
apache處理乙個請求是同步阻塞的模式。
每到達乙個請求，apache都會去fork乙個子程序去處理這個請求，直到這個請求處理完畢。
面對低併發，這種模式沒什麼缺點，但是，面對高併發，就是這種模式的軟肋了。
下面，舉例說明這2種場景是多程序模式的軟肋：
但是，在我們呼叫外部http介面時，比如qq登入、微博登入，耗時較長，假設乙個請求消耗10s，也就是1個程序1s處理0.1個請求，那麼100個程序只能達到10qps，這樣的處理能力就未免太差了。
注：什麼是c10k問題？綜上，我們可以看出，apache是同步阻塞的多程序模式，面對高併發等一些場景，是很蒼白的。網路服務在處理數以萬計的客戶端連線時，往往出現效率低下甚至完全癱瘓，這被稱為c10k問題。（concurrent 10000 connection）
傳統的伺服器模型就是這樣，因為其同步阻塞的多程序模型，無法面對高併發。
那麼，有沒有一種方式，可以讓我們在乙個程序處理所有的併發i/o呢？
答案是有的，這就是i/o復用技術。
最初級的i/o復用
所謂的i/o復用，就是多個i/o可以復用乙個程序。
上面說的同步阻塞的多程序模型不適合處理高併發，那麼，我們再來考慮非阻塞的方式。
採用非阻塞的模式，當乙個連線過來時，我們不阻塞住，這樣乙個程序可以同時處理多個連線了。
比如乙個程序接受了10000個連線，這個程序每次從頭到尾的問一遍這10000個連線：「有i/o事件沒？有的話就交給我處理，沒有的話我一會再來問一遍。」
然後程序就一直從頭到尾問這10000個連線，如果這1000個連線都沒有i/o事件，就會造成cpu的空轉，並且效率也很低，不好不好。
公升級版的i/o復用
上面雖然實現了基礎版的i/o復用，但是效率太低了。於是偉大的程式猿們日思夜想的去解決這個問題...終於！
我們能不能引入乙個**，這個**可以同時觀察許多i/o流事件呢？
當沒有i/o事件的時候，這個程序處於阻塞狀態；當有i/o事件的時候，這個**就去通知程序醒來？
於是，早期的程式猿們發明了兩個**---select、poll。
select、poll**的原理是這樣的：
當連線有i/o流事件產生的時候，就會去喚醒程序去處理。但是程序並不知道是哪個連線產生的i/o流事件，於是程序就挨個去問：「請問是你有事要處理嗎？」......問了99999遍，哦，原來是第100000個程序有事要處理。那麼，前面這99999次就白問了，白白浪費寶貴的cpu時間片了！痛哉，惜哉...
注:select與poll原理是一樣的，只不過select只能觀察1024個連線，poll可以觀察無限個連線。
上面看了，select、poll因為不知道哪個連線有i/o流事件要處理，效能也挺不好的。
那麼，如果發明乙個**，每次能夠知道哪個連線有了i/o流事件，不就可以避免無意義的空轉了嗎？
於是，超級無敵、閃閃發光的epoll被偉大的程式設計師發明出來了。
epoll**的原理是這樣的：
當連線有i/o流事件產生的時候，epoll就會去告訴程序哪個連線有i/o流事件產生，然後程序就去處理這個程序。如此，多高效！
有了epoll，理論上1個程序就可以無限數量的連線，而且無需輪詢，真正解決了c10k的問題。
nginx是基於epoll的，非同步非阻塞的伺服器程式。自然，nginx能夠輕鬆處理百萬級的併發連線，也就無可厚非了。
swoole是php的乙個擴充套件。
簡單理解：swoole=非同步i/o+網路通訊
phper可以基於swoole去實現過去php無法實現的功能。
具體請參考swoole官網：swoole官網
io復用非同步非阻塞程式使用經典的reactor模型，reactor顧名思義就是反應堆的意思，它本身不處理任何資料收發。只是可以監視乙個socket(也可以是管道、eventfd、訊號)控制代碼的事件變化。
注:什麼是控制代碼？控制代碼英文為handler，可以形象的比喻為鍋柄、勺柄。也就是資源的唯一識別符號、資源的id。通過這個id可以操作資源。reactor只是乙個事件發生器，實際對socket控制代碼的操作，如connect/accept、send/recv、close是在callback中完成的。swoole採用多執行緒reactor+多程序worker
swoole的架構圖如下：
swoole的處理連線流程圖如下：
當請求到達時,swoole是這樣處理的：
因為reactor基於epoll，所以每個reactor可以處理無數個連線請求。請求到達 main reactor||main reactor根據reactor的情況，將請求註冊給對應的reactor
(每個reactor都有epoll。用來監聽客戶端的變化)||
客戶端有變化時，交給worker來處理||
worker處理完畢，通過程序間通訊(比如管道、共享記憶體、訊息佇列)發給對應的reactor。||
reactor將響應結果發給相應的連線||
請求處理完成
如此，swoole就輕鬆的處理了高併發。
基於上面的swoole結構圖，我們看到swoole的worker程序有2種型別：
一種是 普通的worker程序，一種是 task worker程序。
worker程序是用來處理普通的耗時不是太長的請求；
task worker程序用來處理耗時較長的請求，比如資料庫的i/o操作。
我們以非同步mysql舉例：
如此，通過worker、task worker結合的方式，我們就實現了非同步i/o。耗時較長的mysql查詢進入worker||worker通過管道將這個請求交給taskworker來處理||
worker再去處理其他請求||
task worker處理完畢後，處理結果通過管道返回給worker||
worker 將結果返回給reactor||
reactor將結果返回給請求方
高併發 高可用
高併發 提高系統併發能力的方法主要有兩種 前者垂直擴充套件可以通過提公升單機硬體效能，或者提公升單機架構效能，來提高併發性，但單機效能總是有極限的，網際網路分布式架構設計高併發終極解決方案還是後者 水平擴充套件。網際網路分層架構中，各層次水平擴充套件的實踐又有所不同 1 反向 層可以通過 dns輪詢...
高併發 高併發測試筆記
問 高併發測試 一般你們用什麼工具來模擬 10萬級別的客戶端併發？在普通的電腦上可以模擬嗎 10萬併發需要至少10萬的套接字，套接字在核心中占用記憶體100000 6k 2 1g記憶體，系統需要能夠開啟10w個fd。一般的系統能夠能模擬 問 預設每個程序只能開1024個fd，修改後最大可以10w，那...
併發與高併發（二十）高併發 應用拆分思路
這一章節我們將講解高併發解決方案中的應用拆分思路，也可以稱之為系統拆分。單個伺服器再優化，它的處理都是有上限的，因此我們採用擴容 快取 訊息佇列等對程式進行優化，這些手段都可行，但還不是全部。隨著專案的需求要求越來越多，應用自然會跟著越來越大，因此呢，架構師設計出了特別容易擴充套件的方案，從整體將乙...