高並發是網際網路分布式系統架構的性能指標之一,它通常是指單位時間內系統能夠同時處理的請求數,
簡單點說，就是QPS(Queries per second)。
那麼我們在談論高並發的時候，究竟在談些什麼東西呢？
這裡先給出結論:
舉個例子，如果我們開發了一個叫做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推送靜態文件、CND來做優化，這裡的每一層我們都可以寫幾本書來談優化。
本文主要討論服務層這一塊，即圖紅線圈出來的那部分。不再考慮講述資料庫、緩存相關的影響。
高中的知識告訴我們，這個叫 控制變量法。
並發問題一直是服務端編程中的重點和難點問題，為了優系統的並發量，從最初的Fork進程開始，到進程池/線程池,再到epool事件驅動(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的這種CGI運行模式，根本上就決定了它在高並發上的災難性表現。
找到問題，往往比解決問題更難。當我們理解了當我們在談論高並發究竟在談什麼 之後,我們會發現高並發和高性能並不是程式語言限制了你，限制你的只是你的思想。
找到問題,解決問題！當我們能有效壓榨CPU性能之後,能達到什麼樣的效果?
下面我們看看 php+swoole的HTTP服務 與 Java高性能的異步框架netty的HTTP服務之間的性能差異對比。
Swoole是一個為PHP用C和C++編寫的基於事件的高性能異步&協程並行網絡通信引擎
Netty是由JBOSS提供的一個java開源框架。 Netty提供異步的、事件驅動的網絡應用程式框架和工具，用以快速開發高性能、高可靠性的網絡伺服器和客戶端程序。
回憶一下計算機網絡的相關知識，Htpp協議是應用層協議，在傳輸層，每個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數 = 65535 個。
遠端的最大HTTP連接數為： 65535 * 遠端ip數 = 無限制~~ 。
各一台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) {
$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();
原始碼來自, 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服務。
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響應時間(max,min)內存(MB)Java + netty84042.11(11,25)600+php + swoole87222.98(9,25)30+
ps: 上圖選擇的是三次壓測下的最佳結果。
總的來說，性能差異並不大，PHP+swoole的服務甚至比Java+netty的服務還要稍微好一點，特別是在內存占用方面，java用了600MB,php只用了30MB。
這能說明什麼呢？
沒有IO阻塞操作,不會發生協程切換。
這個僅僅只能說明 多線程+epool的模式下,有效的壓榨CPU性能，你甚至用PHP都能寫出高並發和高性能的服務。
上面代碼其實並沒有展現出協程的優秀性能，因為整個請求沒有阻塞操作,但往往我們的應用會伴隨著例如 文檔讀取、DB連接等各種阻塞操作,下面我們看看加上阻塞操作後,壓測結果如何。
Java和PHP代碼中,我都分別加上 sleep(0.01) //秒的代碼，模擬0.01秒的系統調用阻塞。
代碼就不再重複貼上來了。
帶IO阻塞操作的 Java + netty 壓測結果:
大概10分鐘才能跑完所有壓測。。。
帶IO阻塞操作的 PHP + swoole 壓測結果:
服務QPS響應時間(max,min)內存(MB)Java + netty1562.69(52,160)100+php + swoole9745.20(9,25)30+
從結果中可以看出,基於協程的php+ swoole服務比 Java + netty服務的QPS高了6倍。
當然，這兩個測試代碼都是官方demo中的原始碼，肯定還有很多可以優化的配置，優化之後，結果肯定也會好很多。
可以再思考下，為什麼官方默認線程/進程數量不設置的更多一點呢？
進程/線程數量可不是越多越好哦，前面我們已經討論過了，在進程/線程切換的時候，會產生額外的CPU資源花銷，特別是在用戶態和內核態之間切換的時候！
對於這些壓測結果來說，我並不是針對Java,我是指 只要明白了高並發的核心是什麼,找到這個目標，無論用什麼程式語言，只要針對CPU利用率做有效的優化(連接池、守護進程、多線程、協程、select輪詢、epool事件驅動)，你也能搭建出一個高並發和高性能的系統。
所以,你現在明白了，當我們在談論高性能的時候，究竟在談什麼了嗎？
思路永遠比結果重要！
本文作者：hncg