高并發(fā)服務(wù)的幾條優(yōu)化經(jīng)驗(yàn)

如何優(yōu)化高并發(fā)服務(wù),這里指的是qps在20萬(wàn)以上的在線服務(wù),注意不是離線服務(wù),在線服務(wù)會(huì)存哪些挑戰(zhàn)呢？

無(wú)法做離線緩存,所有的數(shù)據(jù)都是實(shí)時(shí)讀的

大量的請(qǐng)求會(huì)打到線上服務(wù),對(duì)于服務(wù)的應(yīng)時(shí)間要求較高,一般都是限制要求在300ms以?xún)?nèi),如果超過(guò)這個(gè)時(shí)間那么對(duì)用戶(hù)造成的體驗(yàn)就會(huì)急劇降

數(shù)據(jù)量較大,單次如果超過(guò)50W的qps,單條1kb,50萬(wàn)就是5GB了,1分鐘30G,對(duì)于底層的數(shù)據(jù)存儲(chǔ)與問(wèn)都有巨大的壓力~

如何應(yīng)對(duì)這些棘手的問(wèn)題,本篇博客來(lái)討論一下

一：向關(guān)系型數(shù)據(jù)庫(kù) say no

一個(gè)真正的大型互聯(lián)網(wǎng)面向c端的服務(wù)都不會(huì)直接使用數(shù)據(jù)庫(kù)作為自己的存儲(chǔ)系統(tǒng),無(wú)論你是采用的是分庫(kù)分表還是底層用了各種優(yōu)秀的連接池等,mysql/oracle在面對(duì)大型在線服務(wù)是存在天然的劣勢(shì),再如何優(yōu)化,也難以抵擋qps大于50萬(wàn)流量帶來(lái)的沖擊。所以換個(gè)思路,我們必須使用nosql類(lèi)緩存系統(tǒng),比如redis/mermCache等作為自己的"數(shù)據(jù)庫(kù)",而mysql等關(guān)系型數(shù)據(jù)庫(kù)只是一種兜底,用于異步去寫(xiě)作為數(shù)據(jù)查詢(xún)的備份系統(tǒng)。

場(chǎng)景舉例:京東雙11主會(huì)場(chǎng),上架了部分商品,這部分商品都是在會(huì)場(chǎng)開(kāi)始上架的時(shí)候直接寫(xiě)入redis中的,當(dāng)上架完成之后,通過(guò)異步消息寫(xiě)入到mysql中。面向c端的查詢(xún)都是直接讀redis,而不是數(shù)據(jù)庫(kù).而b端的查詢(xún),可以走數(shù)據(jù)庫(kù)去查詢(xún)。這部分流量不是很高,數(shù)據(jù)庫(kù)絕對(duì)可以抵擋的住。

二：多級(jí)緩存

都知道緩存是高并發(fā)提高性能的利器之一。而如何使用好緩存進(jìn)而利用好多級(jí)緩存,是需要我們?nèi)ニ伎嫉膯?wèn)題。

redis目前是緩存的第一首選.單機(jī)可達(dá)6-8萬(wàn)的qps,在面對(duì)高并發(fā)的情況下,我們可以手動(dòng)的水平擴(kuò)容,以達(dá)到應(yīng)對(duì)qps可能無(wú)線增長(zhǎng)的場(chǎng)景。但是這種做法也存在弊端,因?yàn)閞edis是單線程的,并且會(huì)存在熱點(diǎn)問(wèn)題。雖然redis內(nèi)部用crc16算法做了hash打散,但是同一個(gè)key還是會(huì)落到一個(gè)單獨(dú)的機(jī)器上,就會(huì)使機(jī)器的負(fù)載增加,redis典型的存在緩存擊穿和緩存穿透兩個(gè)問(wèn)題,尤其在秒殺這個(gè)場(chǎng)景中,如果要解決熱點(diǎn)問(wèn)題,就變的比較棘手。這個(gè)時(shí)候多級(jí)緩存就必須要考慮了,典型的在秒殺的場(chǎng)景中,單sku商品在售賣(mài)開(kāi)始的瞬間,qps會(huì)急劇上升.而我們這時(shí)候需要用memeryCache來(lái)?yè)跻粚?memeryCache是多線程的,比redis擁有更好的并發(fā)能力,并且它是天然可以解決熱點(diǎn)問(wèn)題的。有了memeryCache,我們還需要localCache，本地緩存,這是一種以?xún)?nèi)存換速度的方式。本地緩存會(huì)接入用戶(hù)的第一層請(qǐng)求,如果它找不到,接下來(lái)走memeryCache，然后走redis，這套流程下來(lái)可以擋住百萬(wàn)的qps.

三：多線程

我記得在剛開(kāi)始入行的時(shí)候,每次面試都會(huì)被問(wèn)到多線程,那時(shí)候是一臉懵逼,多線程有這么厲害嗎?干嘛都說(shuō)多線程,為什么要使用多線程,不用行不行?要講明這個(gè)道理,我先來(lái)說(shuō)一個(gè)實(shí)例.曾經(jīng)我優(yōu)化過(guò)一個(gè)接口,很典型的一個(gè)場(chǎng)景。原始的方式是循環(huán)一個(gè)30-40萬(wàn)的list,list執(zhí)行的操作很簡(jiǎn)單,就是讀redis的數(shù)據(jù),讀一次大概需要3ms左右,這是同步的方式，在預(yù)覽環(huán)境測(cè)試,直接30秒+超時(shí)。后來(lái)優(yōu)化的方式就是把原有的同步調(diào)用改為線程池調(diào)用,線程池里的線程數(shù)或阻塞隊(duì)列大小需要自己調(diào)優(yōu),最后實(shí)測(cè)接口rt只需要3秒。足以見(jiàn)多線程的威力。在多核服務(wù)的今天,如果還不用多線程就是對(duì)服務(wù)器資源的一種浪費(fèi)。這里需要說(shuō)一句,使用多線層一定要做好監(jiān)控,你需要隨時(shí)知道線程的狀態(tài),如果線程數(shù)和queueSize設(shè)置的不恰當(dāng),將會(huì)嚴(yán)重影響業(yè)務(wù)~ 當(dāng)然多線程也要分場(chǎng)景,如果為了多線程而多線程反而是一種浪費(fèi),因?yàn)槎嗑€程調(diào)度的時(shí)候會(huì)造成線程在內(nèi)核態(tài)和用戶(hù)態(tài)之間來(lái)回切換,如果使用不當(dāng)反而會(huì)有反作用

四: 降級(jí)和熔斷

降級(jí)和熔斷是一種自我保護(hù)措施,這和電路上的熔斷器的基本原理是一樣的,防止電流過(guò)大引起火災(zāi)等,面對(duì)不可控的巨大流量請(qǐng)求很有可能會(huì)擊垮服務(wù)器的數(shù)據(jù)庫(kù)或者redis,使服務(wù)器宕機(jī)或者癱瘓?jiān)斐刹豢赏旎氐膿p失。因?yàn)槲覀兎?wù)的本身需要有防御機(jī)制,以抵擋外部服務(wù)對(duì)于自身的侵入導(dǎo)致服務(wù)受損引起連帶反應(yīng)。降級(jí)和熔斷有所不同，兩者的區(qū)別在于降級(jí)是將一些線上主鏈路的功能關(guān)閉,不影響到主鏈路.熔斷的話,是指A請(qǐng)求B,B檢測(cè)到服務(wù)流量多大啟動(dòng)了熔斷,那么請(qǐng)求會(huì)直接進(jìn)入熔斷池,直接返回失敗。如何抉擇使用哪一個(gè)需要在實(shí)際中結(jié)合業(yè)務(wù)場(chǎng)景來(lái)考慮.

五: 優(yōu)化IO

很多人都會(huì)忽視IO這個(gè)問(wèn)題,頻繁的建聯(lián)和斷聯(lián)都是對(duì)系統(tǒng)的重負(fù)。在并發(fā)請(qǐng)求中,如果存在單個(gè)請(qǐng)求的放大效那么將會(huì)使io呈指數(shù)倍增加。舉個(gè)例子,比如主會(huì)場(chǎng)的商品信息,如果需要商品的某個(gè)具體的詳情,而這個(gè)詳情需要調(diào)用下游來(lái)單個(gè)獲取.隨著主會(huì)場(chǎng)商品的熱賣(mài),商品越來(lái)越多,一次就要經(jīng)過(guò)商品數(shù)X下游請(qǐng)求的數(shù)量,在海量的qps請(qǐng)求下,IO數(shù)被占據(jù),大量的請(qǐng)求被阻塞,接口的響應(yīng)速度就會(huì)呈指數(shù)級(jí)下降。所以需要批量的請(qǐng)求接口,所有的優(yōu)化為一次IO

六: 慎用重試

重試作為對(duì)臨時(shí)異常的一種處理的常見(jiàn)手法,常見(jiàn)應(yīng)對(duì)的方式是請(qǐng)求某個(gè)服務(wù)失敗或者寫(xiě)數(shù)據(jù)庫(kù)了重新再試,使用重試一定要注意以下幾點(diǎn)

控制好重試次數(shù)

重試的間隔時(shí)間得衡量好

是否重試要做到配置化。之前我們線上出了一個(gè)bug,kafka消費(fèi)出現(xiàn)了嚴(yán)重的lag,單詞消耗時(shí)間是10幾秒,看代碼之后發(fā)現(xiàn)是重試的次數(shù)過(guò)多導(dǎo)致的,并且次數(shù)還不支持配置化修改,所以當(dāng)時(shí)的做法只能是臨時(shí)改代碼后上線.重試作為一種業(yè)務(wù)的二次嘗試,極大提升了程序的請(qǐng)求success,但是也要注意以上幾點(diǎn)。

七:邊界case的判斷和兜底

作為互聯(lián)網(wǎng)老手,很多人寫(xiě)出的代碼都不錯(cuò),但是在經(jīng)歷過(guò)幾輪的故障review之后發(fā)現(xiàn)很多釀成重大事故的代碼背后都是缺少對(duì)一些邊界問(wèn)題的處理,所犯的錯(cuò)誤非常簡(jiǎn)單,但是往往就是這些小問(wèn)題就能釀成大事故.曾經(jīng)review過(guò)一次重大的事故,后來(lái)發(fā)現(xiàn)最終的原因居然是沒(méi)有對(duì)空數(shù)組進(jìn)行判空,導(dǎo)致傳入下游的rpc是空的,下游直接返回全量的業(yè)務(wù)數(shù)據(jù),影響數(shù)百萬(wàn)用戶(hù)。這個(gè)代碼改動(dòng)起來(lái)很簡(jiǎn)單,但是是令人需要反省的,小小的不足釀成了大禍

八:學(xué)會(huì)優(yōu)雅的打印日志

日志作為追溯線上問(wèn)題的最佳利器,可謂保留bug現(xiàn)場(chǎng)的唯一來(lái)源。雖然有arthas這樣的利器方便我們排查問(wèn)題,但是對(duì)于一些比較復(fù)雜的場(chǎng)景,還是需要日志來(lái)記錄程序的數(shù)據(jù).但是在高流量的場(chǎng)景中,如果全量打印日志對(duì)于線上來(lái)說(shuō)就是一種災(zāi)難,有以下缺點(diǎn):

嚴(yán)重占用磁盤(pán),估算以下,如果接口的qps在20萬(wàn)左右,日志一秒就幾千兆,一天下來(lái)就是上千GB

大量的日志需要輸出,占用了程序IO,增加了接口的RT(響應(yīng)時(shí)間) 如果需要解決這個(gè)問(wèn)題,我們可以利用限流組件來(lái)實(shí)現(xiàn)一個(gè)基于限流的日志組件,令牌桶算法可以限制打印日志的流量,比如一秒只允許打印一條日志 - 基于白名單的日志打印,線上配置了白名單用戶(hù)才可以打印出來(lái),節(jié)省了大量了無(wú)效日志輸出

總結(jié)

本篇博客討論了高并發(fā)服務(wù)在面對(duì)大流量時(shí)的一些基本注意事項(xiàng)和應(yīng)對(duì)的點(diǎn),當(dāng)然實(shí)際線上的比前的更復(fù)雜,這里只是給出幾條建議,希望我們?cè)诟卟l(fā)的路上保持敬畏,繼續(xù)探索.更好的深耕c端服務(wù)做更好的互聯(lián)網(wǎng)應(yīng)用,加油！

審核編輯 ：李倩