前言

一臺(tái)服務(wù)器并發(fā)TCP連接數(shù)可以有多少?

如何支持從硬件和操作系統(tǒng)上支持單臺(tái)服務(wù)器支持上萬并發(fā)，支持百萬千萬，甚至上億的并發(fā)

著名的C10K并發(fā)連接問題是什么？C10M并發(fā)問題又是什么？

接下來我們逐一的介紹說明

服務(wù)器支持的并發(fā)

在linux下編程，網(wǎng)絡(luò)服務(wù)器程序我們都知道每一個(gè)TCP連接都要占用一個(gè)文件描述符，一旦這個(gè)文件描述符使用完了，新的連接到就返回錯(cuò)誤“Socket/File:Can't open so many files”

也就是，我們需要明白操作系統(tǒng)對(duì)可以打開的最大文件數(shù)的限制

進(jìn)程限制

執(zhí)行命令 ulimit -n 輸出256，說明對(duì)于一個(gè)進(jìn)程最多打開256個(gè)文件，所以如果采用默認(rèn)的配置最多也就是200多個(gè)并發(fā)，那么就要修改ulimit打開文件的限制，在/etc/rc.local文件最后，添加ulimt -SHn 100000，這樣就支持一個(gè)進(jìn)程打開10萬個(gè)文件，理論并發(fā)是10萬

全局限制

執(zhí)行命令cat /proc/sys/fs/file-nr輸出9344 0 592026分別為：

已經(jīng)分配的文件句柄數(shù)，已經(jīng)分配但是還沒有使用的文件句柄，最大文件句柄數(shù)

我們可以把這個(gè)數(shù)值改大些，用 root 權(quán)限修改 /etc/sysctl.conf 文件:

fs.file-max = 1000000
net.ipv4.ip_conntrack_max = 1000000
net.ipv4.netfilter.ip_conntrack_max = 1000000

端口范圍限制

端口的范圍0-65535，其中1024以下是系統(tǒng)使用的，從1024-65535是給用戶使用的，由于一個(gè)TCP連接都要占用一個(gè)端口號(hào)，所以我們最多可有60000多個(gè)并發(fā)，其實(shí)這樣理解的朋友應(yīng)該不在少數(shù)，這是一個(gè)錯(cuò)誤的理解

如何標(biāo)識(shí)一個(gè)TCP連接

系統(tǒng)用一個(gè)4元數(shù)組來表示唯一的一個(gè)連接{local ip,local port,remote ip,remote port}，作為服務(wù)器端只使用了bind時(shí)的這個(gè)端口，也就是說，不同的進(jìn)程，不同的remote IP 都有不同的端口來對(duì)應(yīng)

Server最大TCP連接數(shù)

server通常固定在某個(gè)本地端口上監(jiān)聽，等待client連接請(qǐng)求，即使sever端有很多的IP，本地監(jiān)聽端口也是獨(dú)占的，因此server端tcp的四個(gè)元組只有remote ip 和 remote port 是可變的，因此最大的TCP連接為客戶端的IP x 客戶端的port數(shù)，最大的TCP連接數(shù)約為2^32次方（IP數(shù)）x 2^16次方（port數(shù)），也就是說server端單擊最大tcp連接數(shù)約為2^48次方

結(jié)論

單個(gè)機(jī)器理論TCP并發(fā)連接數(shù)有這么多，但是實(shí)際上并發(fā)連接肯定受硬件資源（內(nèi)存），網(wǎng)絡(luò)資源（帶寬）的限制，那么如何計(jì)算內(nèi)存和帶寬呢？

假設(shè)一個(gè)請(qǐng)求（UDP）大小按照548個(gè)字節(jié)計(jì)算，內(nèi)存4G，帶寬按照5M獨(dú)立帶寬計(jì)算，那么理論并發(fā)X為：

一個(gè)UDP的長(zhǎng)度在Internet上大約是548個(gè)字節(jié)，理論長(zhǎng)度65535個(gè)字節(jié)，我們計(jì)算暫時(shí)按照548個(gè)字節(jié)

x * 548 < 內(nèi)存大小, 并且還得小于帶寬大小

計(jì)算的結(jié)果：5M帶寬，理論并發(fā)在9000左右

在目前大部分計(jì)算機(jī)的計(jì)算能力以及分布式架構(gòu)來說，并發(fā)的最大瓶頸還是帶寬的能力

C10K問題，單機(jī)支持1萬個(gè)并發(fā)連接問題

在互聯(lián)網(wǎng)web1.0的時(shí)代，互聯(lián)網(wǎng)大部分使用場(chǎng)景下載一個(gè)html頁(yè)面，用戶在瀏覽器上查看網(wǎng)頁(yè)信息，這個(gè)時(shí)期不存在C10K的問題

隨著web2.0的時(shí)代到來，用戶群體幾何倍數(shù)增長(zhǎng)，也不再是單純的瀏覽網(wǎng)頁(yè)，逐漸的開始進(jìn)行交互，從簡(jiǎn)單的表達(dá)提交，到即時(shí)通訊和在線實(shí)時(shí)互動(dòng)，因?yàn)槊總€(gè)用戶都需要和服務(wù)器保持TCP連接才能進(jìn)行數(shù)據(jù)實(shí)時(shí)交互，就像騰訊這樣的網(wǎng)站同一個(gè)時(shí)間的并發(fā)TCP連接可能就過億

早期的騰訊QQ采用了UDP的這種原始包交換協(xié)議來實(shí)現(xiàn)的，繞開了C10K的難題，當(dāng)然了這個(gè)過程肯定是痛苦的，如果當(dāng)時(shí)有epoll技術(shù)，他們肯定用TCP，眾所周知，后臺(tái)的手機(jī)QQ，微信都采用了TCP協(xié)議和UDP協(xié)議的配合

實(shí)際上，當(dāng)時(shí)也有異步模式，如select/poll模型，這些技術(shù)都有一定的缺點(diǎn)，如select最大不能超過1024，poll沒有限制，但是每次收到的數(shù)據(jù)都需要遍歷每一個(gè)連接查看是哪個(gè)連接有數(shù)據(jù)請(qǐng)求

最初的服務(wù)器都是基于進(jìn)程/線程模型的，新連接一個(gè)TCP連接，就需要分配一個(gè)1個(gè)進(jìn)程，而進(jìn)程又是操作系統(tǒng)最昂貴的資源，一臺(tái)機(jī)器無法創(chuàng)建很多進(jìn)程，如果是C10K就要?jiǎng)?chuàng)建1萬個(gè)進(jìn)程，那么對(duì)于單機(jī)操作系統(tǒng)而言是無法承受的（效率低下，甚至完全癱瘓），如果采用分布式系統(tǒng)，維持1億用戶在線需要10萬臺(tái)服務(wù)器成本巨大

那么如何突破單機(jī)性能的局限，這是網(wǎng)絡(luò)編程最直接要面臨的問題

C10K

在之前的舊服務(wù)器上基于select的程序處理1000個(gè)并發(fā)吞吐量，在2倍性能的機(jī)器上往往是處理不了2000個(gè)并發(fā)的，大量的操作消耗和當(dāng)前的連接數(shù)N成線性關(guān)系，大量的操作和消耗和當(dāng)前的連接數(shù)N成線性關(guān)系，會(huì)導(dǎo)致單個(gè)任務(wù)的資源消耗和當(dāng)前的連接數(shù)的關(guān)系是0(n)，而服務(wù)程序同時(shí)需要數(shù)萬計(jì)的socket進(jìn)行I/0處理，積累下的資源消耗會(huì)相對(duì)的可觀，這顯然會(huì)導(dǎo)致系統(tǒng)吞吐量不能和機(jī)器性能匹配

C10K最大的特點(diǎn)是，解決了其性能和連接及機(jī)器性能的關(guān)系是非線性的

一些沒有太多大并發(fā)的實(shí)踐經(jīng)驗(yàn)的技術(shù)同行，所實(shí)現(xiàn)的諸如IM及時(shí)通信，所謂的理論負(fù)載動(dòng)不動(dòng)就號(hào)稱單機(jī)支持上萬，上十萬甚至上百萬的情況，是經(jīng)不起考驗(yàn)的

C10K的本質(zhì)問題

是操作系統(tǒng)的問題，傳統(tǒng)的同步阻塞I/0模式都是一樣的，處理的方式都是requests per second，并發(fā)10K和100的區(qū)別關(guān)鍵在于CPU

創(chuàng)建的進(jìn)程線程多了，數(shù)據(jù)拷貝頻繁（緩存I/O，內(nèi)核將數(shù)據(jù)拷貝到用戶進(jìn)程空間，阻塞），進(jìn)程/線程上下文切換消耗巨大，導(dǎo)致操作系統(tǒng)崩潰，這就是C10K的本質(zhì)問題

解決C10K問題的關(guān)鍵就是：盡可能的減少這些CPU等核心的計(jì)算資源消耗，從而榨干單臺(tái)服務(wù)器的性能，突破C10K的關(guān)鍵問題

C10K問題的解決方案

主要思路有2個(gè)

思路一：一個(gè)是對(duì)應(yīng)每一個(gè)連接處理分配一個(gè)獨(dú)立的進(jìn)程/線程

思路二：另外一個(gè)思路是用同一個(gè)進(jìn)程/線程同時(shí)處理若干個(gè)連接

思路一的擴(kuò)展性差，占用資源過多，是最老的一種服務(wù)器連接處理的方式，我們暫時(shí)忽略，直接說第二種的思路

一個(gè)進(jìn)程/線程處理多個(gè)連接（IO多路復(fù)用）

IO復(fù)用從技術(shù)實(shí)現(xiàn)上分很多種，接下來依次說明各個(gè)方式的實(shí)現(xiàn)和優(yōu)劣：

方式1：傳統(tǒng)思路最簡(jiǎn)單的方式，循環(huán)挨個(gè)處理各個(gè)連接，每個(gè)連接對(duì)應(yīng)一個(gè)socket，當(dāng)所有的socket都有數(shù)據(jù)的時(shí)候，這種方法是可行的，但是當(dāng)應(yīng)用讀取某一個(gè)socket的文件數(shù)據(jù)不ready的時(shí)候，整個(gè)應(yīng)用會(huì)阻塞在這里等待該文件的句柄，即使別的文件句柄ready，也無法往下處理
- - 直接循環(huán)處理多個(gè)連接
  - 任一文件句柄的不成功，并不會(huì)阻塞整個(gè)應(yīng)用

方式2：select方案解決阻塞的問題，思路是如果在讀取文件句柄之前，先查下一下他的狀態(tài)，ready了就進(jìn)行處理，否則就不進(jìn)行處理，于是有了select方案
- - 有連接請(qǐng)求抵達(dá)在檢查處理
  - 句柄上限+重復(fù)初始化+逐個(gè)排查所有文件的句柄狀態(tài)效率不高

方式3：poll主要解決了select的前的2個(gè)問題，通過一個(gè)follfd數(shù)組向內(nèi)核傳遞需要關(guān)注的事件消除文件句柄上限，同時(shí)使用不同字段分別標(biāo)注關(guān)注的事件和發(fā)生事件，來避免重復(fù)初始化
- - 設(shè)計(jì)新的數(shù)據(jù)結(jié)果提高使用效率
  - 逐個(gè)排查所有文件句柄的狀態(tài)效率不高

方式4：epoll既然逐個(gè)排查所有文件句柄狀態(tài)效率不高，如果調(diào)用返回的時(shí)候只給應(yīng)用提供發(fā)生了狀態(tài)變化（很可能數(shù)據(jù)ready）的文件句柄，進(jìn)行排查的效率不就高了嗎，epoll采用了這種設(shè)計(jì)，適用于大規(guī)模的應(yīng)用場(chǎng)景，當(dāng)文件句柄數(shù)目超過10之后，epoll性能就優(yōu)于select和poll，當(dāng)文件句柄達(dá)到10K的時(shí)候，epoll就是另外一個(gè)數(shù)量級(jí)
- - 只返回狀態(tài)變化的文件句柄
  - 依賴特定的平臺(tái)（Linux）

方式5：由于epoll, kqueue, IOCP每個(gè)接口都有自己的特點(diǎn)，程序移植非常困難，于是需要對(duì)這些接口進(jìn)行封裝，以讓它們易于使用和移植，其中l(wèi)ibevent庫(kù)就是其中之一。跨平臺(tái)，封裝底層平臺(tái)的調(diào)用，提供統(tǒng)一的 API，但底層在不同平臺(tái)上自動(dòng)選擇合適的調(diào)用。按照libevent的官方網(wǎng)站，libevent庫(kù)提供了以下功能：當(dāng)一個(gè)文件描述符的特定事件（如可讀，可寫或出錯(cuò)）發(fā)生了，或一個(gè)定時(shí)事件發(fā)生了，libevent就會(huì)自動(dòng)執(zhí)行用戶指定的回調(diào)函數(shù)，來處理事件。目前，libevent已支持以下接口/dev/poll, kqueue, event ports, select, poll 和 epoll。Libevent的內(nèi)部事件機(jī)制完全是基于所使用的接口的。因此libevent非常容易移植，也使它的擴(kuò)展性非常容易。目前，libevent已在以下操作系統(tǒng)中編譯通過：Linux，BSD，mac OS X，Solaris和windows。使用libevent庫(kù)進(jìn)行開發(fā)非常簡(jiǎn)單，也很容易在各種unix平臺(tái)上移植。一個(gè)簡(jiǎn)單的使用libevent庫(kù)的程序如下：

C10M問題，單機(jī)支持1000萬個(gè)并發(fā)連接問題

截止目前，40gpbs、32-cores、256G RAM的X86服務(wù)器在Newegg網(wǎng)站上的報(bào)價(jià)是幾千美元，實(shí)際上這樣的配置，它完全可以處理1千萬個(gè)以上的并發(fā)連接

在未來IPV6協(xié)議下，每個(gè)服務(wù)器的潛在連接數(shù)據(jù)都是百萬級(jí)，單個(gè)服務(wù)器處理數(shù)百萬的并發(fā)甚至上千萬的并發(fā)

不要讓OS內(nèi)核執(zhí)行所有的繁重任務(wù)，將數(shù)據(jù)包處理，內(nèi)存管理，處理器調(diào)度等任務(wù)從內(nèi)核轉(zhuǎn)移到應(yīng)用程序高效的完成，諸如讓linux這樣的OS只處理控制層，數(shù)據(jù)層完全交給應(yīng)用程序來處理

面向數(shù)據(jù)層的系統(tǒng)可以每秒處理1千萬個(gè)數(shù)據(jù)包，面向控制層的系統(tǒng)，每秒只能處理1百萬個(gè)數(shù)據(jù)包，這雖然是很極端的，但是可擴(kuò)展性是專業(yè)化，為了做好這些事情，不能把性能問題外部給操作系統(tǒng)來解決，而是你自己必須要做

回顧一下C10K問題

在之前，開發(fā)人員處理C10K的擴(kuò)展性問題的時(shí)候，盡量避免了服務(wù)器處理超過1萬的并發(fā)連接，改進(jìn)操作系統(tǒng)內(nèi)核及事件驅(qū)動(dòng)服務(wù)器（用Nginx和Node）和代替了線程服務(wù)（Apache）

Apache的問題，在于服務(wù)器的性能會(huì)隨著連接數(shù)增多而變差，，比如Apache持續(xù)幾秒的短連接，快速的事物，如果每秒處理1000個(gè)事物，只能有約1000個(gè)并發(fā)連接到服務(wù)器，如果事務(wù)延長(zhǎng)到了10秒，要維持每秒1000個(gè)事物則必須打開一個(gè)萬個(gè)并發(fā)連接，這種情況下：盡管不顧DoS攻擊，Apache也會(huì)性能陡降，同時(shí)大量的下載操作也會(huì)是Apache崩潰

OS內(nèi)核中兩個(gè)基本的問題：

1、連接數(shù)=線程數(shù)/進(jìn)程數(shù)：當(dāng)一個(gè)數(shù)據(jù)包進(jìn)來，內(nèi)核會(huì)遍歷所有的進(jìn)程以決定由那個(gè)進(jìn)程來處理這個(gè)數(shù)據(jù)包

2、連接數(shù)=選擇數(shù)/輪訓(xùn)次數(shù)（單線程）：同樣的擴(kuò)展性問題，每個(gè)包都要走一遭列表上所有的Socket

通過上述針對(duì)Apache所表現(xiàn)出的問題，實(shí)際上徹底解決并發(fā)性能問題的解決方法的根本就是改進(jìn)OS內(nèi)核使其在常數(shù)時(shí)間內(nèi)查找，使線程切換時(shí)間與線程數(shù)量無關(guān)，使用一個(gè)新的可擴(kuò)展epoll()/IOCompletionPort常數(shù)時(shí)間去做socket查詢。
因?yàn)榫€程調(diào)度并沒有得到擴(kuò)展，所以服務(wù)器大規(guī)模對(duì)socket使用epoll方法，這樣就導(dǎo)致需要使用異步編程模式，而這些編程模式正是Nginx和Node類型服務(wù)器具有的。所以當(dāng)從Apache遷移到Nginx和Node類型服務(wù)器時(shí)，即使在一個(gè)配置較低的服務(wù)器上增加連接數(shù)，性能也不會(huì)突降。所以在處理C10K連接時(shí)，一臺(tái)筆記本電腦的速度甚至超過了16核的服務(wù)器。這也是前一個(gè)10年解決C10K問題的普遍方法。

實(shí)現(xiàn)C10M意味著什么

1千萬的并發(fā)連接數(shù)
100萬個(gè)連接/秒：每個(gè)連接以這個(gè)速率持續(xù)約10秒（單個(gè)請(qǐng)求10秒超時(shí)）
10GB/秒的連接：快速連接到互聯(lián)網(wǎng)
1千萬個(gè)數(shù)據(jù)包/秒：目前的服務(wù)器每秒處理50K數(shù)據(jù)包
10微妙的延遲：可擴(kuò)展服務(wù)也行可以處理這個(gè)規(guī)模（但延遲會(huì)飆升）
10微妙的抖動(dòng)：限制最大的延遲
并發(fā)10核技術(shù)：軟件支持更多核的服務(wù)器

為什么說實(shí)現(xiàn)C10M的挑戰(zhàn)不在硬件而在軟件

硬件不是10M問題的性能瓶頸所在處，真正的問題出在軟件上，尤其是*nux操作系統(tǒng)。理由如下面這幾點(diǎn)：
首先：最初的設(shè)計(jì)是讓Unix成為一個(gè)電話網(wǎng)絡(luò)的控制系統(tǒng)，而不是成為一個(gè)服務(wù)器操作系統(tǒng)。對(duì)于控制系統(tǒng)而言，針對(duì)的主要目標(biāo)是用戶和任務(wù)，而并沒有針對(duì)作為協(xié)助功能的數(shù)據(jù)處理做特別設(shè)計(jì)，也就是既沒有所謂的快速路徑、慢速路徑，也沒有各種數(shù)據(jù)服務(wù)處理的優(yōu)先級(jí)差別。
其次：傳統(tǒng)的CPU，因?yàn)橹挥幸粋€(gè)核，操作系統(tǒng)代碼以多線程或多任務(wù)的形式來提升整體性能。而現(xiàn)在，4核、8核、32核、64核和100核，都已經(jīng)是真實(shí)存在的CPU芯片，如何提高多核的性能可擴(kuò)展性，是一個(gè)必須面對(duì)的問題。比如讓同一任務(wù)分割在多個(gè)核心上執(zhí)行，以避免CPU的空閑浪費(fèi)，當(dāng)然，這里面要解決的技術(shù)點(diǎn)有任務(wù)分割、任務(wù)同步和異步等。
再次：核心緩存大小與內(nèi)存速度是一個(gè)關(guān)鍵問題。現(xiàn)在，內(nèi)存已經(jīng)變得非常的便宜，隨便一臺(tái)普通的筆記本電腦，內(nèi)存至少也就是4G以上，高端服務(wù)器的內(nèi)存上24G那是相當(dāng)?shù)钠匠！５牵瑑?nèi)存的訪問速度仍然很慢，CPU訪問一次內(nèi)存需要約60~100納秒，相比很久以前的內(nèi)存訪問速度，這基本沒有增長(zhǎng)多少。對(duì)于在一個(gè)帶有1GHZ主頻CPU的電腦硬件里，如果要實(shí)現(xiàn)10M性能，那么平均每一個(gè)包只有100納秒，如果存在兩次CPU訪問內(nèi)存，那么10M性能就達(dá)不到了。核心緩存，也就是CPU L1/L2/LL Cache，雖然訪問速度會(huì)快些，但大小仍然不夠，我之前接觸到的高端至強(qiáng)，LLC容量大小貌似也就是12M。

解決C10M問題的思路總結(jié)

網(wǎng)卡問題：通過內(nèi)核工作效率不高
解決方案：使用自己的驅(qū)動(dòng)程序并管理它們，使適配器遠(yuǎn)離操作系統(tǒng)。
CPU問題：使用傳統(tǒng)的內(nèi)核方法來協(xié)調(diào)你的應(yīng)用程序是行不通的。
解決方案：Linux管理前兩個(gè)CPU，你的應(yīng)用程序管理其余的CPU，中斷只發(fā)生在你允許的CPU上。
內(nèi)存問題：內(nèi)存需要特別關(guān)注，以求高效。
解決方案：在系統(tǒng)啟動(dòng)時(shí)就分配大部分內(nèi)存給你管理的大內(nèi)存頁(yè)。
以Linux為例，解決的思路就是將控制層交給Linux，應(yīng)用程序管理數(shù)據(jù)。應(yīng)用程序與內(nèi)核之間沒有交互、沒有線程調(diào)度、沒有系統(tǒng)調(diào)用、沒有中斷，什么都沒有。然而，你有的是在Linux上運(yùn)行的代碼，你可以正常調(diào)試，這不是某種怪異的硬件系統(tǒng)，需要特定的工程師。你需要定制的硬件在數(shù)據(jù)層提升性能，但是必須是在你熟悉的編程和開發(fā)環(huán)境上進(jìn)行。

說了這么多，到底什么是高并發(fā)呢？

引言：代碼還沒有開始寫，就要考慮萬一哪一天IM用戶量破百萬，千萬該怎么辦，這個(gè)是程序員的基本修養(yǎng)

高并發(fā)是互聯(lián)網(wǎng)系統(tǒng)架構(gòu)的一個(gè)性能指標(biāo)之一，它通常是指單位時(shí)間內(nèi)系統(tǒng)能夠同時(shí)處理的請(qǐng)求數(shù)，簡(jiǎn)單的說：QPS（Queries per second）

高并發(fā)的基本表現(xiàn)為單位時(shí)間內(nèi)系統(tǒng)能夠同時(shí)處理的請(qǐng)求數(shù)
高并發(fā)的核心是對(duì)CPU的資源的有效的壓榨

對(duì)于大多數(shù)互聯(lián)網(wǎng)應(yīng)用來說，CPU不是該系統(tǒng)的瓶頸，系統(tǒng)的大部分的時(shí)間的情況下CPU都是在I/O（硬盤/內(nèi)存/網(wǎng)絡(luò)）的讀/寫操作

控制變量法

一個(gè)經(jīng)典的C/S的HTTP請(qǐng)求流程：

Client -1-> 負(fù)載均衡LVS，Nginx -2-> 服務(wù)應(yīng)用層（JAVA Python Go）-3-> 數(shù)據(jù)緩存層（redis Memcached）-4-> 持久層（MySQL MongoDB）-4-> 返回給客戶端