本文轉自:https://www.jianshu.com/p/ba7fa25d3590
C10K問題由來
隨著互聯網的普及，應用的用戶群體幾何倍增長，此時服務器性能問題就出現。最初的服務器是基于進程/線程模型。新到來一個TCP連接，就需要分配一個進程。假如有C10K，就需要創建1W個進程，可想而知單機是無法承受的。那么如何突破單機性能是高性能網絡編程必須要面對的問題，進而這些局限和問題就統稱為C10K問題，最早是由Dan Kegel進行歸納和總結的，并且他也系統的分析和提出解決方案。
C10K問題的本質
C10K問題的本質上是操作系統的問題。對于Web 1.0/2.0時代的操作系統，傳統的同步阻塞I/O模型處理方式都是requests per second。當創建的進程或線程多了，數據拷貝頻繁（緩存I/O、內核將數據拷貝到用戶進程空間、阻塞，進程/線程上下文切換消耗大， 導致操作系統崩潰，這就是C10K問題的本質。
可見, 解決C10K問題的關鍵就是盡可能減少這些CPU資源消耗。
C10K問題的解決方案
從網絡編程技術的角度來說，主要思路：
- 每個連接分配一個獨立的線程/進程
- 同一個線程/進程同時處理多個連接
每個進程/線程處理一個連接
該思路最為直接，但是申請進程/線程是需要系統資源的，且系統需要管理這些進程/線程，所以會使資源占用過多，可擴展性差
每個進程/線程同時處理 多個連接(I/O多路復用)
- select方式：使用fd_set結構體告訴內核同時監控那些文件句柄，使用逐個排查方式去檢查是否有文件句柄就緒或者超時。該方式有以下缺點：文件句柄數量是有上線的，逐個檢查吞吐量低，每次調用都要重復初始化fd_set。
- poll方式：該方式主要解決了select方式的2個缺點，文件句柄上限問題(鏈表方式存儲)以及重復初始化問題(不同字段標注關注事件和發生事件)，但是逐個去檢查文件句柄是否就緒的問題仍然沒有解決。
- epoll方式：該方式可以說是C10K問題的killer，他不去輪詢監聽所有文件句柄是否已經就緒。epoll只對發生變化的文件句柄感興趣。其工作機制是，使用"事件"的就緒通知方式，通過epoll_ctl注冊文件描述符fd，一旦該fd就緒，內核就會采用類似callback的回調機制來激活該fd, epoll_wait便可以收到通知, 并通知應用程序。而且epoll使用一個文件描述符管理多個描述符,將用戶進程的文件描述符的事件存放到內核的一個事件表中, 這樣數據只需要從內核緩存空間拷貝一次到用戶進程地址空間。而且epoll是通過內核與用戶空間共享內存方式來實現事件就緒消息傳遞的，其效率非常高。但是epoll是依賴系統的(Linux)。
- 異步I/O以及Windows，該方式在windows上支持很好，這里就不具體介紹啦。
參考：
- 構建C1000K的服務器(1) – 基礎
- 高性能網絡編程(二)：上一個10年，著名的C10K并發連接問題
