什么是高并發？高并發是互聯網分布式系統架構的性能指標之一，它通常是指單位時間內系統能夠同時處理的請求數，簡單點說，就是 QPS(Queries Per Second)。

那么我們在談論高并發的時候，究竟在談些什么東西呢？高并發究竟是什么?

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

舉個例子，如果我們開發了一個叫做 MD5 窮舉的應用，每個請求都會攜帶一個 MD5 加密字符串，最終系統窮舉出所有的結果，并返回原始字符串。

這個時候我們的應用場景或者說應用業務是屬于 CPU 密集型而不是 IO 密集型。

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

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

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

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

控制變量法

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

如圖中的序號所示：我們會經過 DNS 服務器的解析，請求到達負載均衡集群。

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

再經過緩存層。

最后持久化數據。

返回數據給客戶端。

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

甚至在第 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/Redis/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 協議是應用層協議，在傳輸層，每個 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)命令:

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 都能寫出高并發和高性能的服務。

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

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

Java 和 PHP 代碼中，我都分別加上?Sleep(0.01) //秒的代碼，模擬 0.01 秒的系統調用阻塞，代碼就不再重復貼上來了。

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

大概 10 分鐘才能跑完所有壓測，帶 IO 阻塞操作的 PHP + Swoole 壓測結果：

從結果中可以看出，基于協程的 PHP + Swoole 服務比 Java + Netty 服務的 QPS 高了 6 倍。

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

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

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

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

所以，你現在明白了，當我們在談論高性能的時候，究竟在談什么了嗎？思路永遠比結果重要！

總結

以上是生活随笔為你收集整理的php ssc 源码_吃透这篇，你也能搭建出一个高并发和高性能的系统的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。