本文由小米信息技術團隊研發工程師陳剛原創，原題“當我們在談論高并發的時候究竟在談什么?”，為了更好的內容呈現，即時通訊網收錄時有修訂和改動。

1、引言

在即時通訊網社區里，多是做IM、消息推送、客服系統、音視頻聊天這類實時通信方面的開發者，在涉及到即時通訊技術時聊的最多的話題就是高并發、高吞吐、海量用戶。

代碼還沒開始寫，就考慮萬一哪天這IM用戶量破百萬、千萬該怎么辦的問題，是多數程序員的基本修養（雖然產品一上市就可能死翹翹，但該“高瞻遠矚”的時候，不應該偷懶，不然怎么跟老板提漲工資.....）。

在面視即時通訊相關工作的時候，高并發也是必談問題，那到底什么是高并發？嗯，真要說出個所以然來，還真有點懵。。。

學習交流：

- 即時通訊/推送技術開發交流5群：215477170[推薦]

- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK

（本文同步發布于：http://www.52im.net/thread-3120-1-1.html）

2、系列文章

本文是系列文章中的第7篇，總目錄如下：

《高性能網絡編程(一)：單臺服務器并發TCP連接數到底可以有多少》

《高性能網絡編程(二)：上一個10年，著名的C10K并發連接問題》

《高性能網絡編程(三)：下一個10年，是時候考慮C10M并發問題了》

《高性能網絡編程(四)：從C10K到C10M高性能網絡應用的理論探索》

《高性能網絡編程(五)：一文讀懂高性能網絡編程中的I/O模型》

《高性能網絡編程(六)：一文讀懂高性能網絡編程中的線程模型》

《高性能網絡編程(七)：到底什么是高并發？一文即懂！》（本文）

《高性能網絡編程經典：《The C10K problem(英文)》[附件下載]》

3、什么是高并發?

高并發是互聯網系統架構的性能指標之一，它通常是指單位時間內系統能夠同時處理的請求數。

簡單點說，就是QPS（Queries per second）。

那么我們在談論高并發的時候，究竟在談什么東西呢？歸根結底，到底什么是高并發？

別急，我們繼續往下讀 ....

4、高并發究竟是什么?

這里先給出結論: 

1）高并發的基本表現為單位時間內系統能夠同時處理的請求數；

2）高并發的核心是對CPU資源的有效壓榨。

舉個例子：如果我們開發了一個叫做MD5窮舉的應用，每個請求都會攜帶一個md5加密字符串，最終系統窮舉出所有的結果，并返回原始字符串。這個時候我們的應用場景或者說應用業務是屬于CPU密集型而不是IO密集型。

這個時候CPU一直在做有效計算，甚至可以把CPU利用率跑滿，這時我們談論高并發并沒有任何意義。(當然，我們可以通過加機器也就是加CPU來提高并發能力,這個是一個正常猿都知道廢話方案，談論加機器沒有什么意義，沒有任何高并發是加機器解決不了，如果有,那說明你加的機器還不夠多！)

對于大多數互聯網應用來說，CPU不是也不應該是系統的瓶頸，系統的大部分時間的狀況都是CPU在等I/O (硬盤/內存/網絡) 的讀/寫操作完成。

這個時候就可能有人會說，我看系統監控的時候，內存和網絡都很正常，但是CPU利用率卻跑滿了這是為什么？

這是一個好問題，后文我會給出實際的例子，再次強調上文說的“有效壓榨”這4個字，這4個字會圍繞本文的全部內容！

5、控制變量法

萬事萬物都是互相聯系的，當我們在談論高并發的時候，系統的每個環節應該都是需要與之相匹配的。

我們先來回顧一下一個經典C/S的HTTP請求流程：

如上圖中的序號所示：

1）我們會經過DNS服務器的解析，請求到達負載均衡集群；

2）負載均衡服務器會根據配置的規則，想請求分攤到服務層。服務層也是我們的業務核心層，這里可能也會有一些RPC、MQ的一些調用等等；

3）再經過緩存層；

4）最后持久化數據；

5）返回數據給客戶端。

要達到高并發，我們需要負載均衡、服務層、緩存層、持久層都是高可用、高性能的。

甚至在第5步，我們也可以通過壓縮靜態文件、HTTP2推送靜態文件、CDN來做優化，這里的每一層我們都可以寫幾本書來談優化。

本文主要討論服務層這一塊，即圖紅線圈出來的那部分。不再考慮講述數據庫、緩存相關的影響。

高中的知識告訴我們，這個叫控制變量法。

6、再談并發

6.1 網絡編程模型的演變歷史： 

并發問題一直是服務端編程中的重點和難點問題，為了優系統的并發量，從最初的Fork進程開始，到進程池/線程池，再到epoll事件驅動（Nginx、node.js反人類回調），再到協程。

從上圖中可以很明顯的看出，整個演變的過程，就是對CPU有效性能壓榨的過程。

什么？不明顯？

6.2 那我們再談談上下文切換：

在談論上下文切換之前，我們再明確兩個名詞的概念：

1）并行：兩個事件同一時刻完成；

2）并發：兩個事件在同一時間段內交替發生，從宏觀上看，兩個事件都發生了。

線程是操作系統調度的最小單位，進程是資源分配的最小單位。由于CPU是串行的，因此對于單核CPU來說，同一時刻一定是只有一個線程在占用CPU資源的。因此，Linux作為一個多任務(進程)系統，會頻繁的發生進程/線程切換。

在每個任務運行前，CPU都需要知道從哪里加載，從哪里運行，這些信息保存在CPU寄存器和操作系統的程序計數器里面，這兩樣東西就叫做CPU上下文。

進程是由內核來管理和調度的，進程的切換只能發生在內核態，因此虛擬內存、棧、全局變量等用戶空間的資源，以及內核堆棧、寄存器等內核空間的狀態，就叫做進程上下文。

前面說過，線程是操作系統調度的最小單位。同時線程會共享父進程的虛擬內存和全局變量等資源，因此父進程的資源加上線上自己的私有數據就叫做線程的上下文。

對于線程的上下文切換來說，如果是同一進程的線程，因為有資源共享，所以會比多進程間的切換消耗更少的資源。

現在就更容易解釋了，進程和線程的切換，會產生CPU上下文切換和進程/線程上下文的切換。而這些上下文切換，都是會消耗額外的CPU的資源的。

6.3 進一步談談協程的上下文切換：

那么協程就不需要上下文切換了嗎？需要，但是不會產生 CPU上下文切換和進程/線程上下文的切換，因為這些切換都是在同一個線程中，即用戶態中的切換，你甚至可以簡單的理解為，協程上下文之間的切換，就是移動了一下你程序里面的指針，CPU資源依舊屬于當前線程。

需要深刻理解的，可以再深入看看Go的GMP模型。

最終的效果就是協程進一步壓榨了CPU的有效利用率。

7、回到開始的那個問題

這個時候就可能有人會說，我看系統監控的時候，內存和網絡都很正常，但是CPU利用率卻跑滿了這是為什么？

注意本篇文章在談到CPU利用率的時候，一定會加上有效兩字作為定語，CPU利用率跑滿，很多時候其實是做了很多低效的計算。

以"世界上最好的語言"為例。

典型PHP-FPM的CGI模式，每一個HTTP請求:

1）都會讀取框架的數百個php文件；

2）都會重新建立/釋放一遍MYSQL/REIDS/MQ連接；

3）都會重新動態解釋編譯執行PHP文件；

4）都會在不同的php-fpm進程直接不停的切換切換再切換。

php的這種CGI運行模式，根本上就決定了它在高并發上的災難性表現。

找到問題，往往比解決問題更難。當我們理解了高并發之后，我們會發現高并發和高性能并不是編程語言限制了你，限制你的只是你的思想。

找到問題，解決問題！當我們能有效壓榨CPU性能之后，能達到什么樣的效果?

下面我們看看 php+Swoole的HTTP服務與Java高性能的異步框架Netty的HTTP服務之間的性能差異對比。 

8、性能對比前的準備

swoole是什么：

Swoole是一個為PHP用C和C++編寫的基于事件的高性能異步&協程并行網絡通信引擎。鏈接：https://www.swoole.com/。

Netty是什么：

Netty是著名的Java高性能網絡通信開源框架。 Netty提供異步的、事件驅動的網絡應用程序框架和工具，用以快速開發高性能、高可靠性的網絡服務器和客戶端程序。官網：https://netty.io/、在線源碼：http://docs.52im.net/extend/docs/src/netty4_1/。

單機能夠達到的最大TCP連接數是多少？

回憶一下計算機網絡的相關知識，在傳輸層，每個TCP連接建立之前都會進行三次握手。

每個TCP連接由：

1）本地ip

2）本地端口；

3）遠端ip；

4）遠端端口。

四個屬性標識組成。

TCP協議報文頭如下（圖片來自維基百科）：

題外話：如果對TCP協議臉生的話，權威《TCP/IP詳解》走起。。。

如上圖所示：

1）本地端口由16位組成，因此本地端口的最多數量為 2^16 = 65535個；

2）遠端端口由16位組成，因此遠端端口的最多數量為 2^16 = 65535個。

同時，在linux底層的網絡編程模型中，每個TCP連接，操作系統都會維護一個File descriptor(fd)文件來與之對應，而fd的數量限制，可以由ulimit -n 命令查看和修改，測試之前我們可以執行命令: ulimit -n 65536修改這個限制為65535。

因此，在不考慮硬件資源限制的情況下：

1）本地的最大HTTP連接數為： 本地最大端口數65535 * 本地ip數1 = 65535 個；

2）遠端的最大HTTP連接數為：遠端最大端口數65535 * 遠端(客戶端)ip數+∞ = 無限制~~ 。

PS：實際上操作系統會有一些保留端口占用,因此本地的連接數實際也是達不到理論值的。想要深入地探討這個問題，本系列的第一篇文章可以詳讀一下：《高性能網絡編程(一)：單臺服務器并發TCP連接數到底可以有多少》。

9、性能對比

9.1 測試準備

硬件資源：各一臺docker容器、1G內存+2核CPU，如圖所示： 

docker-compose編排如下：

# java8

version: "2.2"

services:

  java8:

    container_name: "java8"

    hostname: "java8"

    image: "java:8"

    volumes:

      - /home/cg/MyApp:/MyApp

    ports:

      - "5555:8080"

    environment:

      - TZ=Asia/Shanghai

    working_dir: /MyApp

    cpus: 2

    cpuset: 0,1

 

    mem_limit: 1024m

    memswap_limit: 1024m

    mem_reservation: 1024m

    tty: true

 

# php7-sw

version: "2.2"

services:

  php7-sw:

    container_name: "php7-sw"

    hostname: "php7-sw"

    image: "mileschou/swoole:7.1"

    volumes:

      - /home/cg/MyApp:/MyApp

    ports:

      - "5551:8080"

    environment:

      - TZ=Asia/Shanghai

    working_dir: /MyApp

    cpus: 2

    cpuset: 0,1

 

    mem_limit: 1024m

    memswap_limit: 1024m

    mem_reservation: 1024m

    tty: true

php代碼：

<?php

useSwoole\Server;

useSwoole\Http\Response;

$http= newswoole_http_server("0.0.0.0", 8080);

$http->set([

    'worker_num'=> 2

]);

$http->on("request", function($request, Response $response) {

    //go(function () use ($response) {

        // Swoole\Coroutine::sleep(0.01);

        $response->end('Hello World');

    //});

});

 

$http->on("start", function(Server $server) {

    go(function() use($server) {

        echo"server listen on 0.0.0.0:8080 \n";

    });

});

$http->start();

Java關鍵代碼：源代碼來自 https://github.com/netty/netty

public static void main(String[] args) throws Exception {

    // Configure SSL.

    finalSslContext sslCtx;

    if(SSL) {

        SelfSignedCertificate ssc = newSelfSignedCertificate();

        sslCtx = SslContextBuilder.forServer(ssc.certificate(), ssc.privateKey()).build();

    } else{

        sslCtx = null;

    }

 

    // Configure the server.

    EventLoopGroup bossGroup = newNioEventLoopGroup(2);

    EventLoopGroup workerGroup = newNioEventLoopGroup();

    try{

        ServerBootstrap b = newServerBootstrap();

        b.option(ChannelOption.SO_BACKLOG, 1024);

        b.group(bossGroup, workerGroup)

         .channel(NioServerSocketChannel.class)

         .handler(newLoggingHandler(LogLevel.INFO))

         .childHandler(newHttpHelloWorldServerInitializer(sslCtx));

 

        Channel ch = b.bind(PORT).sync().channel();

 

        System.err.println("Open your web browser and navigate to "+

                (SSL? "https": "http") + "://127.0.0.1:"+ PORT + '/');

 

        ch.closeFuture().sync();

    } finally{

        bossGroup.shutdownGracefully();

        workerGroup.shutdownGracefully();

    }

}

因為我只給了兩個核心的CPU資源，所以兩個服務均只開啟連個work進程即可。5551端口表示PHP服務、5555端口表示Java服務。

9.2 壓測工具結果對比：ApacheBench (ab)

ab命令：docker run --rm jordi/ab -k -c 1000 -n 1000000 http://10.234.3.32:5555/

在并發1000進行100萬次Http請求的基準測試中的結果如下。

Java + netty 壓測結果： 

PHP + swoole 壓測結果：

 

ps：上圖選擇的是三次壓測下的最佳結果。

總的來說，性能差異并不大，PHP+swoole的服務甚至比Java+netty的服務還要稍微好一點，特別是在內存占用方面，java用了600MB、php只用了30MB。

這能說明什么呢？

沒有IO阻塞操作，不會發生協程切換。這個僅僅只能說明 多線程+epoll的模式下，有效的壓榨CPU性能，你甚至用PHP都能寫出高并發和高性能的服務。

10、性能對比——見證奇跡的時刻

上面代碼其實并沒有展現出協程的優秀性能，因為整個請求沒有阻塞操作，但往往我們的應用會伴隨著例如 文檔讀取、DB連接/查詢 等各種阻塞操作，下面我們看看加上阻塞操作后，壓測結果如何。

Java和PHP代碼中,我都分別加上 sleep(0.01) //秒 的代碼，模擬0.01秒的系統調用阻塞。

代碼就不再重復貼上來了。

帶IO阻塞操作的 Java + netty 壓測結果：

大概10分鐘才能跑完所有壓測。。。

帶IO阻塞操作的 PHP + swoole 壓測結果： 

 

從結果中可以看出：基于協程的php+ swoole服務比 Java + netty服務的QPS高了6倍。

當然，這兩個測試代碼都是官方demo中的源代碼，肯定還有很多可以優化的配置，優化之后，結果肯定也會好很多。

可以再思考下：為什么官方默認線程/進程數量不設置的更多一點呢？

進程/線程數量可不是越多越好哦，前面我們已經討論過了，在進程/線程切換的時候，會產生額外的CPU資源花銷，特別是在用戶態和內核態之間切換的時候！

11、本文小結

對于上面兩節的壓測結果來說，我并不是針對Java，我想說的是：只要明白了高并發的核心是什么，找到這個目標，無論用什么編程語言，只要針對CPU利用率做有效的優化（連接池、守護進程、多線程、協程、select輪詢、epoll事件驅動），你也能搭建出一個高并發和高性能的系統。

所以，你現在明白了，什么是高并發了嗎？

思路永遠比結果重要！

附錄：更多精華系列文章

《TCP/IP詳解 - 第11章·UDP：用戶數據報協議》

《TCP/IP詳解 - 第17章·TCP：傳輸控制協議》

《TCP/IP詳解 - 第18章·TCP連接的建立與終止》

《TCP/IP詳解 - 第21章·TCP的超時與重傳》

《不為人知的網絡編程(一)：淺析TCP協議中的疑難雜癥(上篇)》

《不為人知的網絡編程(二)：淺析TCP協議中的疑難雜癥(下篇)》

《不為人知的網絡編程(三)：關閉TCP連接時為什么會TIME_WAIT、CLOSE_WAIT》

《不為人知的網絡編程(四)：深入研究分析TCP的異常關閉》

《不為人知的網絡編程(五)：UDP的連接性和負載均衡》

《不為人知的網絡編程(六)：深入地理解UDP協議并用好它》

《不為人知的網絡編程(七)：如何讓不可靠的UDP變的可靠？》

《不為人知的網絡編程(八)：從數據傳輸層深度解密HTTP》

《不為人知的網絡編程(九)：理論聯系實際，全方位深入理解DNS》

《網絡編程懶人入門(一)：快速理解網絡通信協議（上篇）》

《網絡編程懶人入門(二)：快速理解網絡通信協議（下篇）》

《網絡編程懶人入門(三)：快速理解TCP協議一篇就夠》

《網絡編程懶人入門(四)：快速理解TCP和UDP的差異》

《網絡編程懶人入門(五)：快速理解為什么說UDP有時比TCP更有優勢》

《網絡編程懶人入門(六)：史上最通俗的集線器、交換機、路由器功能原理入門》

《網絡編程懶人入門(七)：深入淺出，全面理解HTTP協議》

《網絡編程懶人入門(八)：手把手教你寫基于TCP的Socket長連接》

《網絡編程懶人入門(九)：通俗講解，有了IP地址，為何還要用MAC地址？》

《網絡編程懶人入門(十)：一泡尿的時間，快速讀懂QUIC協議》

《網絡編程懶人入門(十一)：一文讀懂什么是IPv6》

《網絡編程懶人入門(十二)：快速讀懂Http/3協議，一篇就夠！》

《腦殘式網絡編程入門(一)：跟著動畫來學TCP三次握手和四次揮手》

《腦殘式網絡編程入門(二)：我們在讀寫Socket時，究竟在讀寫什么？》

《腦殘式網絡編程入門(三)：HTTP協議必知必會的一些知識》

《腦殘式網絡編程入門(四)：快速理解HTTP/2的服務器推送(Server Push)》

《腦殘式網絡編程入門(五)：每天都在用的Ping命令，它到底是什么？》

《腦殘式網絡編程入門(六)：什么是公網IP和內網IP？NAT轉換又是什么鬼？》

《腦殘式網絡編程入門(七)：面視必備，史上最通俗計算機網絡分層詳解》

《腦殘式網絡編程入門(八)：你真的了解127.0.0.1和0.0.0.0的區別？》

《腦殘式網絡編程入門(九)：面試必考，史上最通俗大小端字節序詳解》

《IM開發者的零基礎通信技術入門(一)：通信交換技術的百年發展史(上)》

《IM開發者的零基礎通信技術入門(二)：通信交換技術的百年發展史(下)》

《IM開發者的零基礎通信技術入門(三)：國人通信方式的百年變遷》

《IM開發者的零基礎通信技術入門(四)：手機的演進，史上最全移動終端發展史》

《IM開發者的零基礎通信技術入門(五)：1G到5G，30年移動通信技術演進史》

《IM開發者的零基礎通信技術入門(六)：移動終端的接頭人——“基站”技術》

《IM開發者的零基礎通信技術入門(七)：移動終端的千里馬——“電磁波”》

《IM開發者的零基礎通信技術入門(八)：零基礎，史上最強“天線”原理掃盲》

《IM開發者的零基礎通信技術入門(九)：無線通信網絡的中樞——“核心網”》

《IM開發者的零基礎通信技術入門(十)：零基礎，史上最強5G技術掃盲》

《IM開發者的零基礎通信技術入門(十一)：為什么WiFi信號差？一文即懂！》

《IM開發者的零基礎通信技術入門(十二)：上網卡頓？網絡掉線？一文即懂！》

《IM開發者的零基礎通信技術入門(十三)：為什么手機信號差？一文即懂！》

《IM開發者的零基礎通信技術入門(十四)：高鐵上無線上網有多難？一文即懂！》

《IM開發者的零基礎通信技術入門(十五)：理解定位技術，一篇就夠》

本文已同步發布于“即時通訊技術圈”公眾號，歡迎關注：

▲ 本文在公眾號上的鏈接是：點此進入，原文鏈接是：http://www.52im.net/thread-3120-1-1.html