摘要: 對于高并發(fā)架構(gòu)狐树，毫無疑問緩存是最重要的一環(huán)涮母，對于大量的高并發(fā)挟冠，可以采用三層緩存架構(gòu)來實(shí)現(xiàn)鹏漆，nginx+redis+ehcache

nginx

對于中間件nginx常用來做流量的分發(fā)巩梢，同時nginx本身也有自己的緩存（容量有限），我們可以用來緩存熱點(diǎn)數(shù)據(jù)艺玲，讓用戶的請求直接走緩存并返回括蝠，減少流向服務(wù)器的流量

一.模板引擎

通常我們可以配合使用freemaker/velocity等模板引擎來抗住大量的請求

小型系統(tǒng)可能直接在服務(wù)器端渲染出所有的頁面并放入緩存，之后的相同頁面請求就可以直接返回饭聚，不用去查詢數(shù)據(jù)源或者做數(shù)據(jù)邏輯處理

對于頁面非常之多的系統(tǒng)又跛，當(dāng)模板有改變，上述方法就需要重新渲染所有的頁面模板若治，毫無疑問是不可取的慨蓝。因此配合nginx+lua（OpenResty），將模板單獨(dú)保存在nginx緩存中端幼，同時對于用來渲染的數(shù)據(jù)也存在nginx緩存中礼烈，但是需要設(shè)置一個緩存過期的時間，以盡可能保證模板的實(shí)時性

二.雙層nginx來提升緩存命中率

對于部署多個nginx而言婆跑，如果不加入一些數(shù)據(jù)的路由策略此熬，那么可能導(dǎo)致每個nginx的緩存命中率很低。因此可以部署雙層nginx

分發(fā)層nginx負(fù)責(zé)流量分發(fā)的邏輯和策略，根據(jù)自己定義的一些規(guī)則犀忱，比如根據(jù)productId進(jìn)行hash募谎，然后對后端nginx數(shù)量取模將某一個商品的訪問請求固定路由到一個nginx后端服務(wù)器上去

后端nginx用來緩存一些熱點(diǎn)數(shù)據(jù)到自己的緩存區(qū)（分發(fā)層只能配置1個嗎）

redis

用戶的請求，在nginx沒有緩存相應(yīng)的數(shù)據(jù)阴汇，那么會進(jìn)入到redis緩存中数冬，redis可以做到全量數(shù)據(jù)的緩存，通過水平擴(kuò)展能夠提升并發(fā)搀庶、高可用的能力

一.持久化機(jī)制：將redis內(nèi)存中的數(shù)據(jù)持久化到磁盤中拐纱，然后可以定期將磁盤文件上傳至S3(AWS)或者ODPS（阿里云）等一些云存儲服務(wù)上去。

如果同時使用RDB和AOF兩種持久化機(jī)制哥倔，那么在redis重啟的時候秸架，會使用AOF來重新構(gòu)建數(shù)據(jù)，因?yàn)锳OF中的數(shù)據(jù)更加完整咆蒿，建議將兩種持久化機(jī)制都開啟东抹，用AO F來保證數(shù)據(jù)不丟失，作為數(shù)據(jù)恢復(fù)的第一選擇沃测；用RDB來作不同程度的冷備府阀，在AOF文件都丟失或損壞不可用的時候來快速進(jìn)行數(shù)據(jù)的恢復(fù)。

實(shí)戰(zhàn)踩坑：對于想從RDB恢復(fù)數(shù)據(jù)芽突，同時AOF開關(guān)也是打開的，一直無法正扯埃恢復(fù)寞蚌，因?yàn)槊看味紩?yōu)先從AOF獲取數(shù)據(jù)（如果臨時關(guān)閉AOF，就可以正衬坪恢復(fù)）挟秤。此時首先停止redis，然后關(guān)閉AOF抄伍，拷貝RDB到相應(yīng)目錄艘刚，啟動redis之后熱修改配置參數(shù)redis config set appendonly yes，此時會自動生成一個當(dāng)前內(nèi)存數(shù)據(jù)的AOF文件截珍，然后再次停止redis攀甚，打開AOF配置，再次啟動數(shù)據(jù)就正常啟動

RDB

對redis中的數(shù)據(jù)執(zhí)行周期性的持久化岗喉，每一刻持久化的都是全量數(shù)據(jù)的一個快照秋度。對redis性能影響較小，基于RDB能夠快速異城玻恢復(fù)

AOF

以append-only的模式寫入一個日志文件中荚斯，在redis重啟的時候可以通過回放AOF日志中的寫入指令來重新構(gòu)建整個數(shù)據(jù)集。（實(shí)際上每次寫的日志數(shù)據(jù)會先到linux os cache，然后redis每隔一秒調(diào)用操作系統(tǒng)fsync將os cache中的數(shù)據(jù)寫入磁盤）事期。對redis有一定的性能影響滥壕，能夠盡量保證數(shù)據(jù)的完整性。redis通過rewrite機(jī)制來保障AOF文件不會太龐大兽泣，基于當(dāng)前內(nèi)存數(shù)據(jù)并可以做適當(dāng)?shù)闹噶钪貥?gòu)绎橘。

二.redis集群

replication

一主多從架構(gòu)，主節(jié)點(diǎn)負(fù)責(zé)寫撞叨，并且將數(shù)據(jù)同步到其他salve節(jié)點(diǎn)（異步執(zhí)行）金踪，從節(jié)點(diǎn)負(fù)責(zé)讀，主要就是用來做讀寫分離的橫向擴(kuò)容架構(gòu)牵敷。這種架構(gòu)的master節(jié)點(diǎn)數(shù)據(jù)一定要做持久化胡岔，否則，當(dāng)master宕機(jī)重啟之后內(nèi)存數(shù)據(jù)清空枷餐，那么就會將空數(shù)據(jù)復(fù)制到slave靶瘸，導(dǎo)致所有數(shù)據(jù)消失

sentinal哨兵

哨兵是redis集群架構(gòu)中很重要的一個組件，負(fù)責(zé)監(jiān)控redis master和slave進(jìn)程是否正常工作毛肋，當(dāng)某個redis實(shí)例故障時怨咪，能夠發(fā)送消息報警通知給管理員，當(dāng)master node宕機(jī)能夠自動轉(zhuǎn)移到slave node上润匙，如果故障轉(zhuǎn)移發(fā)生來诗眨，會通知client客戶端新的master地址。sentinal至少需要3個實(shí)例來保證自己的健壯性孕讳，并且能夠更好地進(jìn)行quorum投票以達(dá)到majority來執(zhí)行故障轉(zhuǎn)移匠楚。

前兩種架構(gòu)方式最大的特點(diǎn)是，每個節(jié)點(diǎn)的數(shù)據(jù)是相同的厂财，無法存取海量的數(shù)據(jù)芋簿。因此哨兵集群的方式使用與數(shù)據(jù)量不大的情況

redis cluster

redis cluster支撐多master node，每個master node可以掛載多個slave node璃饱，如果mastre掛掉會自動將對應(yīng)的某個slave切換成master与斤。需要注意的是redis cluster架構(gòu)下slave節(jié)點(diǎn)主要是用來做高可用、故障主備切換的荚恶，如果一定需要slave能夠提供讀的能力撩穿，修改配置也可以實(shí)現(xiàn)（同時也需要修改jedis源碼來支持該情況下的讀寫分離操作）。redis cluster架構(gòu)下谒撼，master就是可以任意擴(kuò)展的冗锁，直接橫向擴(kuò)展master即可提高讀寫吞吐量。slave節(jié)點(diǎn)能夠自動遷移（讓master節(jié)點(diǎn)盡量平均擁有slave節(jié)點(diǎn)）嗤栓，對整個架構(gòu)過載冗余的slave就可以保障系統(tǒng)更高的可用性冻河。

ehcache

tomcat jvm堆內(nèi)存緩存箍邮，主要是抗redis出現(xiàn)大規(guī)模災(zāi)難。如果redis出現(xiàn)了大規(guī)模的宕機(jī)叨叙，導(dǎo)致nginx大量流量直接涌入數(shù)據(jù)生產(chǎn)服務(wù)锭弊，那么最后的tomcat堆內(nèi)存緩存也可以處理部分請求，避免所有請求都直接流向DB

針對上面的技術(shù)我特意整理了一下擂错，有很多技術(shù)不是靠幾句話能講清楚味滞，所以干脆找朋友錄制了一些視頻，很多問題其實(shí)答案很簡單钮呀，但是背后的思考和邏輯不簡單剑鞍，要做到知其然還要知其所以然。如果想學(xué)習(xí)Java工程化爽醋、高性能及分布式蚁署、深入淺出。微服務(wù)蚂四、Spring光戈，MyBatis，Netty源碼分析的朋友可以加我的Java進(jìn)階群：694549689遂赠，群里有阿里大牛直播講解技術(shù)久妆，以及Java大型互聯(lián)網(wǎng)技術(shù)的視頻免費(fèi)分享給大家。

緩存數(shù)據(jù)更新策略

對時效性要求高的緩存數(shù)據(jù)跷睦，當(dāng)發(fā)生變更的時候筷弦，直接采取數(shù)據(jù)庫和redis緩存雙寫的方案，讓緩存時效性最高抑诸。

對時效性不高的數(shù)據(jù)烂琴，當(dāng)發(fā)生變更之后，采取MQ異步通知的方式哼鬓，通過數(shù)據(jù)生產(chǎn)服務(wù)來監(jiān)聽MQ消息，然后異步去拉取服務(wù)的數(shù)據(jù)更新tomcat jvm緩存和redis緩存边灭，對于nginx本地緩存過期之后就可以從redis中拉取新的數(shù)據(jù)并更新到nginx本地异希。

經(jīng)典的緩存+數(shù)據(jù)庫讀寫的模式，cache aside pattern

讀的時候绒瘦，先讀緩存称簿，緩存沒有的話，那么就讀數(shù)據(jù)庫惰帽，然后取出數(shù)據(jù)后放入緩存憨降，同時返回響應(yīng)

更新的時候，先刪除緩存该酗，然后再更新數(shù)據(jù)庫

之所以更新的時候只是刪除緩存授药，因?yàn)閷τ谝恍?fù)雜有邏輯的緩存數(shù)據(jù)士嚎，每次數(shù)據(jù)變更都更新一次緩存會造成額外的負(fù)擔(dān)，只是刪除緩存悔叽，讓該數(shù)據(jù)下一次被使用的時候再去執(zhí)行讀的操作來重新緩存莱衩，這里采用的是懶加載的策略。舉個例子娇澎，一個緩存涉及的表的字段笨蚁，在1分鐘內(nèi)就修改了20次，或者是100次趟庄，那么緩存跟新20次括细，100次；但是這個緩存在1分鐘內(nèi)就被讀取了1次戚啥，因此每次更新緩存就會有大量的冷數(shù)據(jù)奋单，對于緩存符合28黃金法則，20%的數(shù)據(jù)虑鼎，占用了80%的訪問量

數(shù)據(jù)庫和redis緩存雙寫不一致的問題

最初級的緩存不一致問題以及解決方案

問題：如果先修改數(shù)據(jù)庫再刪除緩存辱匿，那么當(dāng)緩存刪除失敗來，那么會導(dǎo)致數(shù)據(jù)庫中是最新數(shù)據(jù)炫彩，緩存中依舊是舊數(shù)據(jù)匾七，造成數(shù)據(jù)不一致。

解決方案：可以先刪除緩存江兢，再修改數(shù)據(jù)庫昨忆，如果刪除緩存成功但是數(shù)據(jù)庫修改失敗，那么數(shù)據(jù)庫中是舊數(shù)據(jù)杉允，緩存是空不會出現(xiàn)不一致

比較復(fù)雜的數(shù)據(jù)不一致問題分析

問題：對于數(shù)據(jù)發(fā)生來變更邑贴，先刪除緩存，然后去修改數(shù)據(jù)庫叔磷，此時數(shù)據(jù)庫中的數(shù)據(jù)還沒有修改成功拢驾，并發(fā)的讀請求到來去讀緩存發(fā)現(xiàn)是空，進(jìn)而去數(shù)據(jù)庫查詢到此時的舊數(shù)據(jù)放到緩存中改基，然后之前對數(shù)據(jù)庫數(shù)據(jù)的修改成功來繁疤，就會造成數(shù)據(jù)不一致

解決方案：將數(shù)據(jù)庫與緩存更新與讀取操作進(jìn)行異步串行化。當(dāng)更新數(shù)據(jù)的時候秕狰，根據(jù)數(shù)據(jù)的唯一標(biāo)識稠腊，將更新數(shù)據(jù)操作路由到一個jvm內(nèi)部的隊(duì)列中，一個隊(duì)列對應(yīng)一個工作線程鸣哀，線程串行拿到隊(duì)列中的操作一條一條地執(zhí)行架忌。當(dāng)執(zhí)行隊(duì)列中的更新數(shù)據(jù)操作，刪除緩存我衬，然后去更新數(shù)據(jù)庫叹放，此時還沒有完成更新的時候過來一個讀請求饰恕，讀到了空的緩存那么可以先將緩存更新的請求發(fā)送至路由之后的隊(duì)列中，此時會在隊(duì)列積壓许昨，然后同步等待緩存更新完成懂盐，一個隊(duì)列中多個相同數(shù)據(jù)緩存更新請求串在一起是沒有意義的，因此可以做過濾處理糕档。等待前面的更新數(shù)據(jù)操作完成數(shù)據(jù)庫操作之后莉恼，才會去執(zhí)行下一個緩存更新的操作，此時會從數(shù)據(jù)庫中讀取最新的數(shù)據(jù)速那，然后寫入緩存中俐银，如果請求還在等待時間范圍內(nèi)，不斷輪詢發(fā)現(xiàn)可以取到緩存中值就可以直接返回（此時可能會有對這個緩存數(shù)據(jù)的多個請求正在這樣處理）端仰；如果請求等待事件超過一定時長捶惜，那么這一次的請求直接讀取數(shù)據(jù)庫中的舊值

對于這種處理方式需要注意一些問題：

讀請求長時阻塞：由于讀請求進(jìn)行來非常輕度的異步化，所以對超時的問題需要格外注意荔烧，超過超時時間會直接查詢DB吱七，處理不好會對DB造成壓力，因此需要測試系統(tǒng)高峰期QPS來調(diào)整機(jī)器數(shù)以及對應(yīng)機(jī)器上的隊(duì)列數(shù)最終決定合理的請求等待超時時間

多實(shí)例部署的請求路由：可能這個服務(wù)會部署多個實(shí)例鹤竭，那么必須保證對應(yīng)的請求都通過nginx服務(wù)器路由到相同的服務(wù)實(shí)例上

熱點(diǎn)數(shù)據(jù)的路由導(dǎo)師請求的傾斜：因?yàn)橹挥性谏唐窋?shù)據(jù)更新的時候才會清空緩存踊餐，然后才會導(dǎo)致讀寫并發(fā)，所以更新頻率不是太高的話臀稚，這個問題的影響并不是特別大吝岭，但是的確可能某些機(jī)器的負(fù)載會高一些

分布式緩存重建并發(fā)沖突解決方案

對于緩存生產(chǎn)服務(wù)，可能部署在多臺機(jī)器吧寺，當(dāng)redis和ehcache對應(yīng)的緩存數(shù)據(jù)都過期不存在時窜管，此時可能nginx過來的請求和kafka監(jiān)聽的請求同時到達(dá)，導(dǎo)致兩者最終都去拉取數(shù)據(jù)并且存入redis中稚机，因此可能產(chǎn)生并發(fā)沖突的問題幕帆，可以采用redis或者zookeeper類似的分布式鎖來解決，讓請求的被動緩存重建與監(jiān)聽主動的緩存重建操作避免并發(fā)的沖突赖条，當(dāng)存入緩存的時候通過對比時間字段廢棄掉舊的數(shù)據(jù)失乾，保存最新的數(shù)據(jù)到緩存

緩存冷啟動以及緩存預(yù)熱解決方案

當(dāng)系統(tǒng)第一次啟動，大量請求涌入谋币，此時的緩存為空仗扬，可能會導(dǎo)致DB崩潰症概，進(jìn)而讓系統(tǒng)不可用蕾额，同樣當(dāng)redis所有緩存數(shù)據(jù)異常丟失，也會導(dǎo)致該問題彼城。因此诅蝶，可以提前放入數(shù)據(jù)到redis避免上述冷啟動的問題退个，當(dāng)然也不可能是全量數(shù)據(jù)，可以根據(jù)類似于當(dāng)天的具體訪問情況调炬，實(shí)時統(tǒng)計出訪問頻率較高的熱數(shù)據(jù)语盈，這里熱數(shù)據(jù)也比較多，需要多個服務(wù)并行的分布式去讀寫到redis中（所以要基于zk分布式鎖）

通過nginx+lua將訪問流量上報至kafka中缰泡，storm從kafka中消費(fèi)數(shù)據(jù)刀荒，實(shí)時統(tǒng)計處每個商品的訪問次數(shù)，訪問次數(shù)基于LRU（apache commons collections LRUMap）內(nèi)存數(shù)據(jù)結(jié)構(gòu)的存儲方案棘钞，使用LRUMap去存放是因?yàn)閮?nèi)存中的性能高缠借，沒有外部依賴，每個storm task啟動的時候基于zk分布式鎖將自己的id寫入zk同一個節(jié)點(diǎn)中宜猜，每個storm task負(fù)責(zé)完成自己這里的熱數(shù)據(jù)的統(tǒng)計泼返，每隔一段時間就遍歷一下這個map，然后維護(hù)一個前1000的數(shù)據(jù)list姨拥，然后去更新這個list绅喉，最后開啟一個后臺線程，每隔一段時間比如一分鐘都將排名的前1000的熱數(shù)據(jù)list同步到zk中去叫乌，存儲到這個storm task對應(yīng)的一個znode中去

部署多個實(shí)例的服務(wù)柴罐，每次啟動的時候就會去拿到上述維護(hù)的storm task id列表的節(jié)點(diǎn)數(shù)據(jù)，然后根據(jù)taskid综芥，一個一個去嘗試獲取taskid對應(yīng)的znode的zk分布式鎖丽蝎，如果能夠獲取到分布式鎖，再去獲取taskid status的鎖進(jìn)而查詢預(yù)熱狀態(tài)膀藐，如果沒有被預(yù)熱過屠阻，那么就將這個taskid對應(yīng)的熱數(shù)據(jù)list取出來，從而從DB中查詢出來寫入緩存中额各，如果taskid分布式鎖獲取失敗国觉，快速拋錯進(jìn)行下一次循環(huán)獲取下一個taskid的分布式鎖即可，此時就是多個服務(wù)實(shí)例基于zk分布式鎖做協(xié)調(diào)并行的進(jìn)行緩存的預(yù)熱

緩存熱點(diǎn)導(dǎo)致系統(tǒng)不可用解決方案

對于瞬間大量的相同數(shù)據(jù)的請求涌入虾啦，可能導(dǎo)致該數(shù)據(jù)經(jīng)過hash策略之后對應(yīng)的應(yīng)用層nginx被壓垮麻诀，如果請求繼續(xù)就會影響至其他的nginx，最終導(dǎo)致所有nginx出現(xiàn)異常整個系統(tǒng)變得不可用傲醉。

基于nginx+lua+storm的熱點(diǎn)緩存的流量分發(fā)策略自動降級來解決上述問題的出現(xiàn)蝇闭，可以設(shè)定訪問次數(shù)大于后95%平均值n倍的數(shù)據(jù)為熱點(diǎn)，在storm中直接發(fā)送http請求到流量分發(fā)的nginx上去硬毕，使其存入本地緩存呻引，然后storm還會將熱點(diǎn)對應(yīng)的完整緩存數(shù)據(jù)沒發(fā)送到所有的應(yīng)用nginx服務(wù)器上去，并直接存放到本地緩存吐咳。對于流量分發(fā)nginx逻悠，訪問對應(yīng)的數(shù)據(jù)元践，如果發(fā)現(xiàn)是熱點(diǎn)標(biāo)識就立即做流量分發(fā)策略的降級，對同一個數(shù)據(jù)的訪問從hash到一臺應(yīng)用層nginx降級成為分發(fā)至所有的應(yīng)用層nginx童谒。storm需要保存上一次識別出來的熱點(diǎn)List单旁，并同當(dāng)前計算出來的熱點(diǎn)list做對比，如果已經(jīng)不是熱點(diǎn)數(shù)據(jù)饥伊，則發(fā)送對應(yīng)的http請求至流量分發(fā)nginx中來取消對應(yīng)數(shù)據(jù)的熱點(diǎn)標(biāo)識

緩存雪崩解決方案

redis集群徹底崩潰象浑，緩存服務(wù)大量對redis的請求等待，占用資源琅豆，隨后緩存服務(wù)大量的請求進(jìn)入源頭服務(wù)去查詢DB融柬，使DB壓力過大崩潰，此時對源頭服務(wù)的請求也大量等待占用資源趋距，緩存服務(wù)大量的資源全部耗費(fèi)在訪問redis和源服務(wù)無果粒氧，最后使自身無法提供服務(wù)，最終會導(dǎo)致整個網(wǎng)站崩潰节腐。

事前的解決方案外盯，搭建一套高可用架構(gòu)的redis cluster集群，主從架構(gòu)翼雀、一主多從饱苟，一旦主節(jié)點(diǎn)宕機(jī)，從節(jié)點(diǎn)自動跟上狼渊，并且最好使用雙機(jī)房部署集群箱熬。

事中的解決方案，部署一層ehcache緩存狈邑，在redis全部實(shí)現(xiàn)情況下能夠抗住部分壓力城须；對redis cluster的訪問做資源隔離，避免所有資源都等待米苹，對redis cluster的訪問失敗時的情況去部署對應(yīng)的熔斷策略糕伐，部署redis cluster的降級策略；對源服務(wù)訪問的限流以及資源隔離

事后的解決方案：redis數(shù)據(jù)做了備份可以直接恢復(fù)蘸嘶，重啟redis即可良瞧；redis數(shù)據(jù)徹底失敗來或者數(shù)據(jù)過舊，可以快速緩存預(yù)熱训唱，然后讓redis重新啟動褥蚯。然后由于資源隔離的half-open策略發(fā)現(xiàn)redis已經(jīng)能夠正常訪問，那么所有的請求將自動恢復(fù)

緩存穿透解決方案

對于在多級緩存中都沒有對應(yīng)的數(shù)據(jù)况增，并且DB也沒有查詢到數(shù)據(jù)赞庶，此時大量的請求都會直接到達(dá)DB，導(dǎo)致DB承載高并發(fā)的問題。解決緩存穿透的問題可以對DB也沒有的數(shù)據(jù)返回一個空標(biāo)識的數(shù)據(jù)尘执，進(jìn)而保存到各級緩存中，因?yàn)橛袑?shù)據(jù)修改的異步監(jiān)聽宴凉，所以當(dāng)數(shù)據(jù)有更新誊锭，新的數(shù)據(jù)會被更新到緩存匯中。

nginx緩存失效導(dǎo)致redis壓力倍增

可以在nginx本地弥锄，設(shè)置緩存數(shù)據(jù)的時候隨機(jī)緩存的有效期丧靡，避免同一時刻緩存都失效而大量請求直接進(jìn)入redis