Java 淺談 高并發(fā) 處理方案詳解
高性能開發(fā)十大必須掌握的核心技術(shù)
我們循序漸進(jìn),從內(nèi)存、磁盤I/O、網(wǎng)絡(luò)I/O、CPU、緩存、架構(gòu)、算法等多層次遞進(jìn),串聯(lián)起高性能開發(fā)十大必須掌握的核心技術(shù)。
- I/O優(yōu)化:零拷貝技術(shù) - I/O優(yōu)化:多路復(fù)用技術(shù) - 線程池技術(shù) - 無鎖編程技術(shù) - 進(jìn)程間通信技術(shù) - RPC && 序列化技術(shù) - 數(shù)據(jù)庫索引技術(shù) - 緩存技術(shù) && 布隆過濾器 - 全文搜索技術(shù) - 負(fù)載均衡技術(shù)
I/O優(yōu)化:零拷貝技術(shù)
從磁盤讀文件、再通過網(wǎng)絡(luò)發(fā)送數(shù)據(jù),數(shù)據(jù)從磁盤到網(wǎng)絡(luò),兜兜轉(zhuǎn)轉(zhuǎn)需要拷貝四次,其中CPU親自搬運(yùn)都需要兩次。
最近在學(xué)習(xí)nginx的底層設(shè)計(jì),正好有看到這個(gè)。后面可以在nginx系列里面補(bǔ)上這個(gè)。
零拷貝技術(shù),解放CPU,文件數(shù)據(jù)直接從內(nèi)核發(fā)送出去,無需再拷貝到應(yīng)用程序緩沖區(qū),白白浪費(fèi)資源。
Linux API:
ssize_t sendfile( int out_fd, int in_fd, off_t *offset, size_t count );
函數(shù)名字已經(jīng)把函數(shù)的功能解釋的很明顯了:發(fā)送文件。指定要發(fā)送的文件描述符和網(wǎng)絡(luò)套接字描述符,一個(gè)函數(shù)搞定!
I/O優(yōu)化:多路復(fù)用技術(shù)
每個(gè)線程都要阻塞在recv等待對(duì)方的請求,這來訪問的人多了,線程開的就多了,大量線程都在阻塞,系統(tǒng)運(yùn)轉(zhuǎn)速度也隨之下降。
這個(gè)時(shí)候,你需要多路復(fù)用技術(shù),使用select模型,將所有等待(accept、recv)都放在主線程里,工作線程不需要再等待。
過了一段時(shí)間之后,網(wǎng)站訪問的人越來越多了,就連select也開始有點(diǎn)應(yīng)接不暇,老板繼續(xù)讓你優(yōu)化性能。
這個(gè)時(shí)候,你需要升級(jí)多路復(fù)用模型為epoll。
select有三弊,epoll有三優(yōu)。
select底層采用數(shù)組來管理套接字描述符,同時(shí)管理的數(shù)量有上限,一般不超過幾千個(gè),epoll使用樹和鏈表來管理,同時(shí)管理數(shù)量可以很大。 select不會(huì)告訴你到底哪個(gè)套接字來了消息,你需要一個(gè)個(gè)去詢問。epoll直接告訴你誰來了消息,不用輪詢。 select進(jìn)行系統(tǒng)調(diào)用時(shí)還需要把套接字列表在用戶空間和內(nèi)核空間來回拷貝,循環(huán)中調(diào)用select時(shí)簡直浪費(fèi)。epoll統(tǒng)一在內(nèi)核管理套接字描述符,無需來回拷貝。
用上了epoll多路復(fù)用技術(shù),開發(fā)了3.0版本,你的網(wǎng)站能同時(shí)處理很多用戶請求了。
之前的方案中,工作線程總是用到才創(chuàng)建,用完就關(guān)閉,大量請求來的時(shí)候,線程不斷創(chuàng)建、關(guān)閉、創(chuàng)建、關(guān)閉,開銷挺大的。這個(gè)時(shí)候,你需要:
線程池技術(shù)
我們可以在程序一開始啟動(dòng)后就批量啟動(dòng)一波工作線程,而不是在有請求來的時(shí)候才去創(chuàng)建,使用一個(gè)公共的任務(wù)隊(duì)列,請求來臨時(shí),向隊(duì)列中投遞任務(wù),各個(gè)工作線程統(tǒng)一從隊(duì)列中不斷取出任務(wù)來處理,這就是線程池技術(shù)。
多線程技術(shù)的使用一定程度提升了服務(wù)器的并發(fā)能力,但同時(shí),多個(gè)線程之間為了數(shù)據(jù)同步,常常需要使用互斥體、信號(hào)、條件變量等手段來同步多個(gè)線程。這些重量級(jí)的同步手段往往會(huì)導(dǎo)致線程在用戶態(tài)/內(nèi)核態(tài)多次切換,系統(tǒng)調(diào)用,線程切換都是不小的開銷。
在線程池技術(shù)中,提到了一個(gè)公共的任務(wù)隊(duì)列,各個(gè)工作線程需要從中提取任務(wù)進(jìn)行處理,這里就涉及到多個(gè)工作線程對(duì)這個(gè)公共隊(duì)列的同步操作。
有沒有一些輕量級(jí)的方案來實(shí)現(xiàn)多線程安全的訪問數(shù)據(jù)呢?這個(gè)時(shí)候,你需要:
無鎖編程技術(shù)
多線程并發(fā)編程中,遇到公共數(shù)據(jù)時(shí)就需要進(jìn)行線程同步。而這里的同步又可以分為阻塞型同步和非阻塞型同步。
阻塞型同步好理解,我們常用的互斥體、信號(hào)、條件變量等這些操作系統(tǒng)提供的機(jī)制都屬于阻塞型同步,其本質(zhì)都是要加“鎖”。
與之對(duì)應(yīng)的非阻塞型同步就是在無鎖的情況下實(shí)現(xiàn)同步,目前有三類技術(shù)方案:
Wait-freeLock-freeObstruction-free
三類技術(shù)方案都是通過一定的算法和技術(shù)手段來實(shí)現(xiàn)不用阻塞等待而實(shí)現(xiàn)同步,這其中又以Lock-free最為應(yīng)用廣泛。
Lock-free能夠廣泛應(yīng)用得益于目前主流的CPU都提供了原子級(jí)別的read-modify-write原語,這就是著名的CAS(Compare-And-Swap)操作。在Intel x86系列處理器上,就是cmpxchg系列指令。
我們常常見到的無鎖隊(duì)列、無鎖鏈表、無鎖HashMap等數(shù)據(jù)結(jié)構(gòu),其無鎖的核心大都來源于此。在日常開發(fā)中,恰當(dāng)?shù)倪\(yùn)用無鎖化編程技術(shù),可以有效地降低多線程阻塞和切換帶來的額外開銷,提升性能。
服務(wù)器上線了一段時(shí)間,發(fā)現(xiàn)服務(wù)經(jīng)常崩潰異常,排查發(fā)現(xiàn)是工作線程代碼bug,一崩潰整個(gè)服務(wù)都不可用了。于是你決定把工作線程和主線程拆開到不同的進(jìn)程中,工作線程崩潰不能影響整體的服務(wù)。這個(gè)時(shí)候出現(xiàn)了多進(jìn)程,你需要:
進(jìn)程間通信技術(shù)
提起進(jìn)程間通信,你能想到的是什么?
管道 命名管道 socket 消息隊(duì)列 信號(hào) 信號(hào)量 共享內(nèi)存
以上各種進(jìn)程間通信的方式詳細(xì)介紹和比較,推薦一篇文章再探進(jìn)程間通信,這里不再贅述。
Scale-out(橫向拓展)
采用分布式部署的方式把流量分開,讓每個(gè)服務(wù)器都承擔(dān)一部分并發(fā)和流量。這也是我最喜歡的一種方法。
緩存
使用緩存來提高系統(tǒng)的性能。
為什么緩存可以大幅度提升系統(tǒng)的性能呢?
那肯定是要更普通磁盤進(jìn)行對(duì)比的啊。我們來看看普通磁盤的速度:
普通磁盤的尋道時(shí)間是 10ms 左右,而相比于磁盤尋道花費(fèi)的時(shí)間,CPU 執(zhí)行指令和內(nèi)存尋址的時(shí)間都在是 ns(納秒)級(jí)別,從千兆網(wǎng)卡上讀取數(shù)據(jù)的時(shí)間是在μs(微秒)級(jí)別。所以在整個(gè)計(jì)算機(jī)體系中,磁盤是最慢的一環(huán),甚至比其它的組件要慢幾個(gè)數(shù)量級(jí)。因此,我們通常使用以內(nèi)存作為存儲(chǔ)介質(zhì)的緩存,以此提升性能。
至于緩存為什么快,因?yàn)樗莾?nèi)置的啊,在內(nèi)存中。不過也有個(gè)缺點(diǎn),就是燒內(nèi)存。
異步
這是業(yè)務(wù)層面的異步。
內(nèi)核層面的異步,需要調(diào)用內(nèi)核指定的異步函數(shù)(aio族),不然,不論阻塞還是非阻塞都是同步。
高性能、高可用、高拓展 解決方案
以下實(shí)踐方案,有些我已經(jīng)試過了,有些還沒體驗(yàn)但是知道那么一回事兒,有些則不知道啥時(shí)候能實(shí)踐了。
高性能的實(shí)踐方案
1、集群部署,通過負(fù)載均衡減輕單機(jī)壓力。 2、多級(jí)緩存,包括靜態(tài)數(shù)據(jù)使用CDN、本地緩存、分布式緩存等,以及對(duì)緩存場景中的熱點(diǎn)key、緩存穿透、緩存并發(fā)、數(shù)據(jù)一致性等問題的處理。 3、分庫分表和索引優(yōu)化,以及借助搜索引擎解決復(fù)雜查詢問題。 4、考慮NoSQL數(shù)據(jù)庫的使用,比如HBase、TiDB等,但是團(tuán)隊(duì)必須熟悉這些組件,且有較強(qiáng)的運(yùn)維能力。 5、異步化,將次要流程通過多線程、MQ、甚至延時(shí)任務(wù)進(jìn)行異步處理。 6、限流,需要先考慮業(yè)務(wù)是否允許限流(比如秒殺場景是允許的),包括前端限流、Nginx接入層的限流、服務(wù)端的限流。 7、對(duì)流量進(jìn)行削峰填谷,通過MQ承接流量。 8、并發(fā)處理,通過多線程將串行邏輯并行化。 9、預(yù)計(jì)算,比如搶紅包場景,可以提前計(jì)算好紅包金額緩存起來,發(fā)紅包時(shí)直接使用即可。 10、緩存預(yù)熱,通過異步任務(wù)提前預(yù)熱數(shù)據(jù)到本地緩存或者分布式緩存中。 11、減少IO次數(shù),比如數(shù)據(jù)庫和緩存的批量讀寫、RPC的批量接口支持、或者通過冗余數(shù)據(jù)的方式干掉RPC調(diào)用。 12、減少IO時(shí)的數(shù)據(jù)包大小,包括采用輕量級(jí)的通信協(xié)議、合適的數(shù)據(jù)結(jié)構(gòu)、去掉接口中的多余字段、減少緩存key的大小、壓縮緩存value等。 13、程序邏輯優(yōu)化,比如將大概率阻斷執(zhí)行流程的判斷邏輯前置、For循環(huán)的計(jì)算邏輯優(yōu)化,或者采用更高效的算法。 14、各種池化技術(shù)的使用和池大小的設(shè)置,包括HTTP請求池、線程池(考慮CPU密集型還是IO密集型設(shè)置核心參數(shù))、數(shù)據(jù)庫和Redis連接池等。 15、JVM優(yōu)化,包括新生代和老年代的大小、GC算法的選擇等,盡可能減少GC頻率和耗時(shí)。 16、鎖選擇,讀多寫少的場景用樂觀鎖,或者考慮通過分段鎖的方式減少鎖沖突。
上述方案無外乎從計(jì)算和 IO 兩個(gè)維度考慮所有可能的優(yōu)化點(diǎn),需要有配套的監(jiān)控系統(tǒng)實(shí)時(shí)了解當(dāng)前的性能表現(xiàn),并支撐你進(jìn)行性能瓶頸分析,然后再遵循二八原則,抓主要矛盾進(jìn)行優(yōu)化。
高可用的實(shí)踐方案
1、對(duì)等節(jié)點(diǎn)的故障轉(zhuǎn)移,Nginx和服務(wù)治理框架均支持一個(gè)節(jié)點(diǎn)失敗后訪問另一個(gè)節(jié)點(diǎn)。 2、非對(duì)等節(jié)點(diǎn)的故障轉(zhuǎn)移,通過心跳檢測并實(shí)施主備切換(比如redis的哨兵模式或者集群模式、MySQL的主從切換等)。 3、接口層面的超時(shí)設(shè)置、重試策略和冪等設(shè)計(jì)。 4、降級(jí)處理:保證核心服務(wù),犧牲非核心服務(wù),必要時(shí)進(jìn)行熔斷;或者核心鏈路出問題時(shí),有備選鏈路。 5、限流處理:對(duì)超過系統(tǒng)處理能力的請求直接拒絕或者返回錯(cuò)誤碼。 6、MQ場景的消息可靠性保證,包括producer端的重試機(jī)制、broker側(cè)的持久化、consumer端的ack機(jī)制等。 7、灰度發(fā)布,能支持按機(jī)器維度進(jìn)行小流量部署,觀察系統(tǒng)日志和業(yè)務(wù)指標(biāo),等運(yùn)行平穩(wěn)后再推全量。 8、監(jiān)控報(bào)警:全方位的監(jiān)控體系,包括最基礎(chǔ)的CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)的監(jiān)控,以及Web服務(wù)器、JVM、數(shù)據(jù)庫、各類中間件的監(jiān)控和業(yè)務(wù)指標(biāo)的監(jiān)控。 9、災(zāi)備演練:類似當(dāng)前的“混沌工程”,對(duì)系統(tǒng)進(jìn)行一些破壞性手段,觀察局部故障是否會(huì)引起可用性問題。
高可用的方案主要從冗余、取舍、系統(tǒng)運(yùn)維3個(gè)方向考慮,同時(shí)需要有配套的值班機(jī)制和故障處理流程,當(dāng)出現(xiàn)線上問題時(shí),可及時(shí)跟進(jìn)處理。
高擴(kuò)展的實(shí)踐方案
1、合理的分層架構(gòu):比如上面談到的互聯(lián)網(wǎng)最常見的分層架構(gòu),另外還能進(jìn)一步按照數(shù)據(jù)訪問層、業(yè)務(wù)邏輯層對(duì)微服務(wù)做更細(xì)粒度的分層 (但是需要評(píng)估性能,會(huì)存在網(wǎng)絡(luò)多一跳的情況)。 2、存儲(chǔ)層的拆分:按照業(yè)務(wù)維度做垂直拆分、按照數(shù)據(jù)特征維度進(jìn)一步做水平拆分(分庫分表)。 3、業(yè)務(wù)層的拆分:最常見的是按照業(yè)務(wù)維度拆(比如電商場景的商品服務(wù)、訂單服務(wù)等), 也可以按照核心接口和非核心接口拆,還可以按照請求源拆(比如To C和To B,APP和H5)。
總結(jié)
1、最簡單的系統(tǒng)設(shè)計(jì)滿足業(yè)務(wù)需求和流量現(xiàn)狀,選擇最熟悉的技術(shù)體系。
2、隨著流量的增加和業(yè)務(wù)的變化,修正架構(gòu)中存在問題的點(diǎn),如單點(diǎn)問題,橫向擴(kuò)展問題,性能無法滿足需求的組件。
在這個(gè)過程中,選擇社區(qū)成熟的、團(tuán)隊(duì)熟悉的組件幫助我們解決問題,在社區(qū)沒有合適解決方案的前提下才會(huì)自己造輪子。
3、當(dāng)對(duì)架構(gòu)的小修小補(bǔ)無法滿足需求時(shí),考慮重構(gòu)、重寫等大的調(diào)整方式以解決現(xiàn)有的問題。
本篇文章就到這里了,希望能夠給你帶來幫助,也希望您能夠多多關(guān)注腳本之家的更多內(nèi)容!
相關(guān)文章
Java如何將字符串String轉(zhuǎn)換為整型Int
這篇文章主要介紹了Java如何將字符串String轉(zhuǎn)換為整型Int,文章圍繞主題展開詳細(xì)的內(nèi)容介紹,具有一定的參考價(jià)值,需要的朋友可以參考一下2022-08-08Java 實(shí)現(xiàn)網(wǎng)絡(luò)爬蟲框架詳細(xì)代碼
這篇文章主要介紹了Java 實(shí)現(xiàn)網(wǎng)絡(luò)爬蟲框架,主要是用于爬取網(wǎng)絡(luò)上一些內(nèi)容,比如超鏈接之類的,需要的朋友可以參考下面文章內(nèi)容2021-09-09mybatis-plus中wrapper的用法實(shí)例詳解
本文給大家介紹了mybatis-plus中wrapper的用法,包括條件構(gòu)造器關(guān)系、項(xiàng)目實(shí)例及具體使用操作,本文通過實(shí)例代碼給大家介紹的非常詳細(xì),需要的朋友可以參考下2022-02-02SpringCloud超詳細(xì)講解負(fù)載均衡組件Ribbon源碼
在微服務(wù)中,對(duì)服務(wù)進(jìn)行拆分之后,必然會(huì)帶來微服務(wù)之間的通信需求,而每個(gè)微服務(wù)為了保證高可用性,又會(huì)去部署集群,那么面對(duì)一個(gè)集群微服務(wù)進(jìn)行通信的時(shí)候,如何進(jìn)行負(fù)載均衡也是必然需要考慮的問題2022-07-07Java微信公眾平臺(tái)之群發(fā)接口(高級(jí)群發(fā))
這篇文章主要為大家詳細(xì)介紹了Java微信公眾平臺(tái)之群發(fā)接口,高級(jí)群發(fā)功能,具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2018-05-05Java 回調(diào)機(jī)制(CallBack) 詳解及實(shí)例代碼
這篇文章主要介紹了 Java 回調(diào)機(jī)制(CallBack) 詳解及實(shí)例代碼的相關(guān)資料,需要的朋友可以參考下2017-02-02springboot vue完成發(fā)送接口請求顯示響應(yīng)頭信息
這篇文章主要為大家介紹了springboot+vue完成發(fā)送接口請求顯示響應(yīng)頭信息,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2022-05-05Maven報(bào)錯(cuò)之導(dǎo)入Junit包來實(shí)現(xiàn)@Test注解問題
這篇文章主要介紹了Maven報(bào)錯(cuò)之導(dǎo)入Junit包來實(shí)現(xiàn)@Test注解問題,具有很好的參考價(jià)值,希望對(duì)大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2023-11-11