可用性及穩(wěn)定性保障主要是針對(duì)我們的大促活動(dòng)而言，如何在承接億級(jí)流量的同時(shí)保證系統(tǒng)的可用及穩(wěn)定撩笆。這樣的保障不僅是在技術(shù)上的保障捺球，也需要流程上的保障。
整體挑戰(zhàn)
應(yīng)對(duì)流程
技術(shù)優(yōu)化
緩存篇
- 活動(dòng)庫存使用緩存
加快扣庫存操作夕冲，通過分布式任務(wù)異步刷入數(shù)據(jù)庫（數(shù)據(jù)最終一致）
- 活動(dòng)規(guī)則兩級(jí)緩存
活動(dòng)規(guī)則對(duì)象復(fù)雜氮兵，每次從redis讀取時(shí)不僅會(huì)對(duì)IO造成一定的壓力，在反序列化上也會(huì)增加CPU負(fù)載歹鱼，通過本地一分鐘緩存泣栈，降低IO耗時(shí)及CPU負(fù)載。規(guī)則的超時(shí)時(shí)間也設(shè)定在活動(dòng)整體有效時(shí)間醉冤，規(guī)則有變動(dòng)則會(huì)更新緩存秩霍，這樣就不需要在讀取的時(shí)候訪問數(shù)據(jù)庫。
- 領(lǐng)券記錄緩存
主要是防止用戶重復(fù)訪問活動(dòng)頁蚁阳，直接返回用戶已領(lǐng)券的記錄給到用戶。
- 緩存失效時(shí)間梳理
失效時(shí)間的處理很有考究鸽照，既要考慮到集群的容量螺捐，也要考慮到用戶場景，失效時(shí)間太長，對(duì)集群容量有壓力定血，失效時(shí)間太短對(duì)數(shù)據(jù)庫有壓力赔癌。最好是在用戶進(jìn)入場景到離開場景的時(shí)間內(nèi)保持緩存數(shù)據(jù)可用。
- 命中率（暫未有優(yōu)化）
獨(dú)立數(shù)據(jù)庫
- 活動(dòng)數(shù)據(jù)庫集群單獨(dú)部署
一主兩從澜沟，兩從分別在桂橋機(jī)房和南匯機(jī)房灾票，在讀的場景下避免跨機(jī)房讀從庫。
- 慢SQL優(yōu)化
這里的教訓(xùn)特別大茫虽，第一次2億流量直接導(dǎo)致數(shù)據(jù)庫不可用刊苍，原因在扣庫存的活動(dòng)表沒有索引，當(dāng)時(shí)的活動(dòng)不超過100條濒析，相關(guān)開發(fā)人員覺得沒有必要加索引正什，在小流量的場景下倒是沒有問題，在流量大的情況下會(huì)引起激烈的GAP鎖競爭号杏。
服務(wù)配置優(yōu)化
- 線程池優(yōu)化
點(diǎn)評(píng)內(nèi)部的服務(wù)框架是pigeon婴氮，比較和dubbo類似，框架默認(rèn)會(huì)有大小為50的慢服務(wù)線程池盾致，服務(wù)在一定的時(shí)間內(nèi)處理時(shí)間超過閾值就會(huì)落入到慢線程池主经，實(shí)踐證明慢線程池在很多場景下反而加劇了調(diào)用方調(diào)用超時(shí)。比如緩存或者第三方服務(wù)在壓力比較大時(shí)庭惜，提供的服務(wù)會(huì)超出慢線程池定的閾值罩驻，這樣可能會(huì)導(dǎo)致所有的請(qǐng)求都會(huì)落到慢線程池（尤其是緩存訪問變慢的場景）
固定線程池大小，coreSize和maxSize大小保持一致蜈块，設(shè)定在200鉴腻，減少線程池回收及創(chuàng)建時(shí)間。（因大部分服務(wù)都服務(wù)IO密集型百揭，線程數(shù)可根據(jù)壓測結(jié)果適當(dāng)調(diào)大）
合理配置隊(duì)列大小 目前是拍了腦袋定在了400爽哎，目的是提高服務(wù)的吞吐量。合理性待考究器一。
超時(shí)時(shí)間梳理
超時(shí)時(shí)間的梳理主要是解決物盡其用的場景课锌，怎么在有限的服務(wù)資源下提高系統(tǒng)的可用性。
超時(shí)設(shè)定分為服務(wù)超時(shí)以及http的so_timeout祈秕，超時(shí)的設(shè)定會(huì)在極端情況下反應(yīng)出你的系統(tǒng)的極端負(fù)載渺贤，打個(gè)比方，一個(gè)查詢接口的SLA：avg在200ms,可承受1000的qps请毛，一旦這個(gè)服務(wù)出現(xiàn)故障志鞍，導(dǎo)致avg升到了400ms，部分請(qǐng)求時(shí)長超過了2s方仿，如果你的超時(shí)時(shí)間設(shè)定在了2s固棚，那將會(huì)出現(xiàn)很多線程被超過2s或者即將到達(dá)2s的請(qǐng)求占用统翩，用于其他正常請(qǐng)求無法獲得處理線程，最終會(huì)導(dǎo)致你的服務(wù)性能急劇下降此洲。
在者考慮到調(diào)用端的性能厂汗，服務(wù)的超時(shí)時(shí)間設(shè)定的太長會(huì)使增加整個(gè)調(diào)用鏈路時(shí)間，不僅降低用戶體驗(yàn)呜师，還會(huì)占用調(diào)用端的線程資源娶桦。
如何確定超時(shí)時(shí)間？實(shí)踐是999線加上avg汁汗，大部分場景都會(huì)覆蓋到衷畦，如果服務(wù)的穩(wěn)定性不是很高，可適當(dāng)加上avg的倍數(shù)碰酝。
為什么選用999線霎匈？選取999線的話可使可用性達(dá)到三個(gè)9。
為什么還要加上avg? 三個(gè)9的可用性這個(gè)要求其實(shí)對(duì)服務(wù)的要求并不高送爸，還需要加上一定的時(shí)長能夠使服務(wù)達(dá)到4個(gè)9或者更高铛嘱。然而這個(gè)一定的時(shí)長我們不能拍腦袋，例如一個(gè)服務(wù)他的avg為100ms袭厂，999線為200毫秒墨吓，我們拍個(gè)腦袋，超時(shí)時(shí)間設(shè)定在了2s纹磺，顯然2s設(shè)定太過高帖烘。當(dāng)然在服務(wù)的資源很充分的情況下你可以不用去考慮這個(gè)超時(shí)時(shí)間，我們是在討論如何在有限的資源下提高系統(tǒng)可用性橄杨。avg是個(gè)參考值秘症，大部分人在設(shè)定超時(shí)時(shí)間的時(shí)候會(huì)考慮到以秒為單位，但是很多服務(wù)的avg都不到50ms式矫，顯然設(shè)定在2秒肯定是不合理的乡摹，這就需要avg這個(gè)考慮值。
future并發(fā)調(diào)用
future并發(fā)調(diào)用一般運(yùn)用在調(diào)用方采转，如果一個(gè)請(qǐng)求里面有多個(gè)服務(wù)調(diào)用聪廉，部分服務(wù)之間并沒有關(guān)聯(lián)，尤其對(duì)外提供聚合服務(wù)的時(shí)候故慈，很多服務(wù)是沒有調(diào)用順序的板熊，這種場景最適合使用future并發(fā)調(diào)用，使用并發(fā)調(diào)用的話察绷，一個(gè)請(qǐng)求里的多個(gè)服務(wù)調(diào)用時(shí)間并不是相加干签，而是變成了耗時(shí)最長的單個(gè)服務(wù)時(shí)間。這樣大大的提高了響應(yīng)時(shí)間拆撼。
MQ優(yōu)化
美團(tuán)點(diǎn)評(píng)內(nèi)部提供RabbitMQ和Mafka(kafka封裝)兩種類型的MQ筒严，基于營銷場景的使用情況（時(shí)效性要求不高丹泉，吞吐量大情萤，可容忍消息丟失）鸭蛙，最終選擇了Mafka。（訂單場景下慎選）
- 同機(jī)房策略
MQ的集群和應(yīng)用同機(jī)房筋岛，應(yīng)用如果北京上海都有部署娶视，那mq的集群也需要兩地部署。這樣應(yīng)用產(chǎn)生的消息發(fā)送到同機(jī)房的mq睁宰，避免專線的耗時(shí)帶來吞吐性能下降肪获。這樣也要求消費(fèi)機(jī)也在相同機(jī)房有部署，將專線影響降到0柒傻。
- 消息異步發(fā)送
同步主要會(huì)帶來一個(gè)mafka內(nèi)部一鎖的競爭孝赫，而且一次是單個(gè)消息發(fā)送，在IO利用率上不是很好红符。異步發(fā)送的話一是無鎖青柄，二是可全并消息批量發(fā)送。 - 增加集群分片及消息者
mafka的一個(gè)分片只能一個(gè)消費(fèi)線程消費(fèi)预侯，如果分片過少致开，那就制約了消費(fèi)線程數(shù)。在消息有堆積的情況下可適當(dāng)增加分片以及消費(fèi)線程萎馅，提高消費(fèi)能力双戳。
