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

時間  2019-11-06
標籤 咱們 談論 併發 時候 究竟 在談 什麼 简体版
原文   原文鏈接

什麼是高併發?

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

那麼咱們在談論高併發的時候，究竟在談些什麼東西呢？php

高併發到底是什麼?

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

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

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

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

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

控制變量法

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

clipboard.png

如圖中的序號所示:
1 咱們會通過DNS服務器的解析，請求到達負載均衡集羣
2 負載均衡服務器會根據配置的規則，想請求分攤到服務層。服務層也是咱們的業務核心層，這裏可能也會有一些PRC、MQ的一些調用等等
3 再通過緩存層
4 最後持久化數據
5 返回數據給客戶端web

要達到高併發，咱們須要 負載均衡、服務層、緩存層、持久層 都是高可用、高性能的，甚至在第5步，咱們也能夠經過 壓縮靜態文件、HTTP2推送靜態文件、CDN來作優化，這裏的每一層咱們均可以寫幾本書來談優化。docker

本文主要討論服務層這一塊，即圖紅線圈出來的那部分。再也不考慮講述數據庫、緩存相關的影響。
高中的知識告訴咱們，這個叫 控制變量法。數據庫

再談併發

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

clipboard.png

併發問題一直是服務端編程中的重點和難點問題，爲了優系統的併發量，從最初的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是一個爲PHP用C和C++編寫的基於事件的高性能異步&協程並行網絡通訊引擎
Netty是由JBOSS提供的一個java開源框架。 Netty提供異步的、事件驅動的網絡應用程序框架和工具，用以快速開發高性能、高可靠性的網絡服務器和客戶端程序。
  • 單機可以達到的最大HTTP鏈接數是多少？

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

clipboard.png

本地端口由16位組成,所以本地端口的最多數量爲 2^16 = 65535個。
遠端端口由16位組成,所以遠端端口的最多數量爲 2^16 = 65535個。
同時，在linux底層的網絡編程模型中，每一個TCP鏈接，操做系統都會維護一個File descriptor(fd)文件來與之對應，而fd的數量限制，能夠由ulimit -n 命令查看和修改，測試以前咱們能夠執行命令: ulimit -n 65536修改這個限制爲65535。

所以，在不考慮硬件資源限制的狀況下，
本地的最大HTTP鏈接數爲： 本地最大端口數65535 * 本地ip數1 = 65535 個。
遠端的最大HTTP鏈接數爲：遠端最大端口數65535 * 遠端(客戶端)ip數+∞ = 無限制~~ 。
PS: 實際上操做系統會有一些保留端口占用,所以本地的鏈接數實際也是達不到理論值的。

性能對比

  • 測試資源

各一臺docker容器,1G內存+2核CPU,如圖所示:

clipboard.png

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/
在併發1000進行100萬次Http請求的基準測試中,

Java + netty 壓測結果:

clipboard.png

clipboard.png

PHP + swoole 壓測結果:

clipboard.png

clipboard.png

服務 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 壓測結果:

clipboard.png

大概10分鐘才能跑完全部壓測。。。

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

clipboard.png

服務 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事件驅動)，你也能搭建出一個高併發和高性能的系統。

因此,你如今明白了，當咱們在談論高性能的時候，究竟在談什麼了嗎？

思路永遠比結果重要！

本文歡迎轉載，轉載請註明做者和出處便可，謝謝！

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程