一个springboot能支持多少并发_吃透这篇，你也能搭建出一个高并发和高性能的系统...
什么是高并發(fā)？高并發(fā)是互聯(lián)網(wǎng)分布式系統(tǒng)架構(gòu)的性能指標(biāo)之一，它通常是指單位時(shí)間內(nèi)系統(tǒng)能夠同時(shí)處理的請(qǐng)求數(shù)，簡(jiǎn)單點(diǎn)說(shuō)，就是 QPS(Queries Per Second)。
那么我們?cè)谡務(wù)摳卟l(fā)的時(shí)候，究竟在談些什么東西呢？高并發(fā)究竟是什么?
這里先給出結(jié)論：高并發(fā)的基本表現(xiàn)為單位時(shí)間內(nèi)系統(tǒng)能夠同時(shí)處理的請(qǐng)求數(shù)，高并發(fā)的核心是對(duì) CPU 資源的有效壓榨。
舉個(gè)例子，如果我們開(kāi)發(fā)了一個(gè)叫做 MD5 窮舉的應(yīng)用，每個(gè)請(qǐng)求都會(huì)攜帶一個(gè) MD5 加密字符串，最終系統(tǒng)窮舉出所有的結(jié)果，并返回原始字符串。
這個(gè)時(shí)候我們的應(yīng)用場(chǎng)景或者說(shuō)應(yīng)用業(yè)務(wù)是屬于 CPU 密集型而不是 IO 密集型。
這個(gè)時(shí)候 CPU 一直在做有效計(jì)算，甚至可以把 CPU 利用率跑滿，這時(shí)我們談?wù)摳卟l(fā)并沒(méi)有任何意義。(當(dāng)然，我們可以通過(guò)加機(jī)器也就是加 CPU 來(lái)提高并發(fā)能力，這個(gè)是一個(gè)正常猿都知道的廢話方案，談?wù)摷訖C(jī)器沒(méi)有什么意義，沒(méi)有任何高并發(fā)是加機(jī)器解決不了，如果有，那說(shuō)明你加的機(jī)器還不夠多！)
對(duì)于大多數(shù)互聯(lián)網(wǎng)應(yīng)用來(lái)說(shuō)，CPU 不是也不應(yīng)該是系統(tǒng)的瓶頸，系統(tǒng)的大部分時(shí)間的狀況都是 CPU 在等 I/O (硬盤(pán)/內(nèi)存/網(wǎng)絡(luò)) 的讀/寫(xiě)操作完成。
這個(gè)時(shí)候就可能有人會(huì)說(shuō)，我看系統(tǒng)監(jiān)控的時(shí)候，內(nèi)存和網(wǎng)絡(luò)都很正常，但是 CPU 利用率卻跑滿了這是為什么？
這是一個(gè)好問(wèn)題，后文我會(huì)給出實(shí)際的例子，再次強(qiáng)調(diào)上文說(shuō)的 '有效壓榨' 這 4 個(gè)字，這 4 個(gè)字會(huì)圍繞本文的全部?jī)?nèi)容！
控制變量法
萬(wàn)事萬(wàn)物都是互相聯(lián)系的，當(dāng)我們?cè)谡務(wù)摳卟l(fā)的時(shí)候，系統(tǒng)的每個(gè)環(huán)節(jié)應(yīng)該都是需要與之相匹配的。我們先來(lái)回顧一下一個(gè)經(jīng)典 C/S 的 HTTP 請(qǐng)求流程。
如圖中的序號(hào)所示：
我們會(huì)經(jīng)過(guò) DNS 服務(wù)器的解析，請(qǐng)求到達(dá)負(fù)載均衡集群。
負(fù)載均衡服務(wù)器會(huì)根據(jù)配置的規(guī)則，將請(qǐng)求分?jǐn)偟椒?wù)層。服務(wù)層也是我們的業(yè)務(wù)核心層，這里可能也會(huì)有一些 RPC、MQ 的一些調(diào)用等等。
再經(jīng)過(guò)緩存層。
最后持久化數(shù)據(jù)。
返回?cái)?shù)據(jù)給客戶端。
要達(dá)到高并發(fā)，我們需要負(fù)載均衡、服務(wù)層、緩存層、持久層都是高可用、高性能的。
甚至在第 5 步，我們也可以通過(guò)壓縮靜態(tài)文件、HTTP2 推送靜態(tài)文件、CDN 來(lái)做優(yōu)化，這里的每一層我們都可以寫(xiě)幾本書(shū)來(lái)談優(yōu)化。
本文主要討論服務(wù)層這一塊，即圖紅線圈出來(lái)的那部分。不再考慮講述數(shù)據(jù)庫(kù)、緩存相關(guān)的影響。高中的知識(shí)告訴我們，這個(gè)叫控制變量法。
再談并發(fā)
網(wǎng)絡(luò)編程模型的演變歷史
并發(fā)問(wèn)題一直是服務(wù)端編程中的重點(diǎn)和難點(diǎn)問(wèn)題，為了優(yōu)化系統(tǒng)的并發(fā)量，從最初的 Fork 進(jìn)程開(kāi)始，到進(jìn)程池/線程池，再到 Epoll 事件驅(qū)動(dòng)(Nginx、Node.js?反人類(lèi)回調(diào))，再到協(xié)程。
從上中可以很明顯的看出，整個(gè)演變的過(guò)程，就是對(duì) CPU 有效性能壓榨的過(guò)程。什么？不明顯？
那我們?cè)僬務(wù)勆舷挛那袚Q
在談?wù)撋舷挛那袚Q之前，我們?cè)倜鞔_兩個(gè)名詞的概念：
并行：兩個(gè)事件同一時(shí)刻完成。
并發(fā)：兩個(gè)事件在同一時(shí)間段內(nèi)交替發(fā)生，從宏觀上看，兩個(gè)事件都發(fā)生了。
線程是操作系統(tǒng)調(diào)度的最小單位，進(jìn)程是資源分配的最小單位。由于 CPU 是串行的，因此對(duì)于單核 CPU 來(lái)說(shuō)，同一時(shí)刻一定是只有一個(gè)線程在占用 CPU 資源的。因此，Linux 作為一個(gè)多任務(wù)(進(jìn)程)系統(tǒng)，會(huì)頻繁的發(fā)生進(jìn)程/線程切換。
在每個(gè)任務(wù)運(yùn)行前，CPU 都需要知道從哪里加載，從哪里運(yùn)行，這些信息保存在 CPU 寄存器和操作系統(tǒng)的程序計(jì)數(shù)器里面，這兩樣?xùn)|西就叫做?CPU 上下文。
進(jìn)程是由內(nèi)核來(lái)管理和調(diào)度的，進(jìn)程的切換只能發(fā)生在內(nèi)核態(tài)，因此虛擬內(nèi)存、棧、全局變量等用戶空間的資源，以及內(nèi)核堆棧、寄存器等內(nèi)核空間的狀態(tài)，就叫做進(jìn)程上下文。
前面說(shuō)過(guò)，線程是操作系統(tǒng)調(diào)度的最小單位。同時(shí)線程會(huì)共享父進(jìn)程的虛擬內(nèi)存和全局變量等資源，因此父進(jìn)程的資源加上線上自己的私有數(shù)據(jù)就叫做線程的上下文。
對(duì)于線程的上下文切換來(lái)說(shuō)，如果是同一進(jìn)程的線程，因?yàn)橛匈Y源共享，所以會(huì)比多進(jìn)程間的切換消耗更少的資源。
現(xiàn)在就更容易解釋了，進(jìn)程和線程的切換，會(huì)產(chǎn)生 CPU 上下文切換和進(jìn)程/線程上下文的切換。而這些上下文切換，都是會(huì)消耗額外的 CPU 資源的。
進(jìn)一步談?wù)剠f(xié)程的上下文切換
那么協(xié)程就不需要上下文切換了嗎？需要，但是不會(huì)產(chǎn)生?CPU 上下文切換和進(jìn)程/線程上下文的切換，因?yàn)檫@些切換都是在同一個(gè)線程中。
即用戶態(tài)中的切換，你甚至可以簡(jiǎn)單的理解為，協(xié)程上下文之間的切換，就是移動(dòng)了一下你程序里面的指針，CPU 資源依舊屬于當(dāng)前線程。
需要深刻理解的，可以再深入看看 Go 的 GMP 模型。最終的效果就是協(xié)程進(jìn)一步壓榨了 CPU 的有效利用率。
回到開(kāi)始的那個(gè)問(wèn)題
這個(gè)時(shí)候就可能有人會(huì)說(shuō)，我看系統(tǒng)監(jiān)控的時(shí)候，內(nèi)存和網(wǎng)絡(luò)都很正常，但是 CPU 利用率卻跑滿了。這是為什么？
注意本篇文章在談到 CPU 利用率的時(shí)候，一定會(huì)加上有效兩字作為定語(yǔ)，CPU 利用率跑滿，很多時(shí)候其實(shí)是做了很多低效的計(jì)算。
以"世界上最好的語(yǔ)言"為例，典型 PHP-FPM 的 CGI 模式，每一個(gè) HTTP 請(qǐng)求:
都會(huì)讀取框架的數(shù)百個(gè) PHP 文件
都會(huì)重新建立/釋放一遍 MySQL/Redis/MQ連接
都會(huì)重新動(dòng)態(tài)解釋編譯執(zhí)行 PHP 文件
都會(huì)在不同的 php-fpm 進(jìn)程直接不停的切換切換再切換
PHP 的這種 CGI 運(yùn)行模式，根本上就決定了它在高并發(fā)上的災(zāi)難性表現(xiàn)。
找到問(wèn)題，往往比解決問(wèn)題更難。當(dāng)我們理解了當(dāng)我們?cè)谡務(wù)摳卟l(fā)究竟在談什么之后，我們會(huì)發(fā)現(xiàn)高并發(fā)和高性能并不是編程語(yǔ)言限制了你，限制你的只是你的思想。
找到問(wèn)題，解決問(wèn)題！當(dāng)我們能有效壓榨 CPU 性能之后，能達(dá)到什么樣的效果?
下面我們看看 PHP+Swoole 的 HTTP 服務(wù)與 Java 高性能的異步框架 Netty 的 HTTP 服務(wù)之間的性能差異對(duì)比。
性能對(duì)比前的準(zhǔn)備
Swoole 是什么
Swoole 是一個(gè)為 PHP 開(kāi)發(fā)人員用 C 和 C++ 編寫(xiě)的基于事件的高性能異步&協(xié)程并行網(wǎng)絡(luò)通信引擎。
Netty 是什么
Netty 是由 JBOSS 提供的一個(gè) Java 開(kāi)源框架。Netty 提供異步的、事件驅(qū)動(dòng)的網(wǎng)絡(luò)應(yīng)用程序框架和工具，用以快速開(kāi)發(fā)高性能、高可靠性的網(wǎng)絡(luò)服務(wù)器和客戶端程序。
單機(jī)能夠達(dá)到的最大 HTTP 連接數(shù)是多少？回憶一下計(jì)算機(jī)網(wǎng)絡(luò)的相關(guān)知識(shí)，HTTP 協(xié)議是應(yīng)用層協(xié)議，在傳輸層，每個(gè) TCP 連接建立之前都會(huì)進(jìn)行三次握手。
每個(gè) TCP 連接由本地 IP，本地端口，遠(yuǎn)端 IP，遠(yuǎn)端端口，四個(gè)屬性標(biāo)識(shí)。
TCP 協(xié)議報(bào)文頭如上圖(圖片來(lái)自維基百科)：
本地端口由 16 位組成，因此本地端口的最多數(shù)量為 2^16 = 65535個(gè)。
遠(yuǎn)端端口由 16 位組成，因此遠(yuǎn)端端口的最多數(shù)量為 2^16 = 65535個(gè)。
同時(shí)，在 Linux 底層的網(wǎng)絡(luò)編程模型中，每個(gè) TCP 連接，操作系統(tǒng)都會(huì)維護(hù)一個(gè) File descriptor(fd) 文件來(lái)與之對(duì)應(yīng)，而 fd 的數(shù)量限制，可以由 ulimt -n 命令查看和修改。
測(cè)試之前我們可以執(zhí)行命令：ulimit -n 65536 修改這個(gè)限制為 65535。
因此，在不考慮硬件資源限制的情況下：
本地的最大 HTTP 連接數(shù)為：本地最大端口數(shù) 65535 * 本地 IP 數(shù) 1 = 65535 個(gè)。
遠(yuǎn)端的最大 HTTP 連接數(shù)為：遠(yuǎn)端最大端口數(shù) 65535 * 遠(yuǎn)端(客戶端)IP 數(shù)+∞ = 無(wú)限制~~ 。
PS: 實(shí)際上操作系統(tǒng)會(huì)有一些保留端口占用，因此本地的連接數(shù)實(shí)際也是達(dá)不到理論值的。
性能對(duì)比
測(cè)試資源
各一臺(tái) Docker 容器，1G 內(nèi)存+2 核 CPU，如圖所示：
docker-compose 編排如下：
#?java8version:?"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 關(guān)鍵代碼：(源代碼來(lái)自：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();
????????}
????}
因?yàn)槲抑唤o了兩個(gè)核心的 CPU 資源，所以兩個(gè)服務(wù)均只開(kāi)啟兩個(gè) Work 進(jìn)程即可：
5551 端口表示 PHP 服務(wù)。?
5555 端口表示 Java 服務(wù)。
壓測(cè)工具結(jié)果對(duì)比
ApacheBench (ab)命令:?
docker?run?--rm?jordi/ab?-k?-c?1000?-n?1000000?http://10.234.3.32:5555/在并發(fā) 1000 進(jìn)行 100 萬(wàn)次 HTTP 請(qǐng)求的基準(zhǔn)測(cè)試中，Java + Netty 壓測(cè)結(jié)果：
PHP + Swoole 壓測(cè)結(jié)果：
PS：上圖選擇的是三次壓測(cè)下的最佳結(jié)果。
總的來(lái)說(shuō)，性能差異并不大，PHP+Swoole 的服務(wù)甚至比 Java+Netty 的服務(wù)還要稍微好一點(diǎn)，特別是在內(nèi)存占用方面，Java 用了 600MB，PHP 只用了 30MB。
這能說(shuō)明什么呢？沒(méi)有 IO 阻塞操作，不會(huì)發(fā)生協(xié)程切換。
這個(gè)僅僅只能說(shuō)明多線程+Epoll 的模式下，有效的壓榨 CPU 性能，你甚至用 PHP 都能寫(xiě)出高并發(fā)和高性能的服務(wù)。
性能對(duì)比：見(jiàn)證奇跡的時(shí)刻
上面代碼其實(shí)并沒(méi)有展現(xiàn)出協(xié)程的優(yōu)秀性能，因?yàn)檎麄€(gè)請(qǐng)求沒(méi)有阻塞操作，但往往我們的應(yīng)用會(huì)伴隨著例如文檔讀取、DB 連接/查詢等各種阻塞操作，下面我們看看加上阻塞操作后，壓測(cè)結(jié)果如何。
Java 和 PHP 代碼中，我都分別加上?Sleep(0.01) //秒的代碼，模擬 0.01 秒的系統(tǒng)調(diào)用阻塞，代碼就不再重復(fù)貼上來(lái)了。
帶 IO 阻塞操作的 Java + Netty 壓測(cè)結(jié)果：
大概 10 分鐘才能跑完所有壓測(cè)，帶 IO 阻塞操作的 PHP + Swoole 壓測(cè)結(jié)果：
從結(jié)果中可以看出，基于協(xié)程的 PHP + Swoole 服務(wù)比 Java + Netty 服務(wù)的 QPS 高了 6 倍。
當(dāng)然，這兩個(gè)測(cè)試代碼都是官方 Demo 中的源代碼，肯定還有很多可以優(yōu)化的配置，優(yōu)化之后，結(jié)果肯定也會(huì)好很多。
可以再思考下，為什么官方默認(rèn)線程/進(jìn)程數(shù)量不設(shè)置的更多一點(diǎn)呢？
進(jìn)程/線程數(shù)量可不是越多越好哦，前面我們已經(jīng)討論過(guò)了，在進(jìn)程/線程切換的時(shí)候，會(huì)產(chǎn)生額外的 CPU 資源花銷(xiāo)，特別是在用戶態(tài)和內(nèi)核態(tài)之間切換的時(shí)候！
對(duì)于這些壓測(cè)結(jié)果來(lái)說(shuō)，我并不是針對(duì) Java，我是指只要明白了高并發(fā)的核心是什么，找到這個(gè)目標(biāo)，無(wú)論用什么編程語(yǔ)言，只要針對(duì) CPU 利用率做有效的優(yōu)化(連接池、守護(hù)進(jìn)程、多線程、協(xié)程、Select 輪詢、Epoll 事件驅(qū)動(dòng))，你也能搭建出一個(gè)高并發(fā)和高性能的系統(tǒng)。
所以，你現(xiàn)在明白了，當(dāng)我們?cè)谡務(wù)摳咝阅艿臅r(shí)候，究竟在談什么了嗎？思路永遠(yuǎn)比結(jié)果重要！
作者：hncg
編輯：陶家龍、孫淑娟
出處：https://segmentfault.com/a/1190000019360335
精彩文章推薦：
百萬(wàn)并發(fā)下的Nginx優(yōu)化，看這一篇就夠了！
有人要將“高并發(fā)”拉下“神壇”!
此文若說(shuō)不清Epoll原理，那就過(guò)來(lái)掐死我！
總結(jié)
以上是生活随笔為你收集整理的一个springboot能支持多少并发_吃透这篇，你也能搭建出一个高并发和高性能的系统...的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： latex 加粗_LaTeX论文模板
- 下一篇： hadoop namenode启动不了_