什么是高并發(fā)?

高并發(fā)是互聯(lián)網分布式系統(tǒng)架構的性能指標之一,它通常是指單位時間內系統(tǒng)能夠同時處理的請求數(shù),

簡單點說，就是QPS(Queries per second)。

那么我們在談論高并發(fā)的時候，究竟在談些什么東西呢？

高并發(fā)究竟是什么?

這里先給出結論:

高并發(fā)的基本表現(xiàn)為單位時間內系統(tǒng)能夠同時處理的請求數(shù),

高并發(fā)的核心是對CPU資源的有效壓榨。

舉個例子，如果我們開發(fā)了一個叫做MD5窮舉的應用，每個請求都會攜帶一個md5加密字符串，最終系統(tǒng)窮舉出所有的結果，并返回原始字符串。這個時候我們的應用場景或者說應用業(yè)務是屬于CPU密集型而不是IO密集型。這個時候CPU一直在做有效計算，甚至可以把CPU利用率跑滿，這時我們談論高并發(fā)并沒有任何意義。(當然，我們可以通過加機器也就是加CPU來提高并發(fā)能力,這個是一個正常猿都知道廢話方案，談論加機器沒有什么意義，沒有任何高并發(fā)是加機器解決不了，如果有,那說明你加的機器還不夠多!🐶)

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

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

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

控制變量法

萬事萬物都是互相聯(lián)系的，當我們在談論高并發(fā)的時候，系統(tǒng)的每個環(huán)節(jié)應該都是需要與之相匹配的。我們先來回顧一下一個經典C/S的HTTP請求流程。

如圖中的序號所示:

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

2 負載均衡服務器會根據(jù)配置的規(guī)則，想請求分攤到服務層。服務層也是我們的業(yè)務核心層，這里可能也會有一些PRC、MQ的一些調用等等

3 再經過緩存層

4 最后持久化數(shù)據(jù)

5 返回數(shù)據(jù)給客戶端

要達到高并發(fā)，我們需要 負載均衡、服務層、緩存層、持久層 都是高可用、高性能的，甚至在第5步，我們也可以通過 壓縮靜態(tài)文件、HTTP2推送靜態(tài)文件、CDN來做優(yōu)化，這里的每一層我們都可以寫幾本書來談優(yōu)化。

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

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

再談并發(fā)

•  網絡編程模型的演變歷史

并發(fā)問題一直是服務端編程中的重點和難點問題，為了優(yōu)系統(tǒng)的并發(fā)量，從最初的Fork進程開始，到進程池/線程池,再到epoll事件驅動(Nginx、node.js反人類回調),再到協(xié)程。

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

什么?不明顯?

•  那我們再談談上下文切換

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

并行：兩個事件同一時刻完成。

并發(fā)：兩個事件在同一時間段內交替發(fā)生,從宏觀上看，兩個事件都發(fā)生了。

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

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

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

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

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

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

•  進一步談談協(xié)程的上下文切換

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

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

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

回到開始的那個問題

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

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

以"世界上最好的語言"為例，典型PHP-FPM的CGI模式，每一個HTTP請求:

都會讀取框架的數(shù)百個php文件，

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

都會重新動態(tài)解釋編譯執(zhí)行PHP文件，

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

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

找到問題，往往比解決問題更難。當我們理解了當我們在談論高并發(fā)究竟在談什么 之后,我們會發(fā)現(xiàn)高并發(fā)和高性能并不是編程語言限制了你，限制你的只是你的思想。

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

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

性能對比前的準備

•  swoole是什么

Swoole是一個為PHP用C和C++編寫的基于事件的高性能異步&協(xié)程并行網絡通信引擎

•  Netty是什么

Netty是由JBOSS提供的一個java開源框架。 Netty提供異步的、事件驅動的網絡應用程序框架和工具，用以快速開發(fā)高性能、高可靠性的網絡服務器和客戶端程序。

•  單機能夠達到的最大HTTP連接數(shù)是多少？

回憶一下計算機網絡的相關知識，HTTP協(xié)議是應用層協(xié)議，在傳輸層，每個TCP連接建立之前都會進行三次握手。

每個TCP連接由 本地ip,本地端口,遠端ip,遠端端口,四個屬性標識。

TCP協(xié)議報文頭如下(圖片來自維基百科)：

本地端口由16位組成,因此本地端口的最多數(shù)量為 2^16 = 65535個。

遠端端口由16位組成,因此遠端端口的最多數(shù)量為 2^16 = 65535個。

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

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

本地的最大HTTP連接數(shù)為： 本地最大端口數(shù)65535 * 本地ip數(shù)1 = 65535 個。

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

PS: 實際上操作系統(tǒng)會有一些保留端口占用,因此本地的連接數(shù)實際也是達不到理論值的。

性能對比

•  測試資源

各一臺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  
use Swoole\Server;  
use Swoole\Http\Response;  
$http = new swoole_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.  
       final SslContext sslCtx;  
       if (SSL) {  
           SelfSignedCertificate ssc = new SelfSignedCertificate();  
           sslCtx = SslContextBuilder.forServer(ssc.certificate(), ssc.privateKey()).build();  
       } else {  
           sslCtx = null;  
       }  
       // Configure the server.  
       EventLoopGroup bossGroup = new NioEventLoopGroup(2);  
       EventLoopGroup workerGroup = new NioEventLoopGroup();  
       try {  
           ServerBootstrap b = new ServerBootstrap();  
           b.option(ChannelOption.SO_BACKLOG, 1024);  
           b.group(bossGroup, workerGroup)  
            .channel(NioServerSocketChannel.class)  
            .handler(new LoggingHandler(LogLevel.INFO))  
            .childHandler(new HttpHelloWorldServerInitializer(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服務。

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

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

在并發(fā)1000進行100萬次Http請求的基準測試中,

Java + netty 壓測結果:

PHP + swoole 壓測結果:

服務	QPS	響應時間ms(max,min)	內存(MB)
Java + netty	84042.11	(11,25)	600+
php + swoole	87222.98	(9,25)	30+

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

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

這能說明什么呢？

沒有IO阻塞操作,不會發(fā)生協(xié)程切換。

這個僅僅只能說明 多線程+epoll的模式下,有效的壓榨CPU性能，你甚至用PHP都能寫出高并發(fā)和高性能的服務。

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

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

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

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

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

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

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

服務	QPS	響應時間ms(max,min)	內存(MB)
Java + netty	1562.69	(52,160)	100+
php + swoole	9745.20	(9,25)	30+

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

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

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

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

對于這些壓測結果來說，我并不是針對Java,我是指 只要明白了高并發(fā)的核心是什么,找到這個目標，無論用什么編程語言，只要針對CPU利用率做有效的優(yōu)化(連接池、守護進程、多線程、協(xié)程、select輪詢、epoll事件驅動)，你也能搭建出一個高并發(fā)和高性能的系統(tǒng)。

所以,你現(xiàn)在明白了，當我們在談論高性能的時候，究竟在談什么了嗎？

思路永遠比結果重要！