對于高并發(fā)架構(gòu)馍迄，毫無疑問緩存是最重要的一環(huán)捅儒，對于大量的高并發(fā)灰蛙，可以采用三層緩存架構(gòu)來實現(xiàn)nginx+redis+ehcache圣贸。

Nginx

對于中間件nginx常用來做流量的分發(fā)殴泰，同時nginx本身也有自己的緩存（容量有限）于宙，我們可以用來緩存熱點數(shù)據(jù)，讓用戶的請求直接走緩存并返回艰匙，減少流向服務器的流量限煞。

1.模板引擎

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

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

對于頁面非常之多的系統(tǒng)，當模板有改變健霹，上述方法就需要重新渲染所有的頁面模板旺上，毫無疑問是不可取的。因此配合nginx+lua（OpenResty）糖埋，將模板單獨保存在nginx緩存中宣吱，同時對于用來渲染的數(shù)據(jù)也存在nginx緩存中，但是需要設置一個緩存過期的時間瞳别，以盡可能保證模板的實時性征候。

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

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

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

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

Redis

用戶的請求历谍，在nginx沒有緩存相應的數(shù)據(jù)现拒，那么會進入到redis緩存中，redis可以做到全量數(shù)據(jù)的緩存望侈，通過水平擴展能夠提升并發(fā)印蔬、高可用的能力。

1.持久化機制

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

如果同時使用RDB和AOF兩種持久化機制哥遮，那么在redis重啟的時候岂丘，會使用AOF來重新構(gòu)建數(shù)據(jù)，因為AOF中的數(shù)據(jù)更加完整眠饮，建議將兩種持久化機制都開啟奥帘，用AO F來保證數(shù)據(jù)不丟失，作為數(shù)據(jù)恢復的第一選擇仪召；用RDB來作不同程度的冷備寨蹋，在AOF文件都丟失或損壞不可用的時候來快速進行數(shù)據(jù)的恢復。

實戰(zhàn)踩坑：對于想從RDB恢復數(shù)據(jù)扔茅，同時AOF開關也是打開的已旧，一直無法正常恢復召娜，因為每次都會優(yōu)先從AOF獲取數(shù)據(jù)（如果臨時關閉AOF运褪，就可以正常恢復）玖瘸。此時首先停止redis秸讹，然后關閉AOF，拷貝RDB到相應目錄雅倒，啟動redis之后熱修改配置參數(shù)redis config set appendonly yes璃诀，此時會自動生成一個當前內(nèi)存數(shù)據(jù)的AOF文件，然后再次停止redis蔑匣，打開AOF配置劣欢，再次啟動數(shù)據(jù)就正常啟動棕诵。

RDB

對redis中的數(shù)據(jù)執(zhí)行周期性的持久化，每一刻持久化的都是全量數(shù)據(jù)的一個快照凿将。對redis性能影響較小年鸳，基于RDB能夠快速異常恢復丸相。

AOF

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

2.redis集群

replication

一主多從架構(gòu)映琳，主節(jié)點負責寫机隙，并且將數(shù)據(jù)同步到其他salve節(jié)點（異步執(zhí)行），從節(jié)點負責讀萨西，主要就是用來做讀寫分離的橫向擴容架構(gòu)有鹿。這種架構(gòu)的master節(jié)點數(shù)據(jù)一定要做持久化，否則谎脯，當master宕機重啟之后內(nèi)存數(shù)據(jù)清空葱跋，那么就會將空數(shù)據(jù)復制到slave，導致所有數(shù)據(jù)消失源梭。

sentinal哨兵

哨兵是redis集群架構(gòu)中很重要的一個組件娱俺，負責監(jiān)控redis master和slave進程是否正常工作，當某個redis實例故障時废麻，能夠發(fā)送消息報警通知給管理員荠卷，當master node宕機能夠自動轉(zhuǎn)移到slave node上，如果故障轉(zhuǎn)移發(fā)生來烛愧，會通知client客戶端新的master地址油宜。sentinal至少需要3個實例來保證自己的健壯性，并且能夠更好地進行quorum投票以達到majority來執(zhí)行故障轉(zhuǎn)移屑彻。

前兩種架構(gòu)方式最大的特點是验庙，每個節(jié)點的數(shù)據(jù)是相同的，無法存取海量的數(shù)據(jù)社牲。因此哨兵集群的方式使用與數(shù)據(jù)量不大的情況粪薛。

redis cluster

redis cluster支撐多master node，每個master node可以掛載多個slave node搏恤，如果mastre掛掉會自動將對應的某個slave切換成master违寿。需要注意的是redis cluster架構(gòu)下slave節(jié)點主要是用來做高可用湃交、故障主備切換的，如果一定需要slave能夠提供讀的能力藤巢，修改配置也可以實現(xiàn)（同時也需要修改jedis源碼來支持該情況下的讀寫分離操作）搞莺。redis cluster架構(gòu)下，master就是可以任意擴展的掂咒，直接橫向擴展master即可提高讀寫吞吐量才沧。slave節(jié)點能夠自動遷移（讓master節(jié)點盡量平均擁有slave節(jié)點），對整個架構(gòu)過載冗余的slave就可以保障系統(tǒng)更高的可用性绍刮。

ehcache

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

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

對時效性要求高的緩存數(shù)據(jù)膝蜈，當發(fā)生變更的時候锅移，直接采取數(shù)據(jù)庫和redis緩存雙寫的方案，讓緩存時效性最高饱搏。

對時效性不高的數(shù)據(jù)非剃，當發(fā)生變更之后，采取MQ異步通知的方式窍帝，通過數(shù)據(jù)生產(chǎn)服務來監(jiān)聽MQ消息努潘，然后異步去拉取服務的數(shù)據(jù)更新tomcat jvm緩存和redis緩存，對于nginx本地緩存過期之后就可以從redis中拉取新的數(shù)據(jù)并更新到nginx本地坤学。

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

cache aside pattern

讀的時候，先讀緩存报慕，緩存沒有的話深浮，那么就讀數(shù)據(jù)庫，然后取出數(shù)據(jù)后放入緩存眠冈，同時返回響應飞苇。

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

之所以更新的時候只是刪除緩存布卡，因為對于一些復雜有邏輯的緩存數(shù)據(jù)，每次數(shù)據(jù)變更都更新一次緩存會造成額外的負擔雇盖，只是刪除緩存忿等，讓該數(shù)據(jù)下一次被使用的時候再去執(zhí)行讀的操作來重新緩存，這里采用的是懶加載的策略崔挖。

舉個例子贸街，一個緩存涉及的表的字段庵寞，在1分鐘內(nèi)就修改了20次，或者是100次薛匪，那么緩存跟新20次捐川，100次；但是這個緩存在1分鐘內(nèi)就被讀取了1次逸尖，因此每次更新緩存就會有大量的冷數(shù)據(jù)古沥，對于緩存符合28黃金法則，20%的數(shù)據(jù)娇跟，占用了80%的訪問量渐白。

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

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

問題：

如果先修改數(shù)據(jù)庫再刪除緩存，那么當緩存刪除失敗來逞频，那么會導致數(shù)據(jù)庫中是最新數(shù)據(jù)纯衍，緩存中依舊是舊數(shù)據(jù)，造成數(shù)據(jù)不一致苗胀。

解決方案：

可以先刪除緩存襟诸，再修改數(shù)據(jù)庫，如果刪除緩存成功但是數(shù)據(jù)庫修改失敗基协，那么數(shù)據(jù)庫中是舊數(shù)據(jù)歌亲，緩存是空不會出現(xiàn)不一致。

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

問題：

問題：對于數(shù)據(jù)發(fā)生來變更澜驮，先刪除緩存陷揪，然后去修改數(shù)據(jù)庫，此時數(shù)據(jù)庫中的數(shù)據(jù)還沒有修改成功杂穷，并發(fā)的讀請求到來去讀緩存發(fā)現(xiàn)是空悍缠，進而去數(shù)據(jù)庫查詢到此時的舊數(shù)據(jù)放到緩存中，然后之前對數(shù)據(jù)庫數(shù)據(jù)的修改成功來耐量，就會造成數(shù)據(jù)不一致飞蚓。

解決方案：

將數(shù)據(jù)庫與緩存更新與讀取操作進行異步串行化。當更新數(shù)據(jù)的時候廊蜒，根據(jù)數(shù)據(jù)的唯一標識趴拧，將更新數(shù)據(jù)操作路由到一個jvm內(nèi)部的隊列中，一個隊列對應一個工作線程山叮，線程串行拿到隊列中的操作一條一條地執(zhí)行著榴。當執(zhí)行隊列中的更新數(shù)據(jù)操作，刪除緩存屁倔，然后去更新數(shù)據(jù)庫脑又，此時還沒有完成更新的時候過來一個讀請求，讀到了空的緩存那么可以先將緩存更新的請求發(fā)送至路由之后的隊列中，此時會在隊列積壓挂谍，然后同步等待緩存更新完成叔壤，一個隊列中多個相同數(shù)據(jù)緩存更新請求串在一起是沒有意義的，因此可以做過濾處理口叙。等待前面的更新數(shù)據(jù)操作完成數(shù)據(jù)庫操作之后炼绘，才會去執(zhí)行下一個緩存更新的操作，此時會從數(shù)據(jù)庫中讀取最新的數(shù)據(jù)妄田，然后寫入緩存中俺亮，如果請求還在等待時間范圍內(nèi)，不斷輪詢發(fā)現(xiàn)可以取到緩存中值就可以直接返回（此時可能會有對這個緩存數(shù)據(jù)的多個請求正在這樣處理）疟呐；如果請求等待事件超過一定時長脚曾，那么這一次的請求直接讀取數(shù)據(jù)庫中的舊值

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

1.讀請求長時阻塞

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

2.多實例部署的請求路由

可能這個服務會部署多個實例鲁冯，那么必須保證對應的請求都通過nginx服務器路由到相同的服務實例上

3.熱點數(shù)據(jù)的路由導師請求的傾斜

因為只有在商品數(shù)據(jù)更新的時候才會清空緩存拷沸，然后才會導致讀寫并發(fā)，所以更新頻率不是太高的話薯演，這個問題的影響并不是特別大撞芍，但是的確可能某些機器的負載會高一些

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

對于緩存生產(chǎn)服務，可能部署在多臺機器跨扮，當redis和ehcache對應的緩存數(shù)據(jù)都過期不存在時序无，此時可能nginx過來的請求和kafka監(jiān)聽的請求同時到達，導致兩者最終都去拉取數(shù)據(jù)并且存入redis中衡创，因此可能產(chǎn)生并發(fā)沖突的問題帝嗡，可以采用redis或者zookeeper類似的分布式鎖來解決，讓請求的被動緩存重建與監(jiān)聽主動的緩存重建操作避免并發(fā)的沖突钧汹，當存入緩存的時候通過對比時間字段廢棄掉舊的數(shù)據(jù)丈探，保存最新的數(shù)據(jù)到緩存

緩存冷啟動以及緩存預熱解決方案

當系統(tǒng)第一次啟動，大量請求涌入拔莱，此時的緩存為空，可能會導致DB崩潰隘竭，進而讓系統(tǒng)不可用塘秦，同樣當redis所有緩存數(shù)據(jù)異常丟失，也會導致該問題动看。因此尊剔，可以提前放入數(shù)據(jù)到redis避免上述冷啟動的問題，當然也不可能是全量數(shù)據(jù)菱皆，可以根據(jù)類似于當天的具體訪問情況须误，實時統(tǒng)計出訪問頻率較高的熱數(shù)據(jù)挨稿，這里熱數(shù)據(jù)也比較多，需要多個服務并行的分布式去讀寫到redis中（所以要基于zk分布式鎖）京痢。

通過nginx+lua將訪問流量上報至kafka中奶甘，storm從kafka中消費數(shù)據(jù)，實時統(tǒng)計處每個商品的訪問次數(shù)祭椰，訪問次數(shù)基于LRU（apache commons collections LRUMap）內(nèi)存數(shù)據(jù)結(jié)構(gòu)的存儲方案臭家，使用LRUMap去存放是因為內(nèi)存中的性能高，沒有外部依賴方淤，每個storm task啟動的時候基于zk分布式鎖將自己的id寫入zk同一個節(jié)點中钉赁，每個storm task負責完成自己這里的熱數(shù)據(jù)的統(tǒng)計，每隔一段時間就遍歷一下這個map携茂，然后維護一個前1000的數(shù)據(jù)list你踩，然后去更新這個list，最后開啟一個后臺線程讳苦，每隔一段時間比如一分鐘都將排名的前1000的熱數(shù)據(jù)list同步到zk中去带膜，存儲到這個storm task對應的一個znode中去。

部署多個實例的服務医吊，每次啟動的時候就會去拿到上述維護的storm task id列表的節(jié)點數(shù)據(jù)钱慢，然后根據(jù)taskid，一個一個去嘗試獲取taskid對應的znode的zk分布式鎖卿堂，如果能夠獲取到分布式鎖束莫，再去獲取taskid status的鎖進而查詢預熱狀態(tài)，如果沒有被預熱過草描，那么就將這個taskid對應的熱數(shù)據(jù)list取出來览绿，從而從DB中查詢出來寫入緩存中，如果taskid分布式鎖獲取失敗穗慕，快速拋錯進行下一次循環(huán)獲取下一個taskid的分布式鎖即可饿敲，此時就是多個服務實例基于zk分布式鎖做協(xié)調(diào)并行的進行緩存的預熱。

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

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

基于nginx+lua+storm的熱點緩存的流量分發(fā)策略自動降級來解決上述問題的出現(xiàn)瓢对，可以設定訪問次數(shù)大于后95%平均值n倍的數(shù)據(jù)為熱點，在storm中直接發(fā)送http請求到流量分發(fā)的nginx上去胰苏，使其存入本地緩存硕蛹，然后storm還會將熱點對應的完整緩存數(shù)據(jù)沒發(fā)送到所有的應用nginx服務器上去，并直接存放到本地緩存。對于流量分發(fā)nginx法焰，訪問對應的數(shù)據(jù)秧荆，如果發(fā)現(xiàn)是熱點標識就立即做流量分發(fā)策略的降級，對同一個數(shù)據(jù)的訪問從hash到一臺應用層nginx降級成為分發(fā)至所有的應用層nginx埃仪。storm需要保存上一次識別出來的熱點List乙濒，并同當前計算出來的熱點list做對比，如果已經(jīng)不是熱點數(shù)據(jù)贵试，則發(fā)送對應的http請求至流量分發(fā)nginx中來取消對應數(shù)據(jù)的熱點標識

緩存雪崩解決方案

redis集群徹底崩潰琉兜，緩存服務大量對redis的請求等待，占用資源毙玻，隨后緩存服務大量的請求進入源頭服務去查詢DB豌蟋，使DB壓力過大崩潰，此時對源頭服務的請求也大量等待占用資源桑滩，緩存服務大量的資源全部耗費在訪問redis和源服務無果梧疲，最后使自身無法提供服務，最終會導致整個網(wǎng)站崩潰运准。

事前解決方案：

搭建一套高可用架構(gòu)的redis cluster集群幌氮，主從架構(gòu)、一主多從胁澳，一旦主節(jié)點宕機该互，從節(jié)點自動跟上，并且最好使用雙機房部署集群韭畸。

事中解決方案：

部署一層ehcache緩存宇智，在redis全部實現(xiàn)情況下能夠抗住部分壓力；對redis cluster的訪問做資源隔離胰丁，避免所有資源都等待随橘，對redis cluster的訪問失敗時的情況去部署對應的熔斷策略，部署redis cluster的降級策略锦庸；對源服務訪問的限流以及資源隔離机蔗。

事后解決方案：

redis數(shù)據(jù)做了備份可以直接恢復，重啟redis即可甘萧；redis數(shù)據(jù)徹底失敗來或者數(shù)據(jù)過舊萝嘁，可以快速緩存預熱，然后讓redis重新啟動扬卷。然后由于資源隔離的half-open策略發(fā)現(xiàn)redis已經(jīng)能夠正常訪問酿愧，那么所有的請求將自動恢復。

緩存穿透解決方案

對于在多級緩存中都沒有對應的數(shù)據(jù)邀泉，并且DB也沒有查詢到數(shù)據(jù)，此時大量的請求都會直接到達DB，導致DB承載高并發(fā)的問題汇恤。解決緩存穿透的問題可以對DB也沒有的數(shù)據(jù)返回一個空標識的數(shù)據(jù)庞钢，進而保存到各級緩存中，因為有對數(shù)據(jù)修改的異步監(jiān)聽因谎，所以當數(shù)據(jù)有更新基括，新的數(shù)據(jù)會被更新到緩存匯中。

nginx緩存失效導致redis壓力倍增

可以在nginx本地财岔，設置緩存數(shù)據(jù)的時候隨機緩存的有效期风皿，避免同一時刻緩存都失效而大量請求直接進入redis

這個過程值得我們?nèi)ド钊雽W習和思考。如果對你有幫助請動動小手關注下吧匠璧！

進群：可以領取免費的架構(gòu)師學習資料桐款。

進群：了解最新的學習動態(tài)

進群：了解最新的阿里，京東招聘資訊

進群：獲取更多的面試資料

1夷恍、具有1-5工作經(jīng)驗的魔眨，面對目前流行的技術(shù)不知從何下手，需要突破技術(shù)

瓶頸的可以加群酿雪。

2遏暴、在公司待久了，過得很安逸指黎，但跳槽時面試碰壁朋凉。需要在短時間內(nèi)進修

、跳槽拿高薪的可以加群醋安。

3杂彭、如果沒有工作經(jīng)驗，但基礎非常扎實茬故，對java工作機制盖灸，常用設計思想

，常用java開發(fā)框架掌握熟練的磺芭，可以加群赁炎。

4、覺得自己很牛B钾腺，一般需求都能搞定徙垫。但是所學的知識點沒有系統(tǒng)化，很

難在技術(shù)領域繼續(xù)突破的可以加群放棒。

5. 群號：835638062 點擊鏈接加入群：https://jq.qq.com/?

_wv=1027&k=5S3kL3v

6.阿里Java高級大牛直播講解知識點姻报，分享知識，上面五大專題都是各位老

師多年工作經(jīng)驗的梳理和總結(jié)间螟，帶著大家全面吴旋、科學地建立自己的技術(shù)體系

和技術(shù)認知损肛！