歡迎光臨
每天分享高質量文章

當我們在談論高併發的時候究竟在談什麼?

什麼是高併發?

 

高併發是互聯網分佈式系統架構的性能指標之一,它通常是指單位時間內系統能夠同時處理的請求數,簡單點說,就是QPS(Queries per second)。

那麼我們在談論高併發的時候,究竟在談些什麼東西呢?

高併發究竟是什麼?

這裡先給出結論: 
高併發的基本表現為單位時間內系統能夠同時處理的請求數,
高併發的核心是對CPU資源的有效壓榨

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

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

這個時候就可能有人會說,我看系統監控的時候,記憶體和網絡都很正常,但是CPU利用率卻跑滿了這是為什麼?

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

控制變數法

萬事萬物都是互相聯繫的,當我們在談論高併發的時候,系統的每個環節應該都是需要與之相匹配的。我們先來回顧一下一個經典C/S的HTTP請求流程。

如圖中的序號所示:
1 我們會經過DNS服務器的解析,請求到達負載均衡集群
2 負載均衡服務器會根據配置的規則,想請求分攤到服務層。服務層也是我們的業務核心層,這裡可能也會有一些PRC、MQ的一些呼叫等等
3 再經過快取層
4 最後持久化資料
5 傳回資料給客戶端

要達到高併發,我們需要 負載均衡、服務層、快取層、持久層 都是高可用、高性能的,甚至在第5步,我們也可以通過 壓縮靜態檔案、HTTP2推送靜態檔案、CDN來做優化,這裡的每一層我們都可以寫幾本書來談優化。

本文主要討論服務層這一塊,即圖紅線圈出來的那部分。不再考慮講述資料庫、快取相關的影響。
高中的知識告訴我們,這個叫 控制變數法

再談併發

 

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

併發問題一直是服務端編程中的重點和難點問題,為了優系統的併發量,從最初的Fork行程開始,到行程池/執行緒池,再到epoll事件驅動(Nginx、node.js反人類回呼),再到協程。
從上中可以很明顯的看出,整個演變的過程,就是對CPU有效性能壓榨的過程。
什麼?不明顯?

  • 那我們再談談背景關係切換

在談論背景關係切換之前,我們再明確兩個名詞的概念。
並行:兩個事件同一時刻完成。
併發:兩個事件在同一時間段內交替發生,從宏觀上看,兩個事件都發生了

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

在每個任務運行前,CPU都需要知道從哪裡加載,從哪裡運行,這些信息儲存在CPU暫存器和操作系統的程式計數器裡面,這兩樣東西就叫做 CPU背景關係
行程是由內核來管理和調度的,行程的切換隻能發生在內核態,因此 虛擬記憶體、棧、全域性變數等用戶空間的資源,以及內核堆棧、暫存器等內核空間的狀態,就叫做 行程背景關係
前面說過,執行緒是操作系統調度的最小單位。同時執行緒會共享父行程的虛擬記憶體和全域性變數等資源,因此 父行程的資源加上線上自己的私有資料就叫做執行緒的背景關係

對於執行緒的背景關係切換來說,如果是同一行程的執行緒,因為有資源共享,所以會比多行程間的切換消耗更少的資源。

現在就更容易解釋了,行程和執行緒的切換,會產生CPU背景關係切換和行程/執行緒背景關係的切換。而這些背景關係切換,都是會消耗額外的CPU的資源的。

  • 進一步談談協程的背景關係切換

那麼協程就不需要背景關係切換了嗎?需要,但是不會產生 CPU背景關係切換行程/執行緒背景關係的切換,因為這些切換都是在同一個執行緒中,即用戶態中的切換,你甚至可以簡單的理解為協程背景關係之間的切換,就是移動了一下你程式裡面的指標,CPU資源依舊屬於當前執行緒。
需要深刻理解的,可以再深入看看Go的GMP模型
最終的效果就是協程進一步壓榨了CPU的有效利用率

回到開始的那個問題

這個時候就可能有人會說,我看系統監控的時候,記憶體和網絡都很正常,但是CPU利用率卻跑滿了這是為什麼?

註意本篇文章在談到CPU利用率的時候,一定會加上有效兩字作為定語,CPU利用率跑滿,很多時候其實是做了很多低效的計算。
以”世界上最好的語言”為例,典型PHP-FPM的CGI樣式,每一個HTTP請求:
都會讀取框架的數百個php檔案,
都會重新建立/釋放一遍MYSQL/REIDS/MQ連接,
都會重新動態解釋編譯執行PHP檔案,
都會在不同的php-fpm行程直接不停的切換切換再切換。

php的這種CGI運行樣式,根本上就決定了它在高併發上的災難性表現

找到問題,往往比解決問題更難。當我們理解了當我們在談論高併發究竟在談什麼 之後,我們會發現高併發和高性能並不是編程語言限制了你,限制你的只是你的思想。

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

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

性能對比前的準備

 

  • swoole是什麼
Swoole是一個為PHP用C和C++編寫的基於事件的高性能異步&協程並行網絡通信引擎
  • Netty是什麼
Netty是由JBOSS提供的一個java開源框架。 Netty提供異步的、事件驅動的網絡應用程式框架和工具,用以快速開發高性能、高可靠性的網絡服務器和客戶端程式。
  • 單機能夠達到的最大HTTP連接數是多少?

回憶一下計算機網絡的相關知識,HTTP協議是應用層協議,在傳輸層,每個HTTP請求都會進行三次握手,並建立一個TCP連接。
每個TCP連接由 本地ip,本地端口,遠端ip,遠端端口,四個屬性標識。
TCP協議報文頭如下(圖片來自維基百科):

本地端口由16位組成,因此本地端口的最多數量為 2^16 = 65535個。
遠端端口由16位組成,因此遠端端口的最多數量為 2^16 = 65535個。
同時,在linux底層的網絡編程模型中,每個TCP連接,操作系統都會維護一個File descriptor(fd)檔案來與之對應,而fd的數量限制,可以由ulimt -n 命令查看和修改,測試之前我們可以執行命令: ulimit -n 65536修改這個限製為65535。

因此,在不考慮硬體資源限制的情況下,
本地的最大HTTP連接數為: 本地最大端口數65535 * 本地ip數1 = 65535 個。
遠端的最大HTTP連接數為:遠端最大端口數65535 * 遠端(客戶端)ip數+∞ = 無限制~~ 。
PS: 實際上操作系統會有一些保留端口占用,因此本地的連接數實際也是達不到理論值的。

性能對比

 

  • 測試資源

各一臺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代碼

     

 



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/
在併發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阻塞操作,不會發生協程切換。
這個僅僅只能說明 多執行緒+epoll的樣式下,有效的壓榨CPU性能,你甚至用PHP都能寫出高併發和高性能的服務。

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

上面代碼其實並沒有展現出協程的優秀性能,因為整個請求沒有阻塞操作,但往往我們的應用會伴隨著例如 文件讀取、DB連接等各種阻塞操作,下麵我們看看加上阻塞操作後,壓測結果如何。
Java和PHP代碼中,我都分別加上 sleep(0.01) //秒的代碼,模擬0.01秒的系統呼叫阻塞。
代碼就不再重覆貼上來了。

帶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+

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

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

可以再思考下,為什麼官方預設執行緒/行程數量不設置的更多一點呢?
行程/執行緒數量可不是越多越好哦,前面我們已經討論過了,在行程/執行緒切換的時候,會產生額外的CPU資源花銷,特別是在用戶態和內核態之間切換的時候!

對於這些壓測結果來說,我並不是針對Java,我是指 只要明白了高併發的核心是什麼,找到這個標的,無論用什麼編程語言,只要針對CPU利用率做有效的優化(連接池、守護行程、多執行緒、協程、select輪詢、epoll事件驅動),你也能搭建出一個高併發和高性能的系統。

所以,你現在明白了,當我們在談論高性能的時候,究竟在談什麼了嗎?

思路永遠比結果重要!

赞(0)

分享創造快樂