動(dòng)靜分離 與 熱點(diǎn)緩存
點(diǎn)擊上方“程序員大白”，選擇“星標(biāo)”公眾號(hào)
重磅干貨，第一時(shí)間送達(dá)
動(dòng)靜分離
讓系統(tǒng)“快”起來：
1、提高單次請求的效率
2、減少?zèng)]必要的請求
“動(dòng)靜分離”就是瞄著這個(gè)大方向去的。所謂“動(dòng)靜分離”，其實(shí)就是把用戶請求的數(shù)據(jù)（如HTML頁面）劃分為“動(dòng)態(tài)數(shù)據(jù)”和“靜態(tài)數(shù)據(jù)”。簡單來說，“動(dòng)態(tài)數(shù)據(jù)”和“靜態(tài)數(shù)據(jù)”的主要區(qū)別就是看頁面中輸出的數(shù)據(jù)是否和URL、瀏覽者、時(shí)間、地域相關(guān)，以及是否含有Cookie等私密數(shù)據(jù)。
比如說：
1、很多媒體類的網(wǎng)站，某一篇文章的內(nèi)容不管是你訪問還是我訪問，它都是一樣的。所以它就是一個(gè)典型的靜態(tài)數(shù)據(jù)，但是它是個(gè)動(dòng)態(tài)頁面
2、我們?nèi)绻F(xiàn)在訪問淘寶的首頁，每個(gè)人看到的頁面可能都是不一樣的，淘寶首頁中包含了很多根據(jù)訪問者特征推薦的信息，而這些個(gè)性化的數(shù)據(jù)就可以理解為動(dòng)態(tài)數(shù)據(jù)了
也就是所謂“動(dòng)態(tài)”還是“靜態(tài)”，并不是說數(shù)據(jù)本身是否動(dòng)靜，而是數(shù)據(jù)中是否含有和訪問者相關(guān)的個(gè)性化數(shù)據(jù)
如何做靜態(tài)數(shù)據(jù)緩存
1、應(yīng)該把靜態(tài)數(shù)據(jù)緩存到離用戶最近的地方
靜態(tài)數(shù)據(jù)就是那些相對不會(huì)變化的數(shù)據(jù)，因此我們可以把它們緩存起來。常見的就三種: 用戶瀏覽器里、CDN上或者在服務(wù)端的Cache中。應(yīng)該根據(jù)實(shí)際情況，把它們盡量緩存到離用戶最近的地方
2、靜態(tài)化改造就是要直接緩存HTTP連接
靜態(tài)化改造是直接緩存HTTP連接而不是僅僅緩存數(shù)據(jù)，Web代理服務(wù)器根據(jù)請求URL，直接取出對應(yīng)的HTTP響應(yīng)頭和響應(yīng)體然后直接返回，這個(gè)響應(yīng)過程簡單得連HTTP協(xié)議都不用重新組裝，甚至連HTTP請求頭也不需要解析
3、讓誰來緩存靜態(tài)數(shù)據(jù)也很重要
不同語言寫的Cache軟件處理緩存數(shù)據(jù)的效率也各不相同。以Java為例，因?yàn)镴ava系統(tǒng)本身也有其弱點(diǎn)（比如不擅長處理大量連接請求，每個(gè)連接消耗的內(nèi)存較多，Servlet容器解析HTTP協(xié)議較慢），所以你可以不在Java層做緩存，而是直接在Web服務(wù)器層上做，這樣你就可以屏蔽Java語言層面的一些弱點(diǎn)；而相比起來，Web服務(wù)器（如Nginx、Apache、Varnish）也更擅長處理大并發(fā)的靜態(tài)文件請求
如何做動(dòng)靜分離改造
以典型的商品詳情系統(tǒng)為例來詳細(xì)介紹，可以從以下5個(gè)方面來分離出動(dòng)態(tài)內(nèi)容:
URL唯一化: 商品詳情系統(tǒng)天然地就可以做到URL唯一化，比如每個(gè)商品都由ID來標(biāo)識(shí)，那么
http://item.xxx.com/item.htm?id=xxxx就可以作為唯一的URL標(biāo)識(shí)。為什么要URL唯一呢？前面說了我們是要緩存整個(gè)HTTP連接，那么以什么作為Key呢？就以URL作為緩存的Key，例如以id=xxx這個(gè)格式進(jìn)行區(qū)分分離瀏覽者相關(guān)的因素: 瀏覽者相關(guān)的因素包括是否已登錄，以及登錄身份等，這些相關(guān)因素我們可以單獨(dú)拆分出來，通過動(dòng)態(tài)請求來獲取
分離時(shí)間因素: 服務(wù)端輸出的時(shí)間也通過動(dòng)態(tài)請求獲取
異步化地域因素: 詳情頁面上與地域相關(guān)的因素可做成異步方式獲取，當(dāng)然你也可以通過動(dòng)態(tài)請求方式獲取，只是這里通過異步獲取更合適
去掉Cookie: 服務(wù)端輸出的頁面包含的Cookie可以通過代碼軟件來刪除，如Web服務(wù)器Varnish可以通過unset req.http.cookie 命令去掉Cookie。注意，這里說的去掉Cookie并不是用戶端收到的頁面就不含Cookie了，而是說，在緩存的靜態(tài)數(shù)據(jù)中不含有Cookie
分離出動(dòng)態(tài)內(nèi)容之后，如何組織這些內(nèi)容頁就變得非常關(guān)鍵了。這里需要提醒一點(diǎn)，因?yàn)檫@其中很多動(dòng)態(tài)內(nèi)容都會(huì)被頁面中的其他模塊用到，如判斷該用戶是否已登錄、用戶ID是否匹配等，所以這個(gè)時(shí)候我們應(yīng)該將這些信息JSON化（用JSON格式組織這些數(shù)據(jù)），以方便前端獲取
可以用上面介紹的緩存的方式來處理靜態(tài)數(shù)據(jù)
動(dòng)態(tài)內(nèi)容的處理通常有兩種方案：
ESI(Edge Side Includes)（或者SSI）方案: 即在Web代理服務(wù)器上做動(dòng)態(tài)內(nèi)容請求，并將請求插入到靜態(tài)頁面中，當(dāng)用戶拿到頁面時(shí)已經(jīng)是一個(gè)完整的頁面了。這種方式對服務(wù)端性能有些影響，但是用戶體驗(yàn)較好
CSI(Client Side Include)方案: 即單獨(dú)發(fā)起一個(gè)異步JavaScript 請求，以向服務(wù)端獲取動(dòng)態(tài)內(nèi)容。這種方式服務(wù)端性能更佳，但是用戶端頁面可能會(huì)延時(shí)，體驗(yàn)稍差
動(dòng)靜分離的幾種架構(gòu)方案
前面通過改造把靜態(tài)數(shù)據(jù)和動(dòng)態(tài)數(shù)據(jù)做了分離，那么如何在系統(tǒng)架構(gòu)上進(jìn)一步對這些動(dòng)態(tài)和靜態(tài)數(shù)據(jù)重新組合，再完整地輸出給用戶呢？
這就涉及對用戶請求路徑進(jìn)行合理的架構(gòu)了。根據(jù)架構(gòu)上的復(fù)雜度，有3種方案可選
方案1、實(shí)體機(jī)單機(jī)部署
這種方案是將虛擬機(jī)改為實(shí)體機(jī)，以增大Cache的容量，并且采用了一致性Hash分組的方式來提升命中率。這里將Cache分成若干組，是希望能達(dá)到命中率和訪問熱點(diǎn)的平衡。Hash分組越少，緩存的命中率肯定就會(huì)越高，但短板是也會(huì)使單個(gè)商品集中在一個(gè)分組中，容易導(dǎo)致Cache被擊穿，所以我們應(yīng)該適當(dāng)增加多個(gè)相同的分組，來平衡訪問熱點(diǎn)和命中率的問題
這里我給出了實(shí)體機(jī)單機(jī)部署方案的結(jié)構(gòu)圖，如下：
Nginx+Cache+Java結(jié)構(gòu)實(shí)體機(jī)單機(jī)部署
實(shí)體機(jī)單機(jī)部署有以下幾個(gè)優(yōu)點(diǎn)：
1、沒有網(wǎng)絡(luò)瓶頸，而且能使用大內(nèi)存
2、既能提升命中率，又能減少Gzip壓縮
3、減少Cache失效壓力，因?yàn)椴捎枚〞r(shí)失效方式，例如只緩存3秒鐘，過期即自動(dòng)失效
不足之處：
1、這個(gè)方案中，雖然把通常只需要虛擬機(jī)或者容器運(yùn)行的Java應(yīng)用換成實(shí)體機(jī)，優(yōu)勢很明顯，它會(huì)增加單機(jī)的內(nèi)存容量，但是一定程度上也造成了CPU的浪費(fèi)，因?yàn)閱蝹€(gè)的Java進(jìn)程很難用完整個(gè)實(shí)體機(jī)的CPU
2、另外就是，一個(gè)實(shí)體機(jī)上部署了Java應(yīng)用又作為Cache來使用，這造成了運(yùn)維上的高復(fù)雜度，所以這是一個(gè)折中的方案。如果你的公司里，沒有更多的系統(tǒng)有類似需求，那么這樣做也比較合適，如果你們有多個(gè)業(yè)務(wù)系統(tǒng)都有靜態(tài)化改造的需求，那還是建議把Cache層單獨(dú)抽出來公用比較合理
方案2.統(tǒng)一Cache層
所謂統(tǒng)一Cache層，就是將單機(jī)的Cache統(tǒng)一分離出來，形成一個(gè)單獨(dú)的Cache集群。統(tǒng)一Cache層是個(gè)更理想的可推廣方案，該方案的結(jié)構(gòu)圖如下：
將Cache層單獨(dú)拿出來統(tǒng)一管理可以減少運(yùn)維成本，同時(shí)也方便接入其他靜態(tài)化系統(tǒng)。此外，它還有一些優(yōu)點(diǎn)：
1、單獨(dú)一個(gè)Cache層，可以減少多個(gè)應(yīng)用接入時(shí)使用Cache的成本。這樣接入的應(yīng)用只要維護(hù)自己的Java系統(tǒng)就好，不需要單獨(dú)維護(hù)Cache，而只關(guān)心如何使用即可
2、統(tǒng)一Cache的方案更易于維護(hù)，如后面加強(qiáng)監(jiān)控、配置的自動(dòng)化，只需要一套解決方案就行，統(tǒng)一起來維護(hù)升級也比較方便
3、可以共享內(nèi)存，最大化利用內(nèi)存，不同系統(tǒng)之間的內(nèi)存可以動(dòng)態(tài)切換，從而能夠有效應(yīng)對各種攻擊
這種方案雖然維護(hù)上更方便了，但是也帶來了其他一些問題，比如緩存更加集中，導(dǎo)致：
1、Cache層內(nèi)部交換網(wǎng)絡(luò)成為瓶頸
2、緩存服務(wù)器的網(wǎng)卡也會(huì)是瓶頸
3、機(jī)器少風(fēng)險(xiǎn)較大，掛掉一臺(tái)就會(huì)影響很大一部分緩存數(shù)據(jù)
要解決上面這些問題，可以再對Cache做Hash分組，即一組Cache緩存的內(nèi)容相同，這樣能夠避免熱點(diǎn)數(shù)據(jù)過度集中導(dǎo)致新的瓶頸產(chǎn)生
方案3.上CDN
在將整個(gè)系統(tǒng)做動(dòng)靜分離后，我們自然會(huì)想到更進(jìn)一步的方案，就是將Cache進(jìn)一步前移到CDN上，因?yàn)镃DN離用戶最近，效果會(huì)更好。但是要想這么做，有以下幾個(gè)問題需要解決：
1、失效問題，就是緩存時(shí)效的問題。談到靜態(tài)數(shù)據(jù)時(shí)，說過一個(gè)關(guān)鍵詞叫“相對不變”，它的言外之意是“可能會(huì)變化”。比如一篇文章，現(xiàn)在不變，但如果你發(fā)現(xiàn)個(gè)錯(cuò)別字，是不是就會(huì)變化了？如果你的緩存時(shí)效很長，那用戶端在很長一段時(shí)間內(nèi)看到的都是錯(cuò)的。所以，這個(gè)方案中也是，我們需要保證CDN可以在秒級時(shí)間內(nèi)，讓分布在全國各地的Cache同時(shí)失效，這對CDN的失效系統(tǒng)要求很高
2、命中率問題。Cache最重要的一個(gè)衡量指標(biāo)就是“高命中率”，不然Cache的存在就失去了意義。同樣，如果將數(shù)據(jù)全部放到全國的CDN上，必然導(dǎo)致Cache分散，而Cache分散又會(huì)導(dǎo)致訪問請求命中同一個(gè)Cache的可能性降低，那么命中率就成為一個(gè)問題
3、發(fā)布更新問題。如果一個(gè)業(yè)務(wù)系統(tǒng)每周都有日常業(yè)務(wù)需要發(fā)布，那么發(fā)布系統(tǒng)必須足夠簡潔高效，而且你還要考慮有問題時(shí)快速回滾和排查問題的簡便性
從前面的分析來看，將商品詳情系統(tǒng)放到全國的所有CDN節(jié)點(diǎn)上是不太現(xiàn)實(shí)的，因?yàn)榇嬖谑栴}、命中率問題以及系統(tǒng)的發(fā)布更新問題。那么是否可以選擇若干個(gè)節(jié)點(diǎn)來嘗試實(shí)施呢？答案是“可以”，但是這樣的節(jié)點(diǎn)需要滿足幾個(gè)條件：
1、靠近訪問量比較集中的地區(qū)
2、離主站相對較遠(yuǎn)
3、節(jié)點(diǎn)到主站間的網(wǎng)絡(luò)比較好，而且穩(wěn)定
4、節(jié)點(diǎn)容量比較大，不會(huì)占用其他CDN太多的資源
5、節(jié)點(diǎn)不要太多
基于上面幾個(gè)因素，選擇CDN的二級Cache比較合適，因?yàn)槎塁ache數(shù)量偏少，容量也更大，讓用戶的請求先回源的CDN的二級Cache中，如果沒命中再回源站獲取數(shù)據(jù)，部署方式如下圖所示：
使用CDN的二級Cache作為緩存，可以達(dá)到和當(dāng)前服務(wù)端靜態(tài)化Cache類似的命中率，因?yàn)楣?jié)點(diǎn)數(shù)不多，Cache不是很分散，訪問量也比較集中，這樣也就解決了命中率問題，同時(shí)能夠給用戶最好的訪問體驗(yàn)，是當(dāng)前比較理想的一種CDN化方案
除此之外，CDN化部署方案還有以下幾個(gè)特點(diǎn)：
1、把整個(gè)頁面緩存在用戶瀏覽器中
2、如果強(qiáng)制刷新整個(gè)頁面，也會(huì)請求CDN
3、實(shí)際有效請求，只是用戶對“刷新?lián)寣殹卑粹o的點(diǎn)擊
這樣就把90%的靜態(tài)數(shù)據(jù)緩存在了用戶端或者CDN上，當(dāng)真正秒殺時(shí)，用戶只需要點(diǎn)擊特殊的“刷新?lián)寣殹卑粹o，而不需要刷新整個(gè)頁面。這樣一來，系統(tǒng)只是向服務(wù)端請求很少的有效數(shù)據(jù)，而不需要重復(fù)請求大量的靜態(tài)數(shù)據(jù)
秒殺的動(dòng)態(tài)數(shù)據(jù)和普通詳情頁面的動(dòng)態(tài)數(shù)據(jù)相比更少，性能也提升了3倍以上。所以“搶寶”這種設(shè)計(jì)思路，讓我們不用刷新頁面就能夠很好地請求到服務(wù)端最新的動(dòng)態(tài)數(shù)據(jù)
其他注意點(diǎn)
實(shí)現(xiàn)動(dòng)靜分離的幾種架構(gòu)方案，選擇不同會(huì)引入不同的問題
1、比如我們把緩存數(shù)據(jù)從CDN上移到用戶的瀏覽器里，針對秒殺這個(gè)場景是沒問題的，但針對一般的商品可否也這樣做呢？存儲(chǔ)在瀏覽器或CDN上，有多大區(qū)別？
區(qū)別很大！因?yàn)樵贑DN上，我們可以做主動(dòng)失效，而在用戶的瀏覽器里就更不可控，如果用戶不主動(dòng)刷新的話，你很難主動(dòng)地把消息推送給用戶的瀏覽器
2、另外，在什么地方把靜態(tài)數(shù)據(jù)和動(dòng)態(tài)數(shù)據(jù)合并并渲染出一個(gè)完整的頁面也很關(guān)鍵
假如在用戶的瀏覽器里合并，那么服務(wù)端可以減少渲染整個(gè)頁面的CPU消耗
如果在服務(wù)端合并的話，就要考慮緩存的數(shù)據(jù)是否進(jìn)行Gzip壓縮了: 如果緩存Gzip壓縮后的靜態(tài)數(shù)據(jù)可以減少緩存的數(shù)據(jù)量，但是進(jìn)行頁面合并渲染時(shí)就要先解壓，然后再壓縮完整的頁面數(shù)據(jù)輸出給用戶；如果緩存未壓縮的靜態(tài)數(shù)據(jù)，這樣不用解壓靜態(tài)數(shù)據(jù)，但是會(huì)增加緩存容量。雖然這些都是細(xì)節(jié)問題，需要在設(shè)計(jì)架構(gòu)方案時(shí)考慮清楚
熱點(diǎn)數(shù)據(jù)
我們一定要關(guān)注熱點(diǎn)，因?yàn)闊狳c(diǎn)會(huì)對系統(tǒng)產(chǎn)生一系列的影響：
1、熱點(diǎn)請求會(huì)大量占用服務(wù)器處理資源，雖然這個(gè)熱點(diǎn)可能只占請求總量的億分之一，然而卻可能搶占90%的服務(wù)器資源，如果這個(gè)熱點(diǎn)請求還是沒有價(jià)值的無效請求，那么對系統(tǒng)資源來說完全是浪費(fèi)
2、即使這些熱點(diǎn)是有效的請求，我們也要識(shí)別出來做針對性的優(yōu)化，從而用更低的代價(jià)來支撐這些熱點(diǎn)請求
熱點(diǎn)分為熱點(diǎn)操作和熱點(diǎn)數(shù)據(jù)：
熱點(diǎn)操作: 例如大量的刷新頁面、大量的添加購物車、雙十一零點(diǎn)大量的下單等都屬于此類操作
對系統(tǒng)來說，這些操作可以抽象為“讀請求”和“寫請求”，這兩種熱點(diǎn)請求的處理方式大相徑庭，讀請求的優(yōu)化空間要大一些，而寫請求的瓶頸一般都在存儲(chǔ)層，優(yōu)化的思路就是根據(jù)CAP理論做平衡
熱點(diǎn)數(shù)據(jù): 就是用戶的熱點(diǎn)請求對應(yīng)的數(shù)據(jù)
靜態(tài)熱點(diǎn)數(shù)據(jù)：就是能夠提前預(yù)測的熱點(diǎn)數(shù)據(jù)。例如，我們可以通過賣家報(bào)名的方式提前篩選出來，通過報(bào)名系統(tǒng)對這些熱點(diǎn)商品進(jìn)行打標(biāo)。另外，我們還可以通過大數(shù)據(jù)分析來提前發(fā)現(xiàn)熱點(diǎn)商品，比如我們分析歷史成交記錄、用戶的購物車記錄，來發(fā)現(xiàn)哪些商品可能更熱門、更好賣，這些都是可以提前分析出來的熱點(diǎn)
動(dòng)態(tài)熱點(diǎn)數(shù)據(jù)：就是不能被提前預(yù)測到的，系統(tǒng)在運(yùn)行過程中臨時(shí)產(chǎn)生的熱點(diǎn)。例如，賣家在抖音上做了廣告，然后商品一下就火了，導(dǎo)致它在短時(shí)間內(nèi)被大量購買
發(fā)現(xiàn)熱點(diǎn)數(shù)據(jù)
1、發(fā)現(xiàn)靜態(tài)熱點(diǎn)數(shù)據(jù)
靜態(tài)熱點(diǎn)數(shù)據(jù)可以通過商業(yè)手段，例如強(qiáng)制讓賣家通過報(bào)名參加的方式提前把熱點(diǎn)商品篩選出來，實(shí)現(xiàn)方式是通過一個(gè)運(yùn)營系統(tǒng)，把參加活動(dòng)的商品數(shù)據(jù)進(jìn)行打標(biāo)，然后通過一個(gè)后臺(tái)系統(tǒng)對這些熱點(diǎn)商品進(jìn)行預(yù)處理，如提前進(jìn)行緩存。但是這種通過報(bào)名提前篩選的方式也會(huì)帶來新的問題，即增加賣家的使用成本，而且實(shí)時(shí)性較差，也不太靈活
不過，除了提前報(bào)名篩選這種方式，你還可以通過技術(shù)手段提前預(yù)測，例如對買家每天訪問的商品進(jìn)行大數(shù)據(jù)計(jì)算，然后統(tǒng)計(jì)出TOP N的商品，我們可以認(rèn)為這些TOP N的商品就是熱點(diǎn)商品
2、發(fā)現(xiàn)動(dòng)態(tài)熱點(diǎn)數(shù)據(jù)
能夠動(dòng)態(tài)地實(shí)時(shí)發(fā)現(xiàn)熱點(diǎn)不僅對秒殺商品，對其他熱賣商品也同樣有價(jià)值，所以我們需要想辦法實(shí)現(xiàn)熱點(diǎn)的動(dòng)態(tài)發(fā)現(xiàn)功能。
構(gòu)建一個(gè)異步的系統(tǒng)，它可以收集交易鏈路上各個(gè)環(huán)節(jié)中的中間件產(chǎn)品的熱點(diǎn)Key，如Nginx、緩存、RPC服務(wù)框架等這些中間件（一些中間件產(chǎn)品本身已經(jīng)有熱點(diǎn)統(tǒng)計(jì)模塊）
建立一個(gè)熱點(diǎn)上報(bào)和可以按照需求訂閱的熱點(diǎn)服務(wù)的下發(fā)規(guī)范，主要目的是通過交易鏈路上各個(gè)系統(tǒng)（包括詳情、購物車、交易、優(yōu)惠、庫存、物流等）訪問的時(shí)間差，把上游已經(jīng)發(fā)現(xiàn)的熱點(diǎn)透傳給下游系統(tǒng)，提前做好保護(hù)。比如，對于大促高峰期，詳情系統(tǒng)是最早知道的，在統(tǒng)一接入層上Nginx模塊統(tǒng)計(jì)的熱點(diǎn)URL
將上游系統(tǒng)收集的熱點(diǎn)數(shù)據(jù)發(fā)送到熱點(diǎn)服務(wù)臺(tái)，然后下游系統(tǒng)（如交易系統(tǒng)）就會(huì)知道哪些商品會(huì)被頻繁調(diào)用，然后做熱點(diǎn)保護(hù)
其中用戶訪問商品時(shí)經(jīng)過的路徑有很多，我們主要是依賴前面的導(dǎo)購頁面（包括首頁、搜索頁面、商品詳情、購物車等）提前識(shí)別哪些商品的訪問量高，通過這些系統(tǒng)中的中間件來收集熱點(diǎn)數(shù)據(jù)，并記錄到日志中
我們通過部署在每臺(tái)機(jī)器上的Agent把日志匯總到聚合和分析集群中，然后把符合一定規(guī)則的熱點(diǎn)數(shù)據(jù)，通過訂閱分發(fā)系統(tǒng)再推送到相應(yīng)的系統(tǒng)中。你可以是把熱點(diǎn)數(shù)據(jù)填充到Cache中，或者直接推送到應(yīng)用服務(wù)器的內(nèi)存中，還可以對這些數(shù)據(jù)進(jìn)行攔截，總之下游系統(tǒng)可以訂閱這些數(shù)據(jù)，然后根據(jù)自己的需求決定如何處理這些數(shù)據(jù)
打造熱點(diǎn)發(fā)現(xiàn)系統(tǒng)時(shí)，有幾點(diǎn)注意事項(xiàng)：
1、這個(gè)熱點(diǎn)服務(wù)后臺(tái)抓取熱點(diǎn)數(shù)據(jù)日志最好采用異步方式，因?yàn)椤爱惒健币环矫姹阌诒ＷC通用性，另一方面又不影響業(yè)務(wù)系統(tǒng)和中間件產(chǎn)品的主流程
2、熱點(diǎn)服務(wù)發(fā)現(xiàn)和中間件自身的熱點(diǎn)保護(hù)模塊并存，每個(gè)中間件和應(yīng)用還需要保護(hù)自己。熱點(diǎn)服務(wù)臺(tái)提供熱點(diǎn)數(shù)據(jù)的收集和訂閱服務(wù)，便于把各個(gè)系統(tǒng)的熱點(diǎn)數(shù)據(jù)透明出來
3、熱點(diǎn)發(fā)現(xiàn)要做到接近實(shí)時(shí)（3s內(nèi)完成熱點(diǎn)數(shù)據(jù)的發(fā)現(xiàn)），因?yàn)橹挥凶龅浇咏鼘?shí)時(shí)，動(dòng)態(tài)發(fā)現(xiàn)才有意義，才能實(shí)時(shí)地對下游系統(tǒng)提供保護(hù)
處理熱點(diǎn)數(shù)據(jù)
處理熱點(diǎn)數(shù)據(jù)通常有幾種思路：一是優(yōu)化，二是限制，三是隔離
優(yōu)化
優(yōu)化熱點(diǎn)數(shù)據(jù)最有效的辦法就是緩存熱點(diǎn)數(shù)據(jù)，如果熱點(diǎn)數(shù)據(jù)做了動(dòng)靜分離，那么可以長期緩存靜態(tài)數(shù)據(jù)。但是，緩存熱點(diǎn)數(shù)據(jù)更多的是“臨時(shí)”緩存，即不管是靜態(tài)數(shù)據(jù)還是動(dòng)態(tài)數(shù)據(jù)，都用一個(gè)隊(duì)列短暫地緩存數(shù)秒鐘，由于隊(duì)列長度有限，可以采用LRU淘汰算法替換
限制
限制更多的是一種保護(hù)機(jī)制，限制的辦法也有很多，例如對被訪問商品的ID做一致性Hash，然后根據(jù)Hash做分桶，每個(gè)分桶設(shè)置一個(gè)處理隊(duì)列，這樣可以把熱點(diǎn)商品限制在一個(gè)請求隊(duì)列里，防止因某些熱點(diǎn)商品占用太多的服務(wù)器資源，而使其他請求始終得不到服務(wù)器的處理資源
隔離
秒殺系統(tǒng)設(shè)計(jì)的第一個(gè)原則就是將這種熱點(diǎn)數(shù)據(jù)隔離出來，不要讓1%的請求影響到另外的99%，隔離出來后也更方便對這1%的請求做針對性的優(yōu)化。具體到“秒殺”業(yè)務(wù)，我們可以在以下幾個(gè)層次實(shí)現(xiàn)隔離:
業(yè)務(wù)隔離。把秒殺做成一種營銷活動(dòng)，賣家要參加秒殺這種營銷活動(dòng)需要單獨(dú)報(bào)名，從技術(shù)上來說，賣家報(bào)名后對我們來說就有了已知熱點(diǎn)，因此可以提前做好預(yù)熱
系統(tǒng)隔離。系統(tǒng)隔離更多的是運(yùn)行時(shí)的隔離，可以通過分組部署的方式和另外99%分開。秒殺可以申請單獨(dú)的域名，目的也是讓請求落到不同的集群中
數(shù)據(jù)隔離。秒殺所調(diào)用的數(shù)據(jù)大部分都是熱點(diǎn)數(shù)據(jù)，比如會(huì)啟用單獨(dú)的Cache集群或者M(jìn)ySQL數(shù)據(jù)庫來放熱點(diǎn)數(shù)據(jù)，目的也是不想0.01%的數(shù)據(jù)有機(jī)會(huì)影響99.99%數(shù)據(jù)
實(shí)現(xiàn)隔離有很多種辦法。比如，你可以按照用戶來區(qū)分，給不同的用戶分配不同的Cookie，在接入層，路由到不同的服務(wù)接口中；再比如，你還可以在接入層針對URL中的不同Path來設(shè)置限流策略。服務(wù)層調(diào)用不同的服務(wù)接口，以及數(shù)據(jù)層通過給數(shù)據(jù)打標(biāo)來區(qū)分等等這些措施，其目的都是把已經(jīng)識(shí)別出來的熱點(diǎn)請求和普通的請求區(qū)分開
source:https://zhouj000.github.io/2018/10/15/SecKill-System-2
推薦閱讀
關(guān)于程序員大白
程序員大白是一群哈工大，東北大學(xué)，西湖大學(xué)和上海交通大學(xué)的碩士博士運(yùn)營維護(hù)的號(hào)，大家樂于分享高質(zhì)量文章，喜歡總結(jié)知識(shí)，歡迎關(guān)注[程序員大白]，大家一起學(xué)習(xí)進(jìn)步！