摘要:用線程池執(zhí)行異步任務(wù)為了減少阻塞時(shí)間,加快響應(yīng)速度,把無需返回結(jié)果的操作變成異步任務(wù),用線程池來執(zhí)行,這是提高性能的一種手段。疲于奔命的模式,做不好大型服務(wù)端開發(fā),也難以做好各種領(lǐng)域的開發(fā)。
1. 用線程池執(zhí)行異步任務(wù)
為了減少阻塞時(shí)間,加快響應(yīng)速度,把無需返回結(jié)果的操作變成異步任務(wù),用線程池來執(zhí)行,這是提高性能的一種手段。
你可能要驚訝了,這么做不對(duì)嗎?
首先,我們把異步任務(wù)分為兩種:
務(wù)必成功執(zhí)行的
不成功就放棄
顯然大多數(shù)時(shí)候都是第一種。那么當(dāng)你把任務(wù)丟給線程池,你知道它完成了沒有嗎?
如果服務(wù)器宕機(jī)、升級(jí)或重啟,那些尚未完成或還在排隊(duì)的任務(wù)就丟了。后果是,用戶在促銷活動(dòng)中搶到的優(yōu)惠券,沒有發(fā)給用戶。更嚴(yán)重的后果是,一個(gè)訂單在送往倉(cāng)庫(kù)系統(tǒng)的途中消失了。
我推薦的做法是把任務(wù)投遞到消息中間件,讓它分發(fā)給消息消費(fèi)者來執(zhí)行(消費(fèi)者可能是發(fā)送者自身)。
消息中間件可以要求消費(fèi)者在完成任務(wù)后通知中間件,否則就重新分發(fā)消息,直到收到任務(wù)已完成的通知。
如果中間件沒這種功能,可以讓應(yīng)用要求消費(fèi)者在完成任務(wù)后回發(fā)一個(gè)"任務(wù)已完成"的消息,但應(yīng)用不能同步等待這一消息,否則異步就退化為同步了。
更重要的是,消息中間件有持久化功能,即使宕機(jī)也不丟消息,而且消息中間件可以長(zhǎng)期不升級(jí)、不重啟。消息中間件的缺點(diǎn)是,對(duì)失敗情況的處理難以定制化——你可能想定制重試間隔、重試次數(shù)等細(xì)節(jié)。
換個(gè)角度來看,要解決丟任務(wù)的問題,你不一定要用消息中間件。你可以在應(yīng)用代碼中把任務(wù)和完成狀態(tài)保存到數(shù)據(jù)庫(kù)中,用線程池執(zhí)行,在完成后更新狀態(tài)。這是不是很像作業(yè)調(diào)度(例如Quartz)呢?是的。
然而,有些任務(wù)確實(shí)是可有可無的,例如『刷新一個(gè)不重要的緩存』的任務(wù),那么就隨便丟到線程池吧。
2. 日志采用同步模式我們知道,性能瓶頸通常都是I/O,尤其是數(shù)據(jù)庫(kù)的I/O。因此我們用了緩存,速度蹬的一下竄上來了——不一定哦。
用緩存把I/O變成了內(nèi)存計(jì)算,最大瓶頸消除,速度上升一個(gè)數(shù)量級(jí)。在這個(gè)數(shù)量級(jí),一些原本不重要的因素開始產(chǎn)生影響了。
日志是一種I/O啊,雖然順序?qū)懘疟P很快,但還是比內(nèi)存計(jì)算要慢啊。更糟的是,一個(gè)線程寫日志時(shí),另一個(gè)線程必須等它寫完才能接著寫,否則日志會(huì)亂,當(dāng)日志量較大時(shí),就stop the world了。
所以當(dāng)你的系統(tǒng)性能高到一定程度,就要對(duì)日志做性能優(yōu)化了(有過提高3倍QPS的案例),兩個(gè)常見辦法:
少打日志
異步模式
今天少打日志,明天排查bug就想哭。所以主要靠異步模式。
Logback可以通過配置(網(wǎng)上搜一搜),在RollingFileAppender上套一個(gè)AsyncAppender,實(shí)際上就是加了個(gè)緩沖隊(duì)列,變成了批量寫磁盤。缺點(diǎn)是無法看到最新日志(還沒寫磁盤)。queueSize默認(rèn)是256,即使設(shè)為16,也有明顯的性能提升,還緩和了不能及時(shí)看到最新日志的問題。
Log4j 2的異步模式有更深入的優(yōu)化,是否選用,以測(cè)試數(shù)據(jù)為準(zhǔn)。
3. 沒有超時(shí)設(shè)置網(wǎng)絡(luò)忘記設(shè)超時(shí),系統(tǒng)隨時(shí)可能掛。
每一個(gè)網(wǎng)絡(luò)操作,都記得設(shè)置超時(shí)時(shí)間,超過這個(gè)時(shí)間就放棄。訪問分布式緩存也如此。
如果不設(shè)超時(shí),可能會(huì)等到天荒地老。網(wǎng)絡(luò),就是這么不確定。
4. 沒有統(tǒng)計(jì)緩存命中率一個(gè)命中率低下的緩存,不如沒有。雖然LRU算法很好用,但未必沒有例外情況。頻繁作廢的數(shù)據(jù)、大體積數(shù)據(jù)都可能是負(fù)擔(dān)。
統(tǒng)計(jì)緩存命中率的實(shí)現(xiàn)辦法可以是內(nèi)存里計(jì)數(shù),定期寫到數(shù)據(jù)庫(kù)或文件;也可以是把命中情況打到日志里,日后匯總統(tǒng)計(jì)。也可能有更精巧的實(shí)現(xiàn)。
當(dāng)你的系統(tǒng)進(jìn)入精耕細(xì)作時(shí)代,這個(gè)問題必然擺上案頭。
5. 沒有統(tǒng)計(jì)緩存響應(yīng)時(shí)間緩存一定快嗎?我真的見過不快的。分布式緩存要經(jīng)由網(wǎng)絡(luò),網(wǎng)絡(luò)抖一抖,緩存抖三抖;還依賴運(yùn)維,運(yùn)維抖一抖,緩存抖三抖。此事之微妙,不可不察也。
留個(gè)心,設(shè)個(gè)超時(shí),記個(gè)響應(yīng)時(shí)間。一個(gè)簡(jiǎn)單辦法是,當(dāng)響應(yīng)時(shí)間過長(zhǎng)時(shí),打一行日志,正常情況不打日志。這樣既留了記錄,又不產(chǎn)生過多日志。
6. 單一的緩存模式中央分布式緩存是由緩存中間件組成的集群,一致性較好,緩存的很快會(huì)同步到所有副本。但是畢竟要經(jīng)由網(wǎng)絡(luò),延遲為亞毫秒級(jí),而且負(fù)載聚集到中間件,可能因網(wǎng)絡(luò)擁塞或機(jī)器負(fù)載高而出現(xiàn)性能波動(dòng)。
為了進(jìn)一步提高部分業(yè)務(wù)的性能和穩(wěn)定性,可能要輔以本地緩存。
緩存要有過期策略,如果使用了Guava Cache,可以選擇expireAfterAccess(不常用)、expireAfterWrite或refreshAfterWrite策略:
expire是先丟棄舊數(shù)據(jù),再?gòu)臄?shù)據(jù)庫(kù)加載新數(shù)據(jù),期間讓數(shù)據(jù)庫(kù)承擔(dān)壓力,適用于一般情況。
refresh是在異步加載新數(shù)據(jù)完成前,一直保留舊數(shù)據(jù),能始終為數(shù)據(jù)庫(kù)擋住壓力,適用于高壓情況。
各個(gè)應(yīng)用實(shí)例的本地緩存是獨(dú)立的,舊數(shù)據(jù)的作廢依賴于過期策略。作為改進(jìn),可以利用消息隊(duì)列,一個(gè)實(shí)例廣播消息說某數(shù)據(jù)作廢了,其他實(shí)例紛紛自檢。這是準(zhǔn)實(shí)時(shí)同步。
緩存的更新方式也影響著性能,@左耳朵耗子 的緩存更新的套路很好地介紹了三種套路,現(xiàn)在我來對(duì)比一下:
Cache Aside Pattern: 應(yīng)用程序在數(shù)據(jù)庫(kù)和緩存之間周旋,以數(shù)據(jù)庫(kù)為準(zhǔn)。適合一般情況,因此最常用。
Read/Write Through Pattern: 應(yīng)用只讀寫緩存,緩存同步寫回?cái)?shù)據(jù)庫(kù)(同步是指應(yīng)用等待著寫回完成)。理論性能略高一些。
Write Behind Caching Pattern: 應(yīng)用只讀寫緩存,緩存異步寫回?cái)?shù)據(jù)庫(kù)(應(yīng)用不等待寫回完成,緩存若宕機(jī)將丟數(shù)據(jù))。理論性能最高,如果有Write Ahead Logging(Redis AOF或Apache Ignite都可以)特性,可避免丟數(shù)據(jù),但略為降低性能。
7. 分布式緩存加鎖有的系統(tǒng)步入精耕細(xì)作時(shí)代后,想避免一種情況——緩存作廢時(shí),很多應(yīng)用實(shí)例同時(shí)訪問數(shù)據(jù)庫(kù),加重負(fù)載,而且浪費(fèi)資源。于是有了給緩存加鎖的方案。
簡(jiǎn)單版是每個(gè)實(shí)例內(nèi)部設(shè)鎖,某條數(shù)據(jù)只許一個(gè)線程去數(shù)據(jù)庫(kù)取。復(fù)雜版是把鎖設(shè)在分布式緩存中,某條數(shù)據(jù)只許一個(gè)實(shí)例去數(shù)據(jù)庫(kù)取,然后放入緩存讓其他實(shí)例用。
復(fù)雜版的想法是好的,但注意,鎖要設(shè)置超時(shí)(還記得我上文說的嗎),否則萬一持有鎖的實(shí)例發(fā)生問題,就全體耽誤了。即使設(shè)了超時(shí),也可能全體實(shí)例一直等待超時(shí),浪費(fèi)時(shí)間。所以這種方案不一定好,需以測(cè)試數(shù)據(jù)為準(zhǔn)。
8. 疲于奔命很多公司經(jīng)常加班,實(shí)際上效率低下、也不持久,只能復(fù)制既有經(jīng)驗(yàn),靠不停換人來維持,其后果就是:需求混亂、bug巨多、創(chuàng)新乏力。
要把技術(shù)搞好,需要有條不紊,遇變不亂,持久輸出。疲于奔命的模式,做不好大型服務(wù)端開發(fā),也難以做好各種領(lǐng)域的開發(fā)。
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://specialneedsforspecialkids.com/yun/65010.html
摘要:用線程池執(zhí)行異步任務(wù)為了減少阻塞時(shí)間,加快響應(yīng)速度,把無需返回結(jié)果的操作變成異步任務(wù),用線程池來執(zhí)行,這是提高性能的一種手段。疲于奔命的模式,做不好大型服務(wù)端開發(fā),也難以做好各種領(lǐng)域的開發(fā)。 1. 用線程池執(zhí)行異步任務(wù) 為了減少阻塞時(shí)間,加快響應(yīng)速度,把無需返回結(jié)果的操作變成異步任務(wù),用線程池來執(zhí)行,這是提高性能的一種手段。 你可能要驚訝了,這么做不對(duì)嗎? 首先,我們把異步任務(wù)分...
摘要:關(guān)于緩存熱點(diǎn)重建原文說到在緩存失效的瞬間,有大量線程來重建緩存,造成后端負(fù)載加大,甚至可能會(huì)讓應(yīng)用崩潰,并給出互斥鎖和永遠(yuǎn)不過期兩種候選方案。即使繞過互斥鎖,也不會(huì)產(chǎn)生什么不好的后果,因?yàn)楦戮彺媸且粋€(gè)冪等操作。 向大家推薦這篇文章——Redis架構(gòu)之防雪崩設(shè)計(jì):網(wǎng)站不宕機(jī)背后的兵法 (另外推薦我去年的短文作為餐前點(diǎn)心——略談服務(wù)端緩存設(shè)計(jì)) 《Redis架構(gòu)之防雪崩設(shè)計(jì)》這篇文章(下...
摘要:我們整個(gè)監(jiān)控的部分,沒有采用社區(qū)流行的,而是自己實(shí)現(xiàn)了一套。但是對(duì)于前端來說,只暴露一個(gè)入口,引入一個(gè)反代即可。簡(jiǎn)介是一個(gè)為了讓部署微服務(wù)更加便捷而誕生的現(xiàn)代反向代理負(fù)載均衡工具。配置熱更新,支持多種后端。將請(qǐng)求轉(zhuǎn)發(fā)到統(tǒng)一認(rèn)證服務(wù)。 前言 對(duì)于監(jiān)控這塊,我們基于prometheus實(shí)現(xiàn),當(dāng)然做了大量的優(yōu)化,包括前面所講到的配置接口化。我們整個(gè)監(jiān)控的UI部分,沒有采用社區(qū)流行的grafa...
摘要:我們整個(gè)監(jiān)控的部分,沒有采用社區(qū)流行的,而是自己實(shí)現(xiàn)了一套。但是對(duì)于前端來說,只暴露一個(gè)入口,引入一個(gè)反代即可。簡(jiǎn)介是一個(gè)為了讓部署微服務(wù)更加便捷而誕生的現(xiàn)代反向代理負(fù)載均衡工具。配置熱更新,支持多種后端。將請(qǐng)求轉(zhuǎn)發(fā)到統(tǒng)一認(rèn)證服務(wù)。 前言 對(duì)于監(jiān)控這塊,我們基于prometheus實(shí)現(xiàn),當(dāng)然做了大量的優(yōu)化,包括前面所講到的配置接口化。我們整個(gè)監(jiān)控的UI部分,沒有采用社區(qū)流行的grafa...
閱讀 2574·2021-09-30 09:48
閱讀 2564·2019-08-30 14:10
閱讀 2708·2019-08-29 11:22
閱讀 1837·2019-08-26 13:51
閱讀 2276·2019-08-26 12:02
閱讀 2415·2019-08-23 16:06
閱讀 3548·2019-08-23 14:06
閱讀 1093·2019-08-23 13:56