C10K問題及解決方案

轉載自：http://blog.csdn.net/wangtaomtk/article/details/51811011

1 C10K問題

你們都知道互聯網的基礎就是網絡通訊，早期的互聯網能夠說是一個小羣體的集合。互聯網還不夠普及，用戶也很少。一臺服務器同時在線100個用戶估計在當時已經算是大型應用了。因此並不存在什麼C10K的難題。互聯網的爆發期應該是在www網站，瀏覽器，雅虎出現後。最先的互聯網稱之爲Web1.0，互聯網大部分的使用場景是下載一個Html頁面，用戶在瀏覽器中查看網頁上的信息。這個時期也不存在C10K問題。

Web2.0時代到來後就不一樣了，一方面是普及率大大提升了，用戶羣體幾何倍增加。另外一方面是互聯網再也不是單純的瀏覽萬維網網頁，逐漸開始進行交互，並且應用程序的邏輯也變的更復雜，從簡單的表單提交，到即時通訊和在線實時互動。C10K的問題才體現出來了。每個用戶都必須與服務器保持TCP鏈接才能進行實時的數據交互。Facebook這樣的網站同一時間的併發TCP鏈接可能會過億。

騰訊QQ也是有C10K問題的，只不過他們是用了UDP這種原始的包交換協議來實現的，繞開了這個難題。固然過程確定是痛苦的。若是當時有epoll技術，他們確定會用TCP。後來的手機QQ，微信都採用TCP協議。

這時候問題就來了，最初的服務器都是基於進程/線程模型的，新到來一個TCP鏈接，就須要分配1個進程（或者線程）。而進程又是操做系統最昂貴的資源，一臺機器沒法建立不少進程。若是是C10K就要建立1萬個進程，那麼操做系統是沒法承受的。若是是採用分佈式系統，維持1億用戶在線須要10萬臺服務器，成本巨大，也只有Facebook，Google，雅虎纔有財力購買如此多的服務器。這就是C10K問題的本質。

實際上當時也有異步模式，如：select/poll模型，這些技術都有必定的缺點，如selelct最大不能超過1024，poll沒有限制，但每次收到數據須要遍歷每個鏈接查看哪一個鏈接有數據請求。

2 解決方案

解決這一問題，主要思路有兩個：一個是對於每一個鏈接處理分配一個獨立的進程/線程；另外一個思路是用同一進程/線程來同時處理若干鏈接。

2.1 每一個進程/線程處理一個鏈接

這一思路最爲直接。可是因爲申請進程/線程會佔用至關可觀的系統資源，同時對於多進程/線程的管理會對系統形成壓力，所以這種方案不具有良好的可擴展性。

所以，這一思路在服務器資源尚未富裕到足夠程度的時候，是不可行的；即使資源足夠富裕，效率也不夠高。

問題：資源佔用過多，可擴展性差。

2.2 每一個進程/線程同時處理多個鏈接（IO多路複用）

1. 傳統思路

   最簡單的方法是循環挨個處理各個鏈接，每一個鏈接對應一個 socket，當全部 socket 都有數據的時候，這種方法是可行的。

   可是當應用讀取某個 socket 的文件數據不 ready 的時候，整個應用會阻塞在這裏等待該文件句柄，即便別的文件句柄 ready，也沒法往下處理。

   思路：直接循環處理多個鏈接。

   問題：任一文件句柄的不成功會阻塞住整個應用。

2. select

   要解決上面阻塞的問題，思路很簡單，若是我在讀取文件句柄以前，先查下它的狀態，ready 了就進行處理，不 ready 就不進行處理，這不就解決了這個問題了嘛？

   因而有了 select 方案。用一個 fd_set 結構體來告訴內核同時監控多個文件句柄，當其中有文件句柄的狀態發生指定變化（例如某句柄由不可用變爲可用）或超時，則調用返回。以後應用能夠使用 FD_ISSET 來逐個查看是哪一個文件句柄的狀態發生了變化。

   這樣作，小規模的鏈接問題不大，但當鏈接數不少（文件句柄個數不少）的時候，逐個檢查狀態就很慢了。所以，select 每每存在管理的句柄上限（FD_SETSIZE）。同時，在使用上，由於只有一個字段記錄關注和發生事件，每次調用以前要從新初始化 fd_set 結構體。

   int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout); 

   思路：有鏈接請求抵達了再檢查處理。

   問題：句柄上限+重複初始化+逐個排查全部文件句柄狀態效率不高。

3. poll

   poll 主要解決 select 的前兩個問題：經過一個 pollfd 數組向內核傳遞須要關注的事件消除文件句柄上限，同時使用不一樣字段分別標註關注事件和發生事件，來避免重複初始化。

   int poll(struct pollfd *fds, nfds_t nfds, int timeout); 

   思路：設計新的數據結構提供使用效率。

   問題：逐個排查全部文件句柄狀態效率不高。

4. epoll

   既然逐個排查全部文件句柄狀態效率不高，很天然的，若是調用返回的時候只給應用提供發生了狀態變化（極可能是數據 ready）的文件句柄，進行排查的效率不就高多了麼。

   epoll 採用了這種設計，適用於大規模的應用場景。

   實驗代表，當文件句柄數目超過 10 以後，epoll 性能將優於 select 和 poll；當文件句柄數目達到 10K 的時候，epoll 已經超過 select 和 poll 兩個數量級。

   int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout); 

   思路：只返回狀態變化的文件句柄。

   問題：依賴特定平臺（Linux）。

   由於Linux是互聯網企業中使用率最高的操做系統，Epoll就成爲C10K killer、高併發、高性能、異步非阻塞這些技術的代名詞了。FreeBSD推出了kqueue，Linux推出了epoll，Windows推出了IOCP，Solaris推出了/dev/poll。這些操做系統提供的功能就是爲了解決C10K問題。epoll技術的編程模型就是異步非阻塞回調，也能夠叫作Reactor，事件驅動，事件輪循（EventLoop）。Nginx，libevent，Node.js這些就是Epoll時代的產物。

   select、poll、epoll具體原理詳解，請參見：《聊聊IO多路複用之select、poll、epoll詳解》。

5. libevent

   因爲epoll, kqueue, IOCP每一個接口都有本身的特色，程序移植很是困難，因而須要對這些接口進行封裝，以讓它們易於使用和移植，其中libevent庫就是其中之一。跨平臺，封裝底層平臺的調用，提供統一的 API，但底層在不一樣平臺上自動選擇合適的調用。

   按照libevent的官方網站，libevent庫提供瞭如下功能：當一個文件描述符的特定事件（如可讀，可寫或出錯）發生了，或一個定時事件發生了，libevent就會自動執行用戶指定的回調函數，來處理事件。目前，libevent已支持如下接口/dev/poll, kqueue, event ports, select, poll 和 epoll。Libevent的內部事件機制徹底是基於所使用的接口的。所以libevent很是容易移植，也使它的擴展性很是容易。目前，libevent已在如下操做系統中編譯經過：Linux，BSD，Mac OS X，Solaris和Windows。

   使用libevent庫進行開發很是簡單，也很容易在各類unix平臺上移植。一個簡單的使用libevent庫的程序以下：

3 協程（coroutine）

隨着技術的演進，epoll 已經能夠較好的處理 C10K 問題，可是若是要進一步的擴展，例如支持 10M 規模的併發鏈接，原有的技術就無能爲力了。

那麼，新的瓶頸在哪裏呢？

從前面的演化過程當中，咱們能夠看到，根本的思路是要高效的去阻塞，讓 CPU 能夠幹核心的任務。因此，千萬級併發實現的祕密：內核不是解決方案，而是問題所在！

這意味着：

不要讓內核執行全部繁重的任務。將數據包處理，內存管理，處理器調度等任務從內核轉移到應用程序高效地完成。讓Linux只處理控制層，數據層徹底交給應用程序來處理。

當鏈接不少時，首先須要大量的進程/線程來作事。同時系統中的應用進程/線程們可能大量的都處於 ready 狀態，須要系統去不斷的進行快速切換，而咱們知道系統上下文的切換是有代價的。雖然如今 Linux 系統的調度算法已經設計的很高效了，但對於 10M 這樣大規模的場景仍然力有不足。

因此咱們面臨的瓶頸有兩個，一個是進程/線程做爲處理單元仍是太厚重了；另外一個是系統調度的代價過高了。

很天然地，咱們會想到，若是有一種更輕量級的進程/線程做爲處理單元，並且它們的調度能夠作到很快（最好不須要鎖），那就完美了。

這樣的技術如今在某些語言中已經有了一些實現，它們就是 coroutine（協程），或協做式例程。具體的，Python、Lua 語言中的 coroutine（協程）模型，Go 語言中的 goroutine（Go 程）模型，都是相似的一個概念。實際上，多種語言（甚至 C 語言）均可以實現相似的模型。

它們在實現上都是試圖用一組少許的線程來實現多個任務，一旦某個任務阻塞，則可能用同一線程繼續運行其餘任務，避免大量上下文的切換。每一個協程所獨佔的系統資源每每只有棧部分。並且，各個協程之間的切換，每每是用戶經過代碼來顯式指定的（跟各類 callback 相似），不須要內核參與，能夠很方便的實現異步。

這個技術本質上也是異步非阻塞技術，它是將事件回調進行了包裝，讓程序員看不到裏面的事件循環。程序員就像寫阻塞代碼同樣簡單。好比調用 client->recv() 等待接收數據時，就像阻塞代碼同樣寫。其實是底層庫在執行recv時悄悄保存了一個狀態，好比代碼行數，局部變量的值。而後就跳回到EventLoop中了。何時真的數據到來時，它再把剛纔保存的代碼行數，局部變量值取出來，又開始繼續執行。

這就是協程的本質。協程是異步非阻塞的另一種展示形式。Golang，Erlang，Lua協程都是這個模型。

3.1 同步阻塞

不知道你們看完協程是否感受獲得，實際上協程和同步阻塞是同樣的。答案是的。因此協程也叫作用戶態進/用戶態線程。區別就在於進程/線程是操做系統充當了EventLoop調度，而協程是本身用Epoll進行調度。

協程的優勢是它比系統線程開銷小，缺點是若是其中一個協程中有密集計算，其餘的協程就不運行了。操做系統進程的缺點是開銷大，優勢是不管代碼怎麼寫，全部進程均可以併發運行。

Erlang解決了協程密集計算的問題，它基於自行開發VM，並不執行機器碼。即便存在密集計算的場景，VM發現某個協程執行時間過長，也能夠進行停止切換。Golang因爲是直接執行機器碼的，因此沒法解決此問題。因此Golang要求用戶必須在密集計算的代碼中，自行Yield。

實際上同步阻塞程序的性能並不差，它的效率很高，不會浪費資源。當進程發生阻塞後，操做系統會將它掛起，不會分配CPU。直到數據到達纔會分配CPU。多進程只是開多了以後反作用太大，由於進程多了互相切換有開銷。因此若是一個服務器程序只有1000左右的併發鏈接，同步阻塞模式是最好的。

3.2 異步回調和協程哪一個性能好

協程雖然是用戶態調度，實際上仍是須要調度的，既然調度就會存在上下文切換。因此協程雖然比操做系統進程性能要好，但總仍是有額外消耗的。而異步回調是沒有切換開銷的，它等同於順序執行代碼。因此異步回調程序的性能是要優於協程模型的。