緩存一致性問題
當數(shù)據(jù)時效性要求很高時懦鼠，需要保證緩存中的數(shù)據(jù)與數(shù)據(jù)庫中的保持一致谚殊，而且需要保證緩存節(jié)點和副本中的數(shù)據(jù)也保持一致偎蘸，不能出現(xiàn)差異現(xiàn)象聚蝶。這就比較依賴緩存的過期和更新策略篡殷。一般會在數(shù)據(jù)發(fā)生更改的時钝吮，主動更新緩存中的數(shù)據(jù)或者移除對應的緩存。
緩存并發(fā)問題
緩存過期后將嘗試從后端數(shù)據(jù)庫獲取數(shù)據(jù)板辽，這是一個看似合理的流程奇瘦。但是，在高并發(fā)場景下劲弦，有可能多個請求并發(fā)的去從數(shù)據(jù)庫獲取數(shù)據(jù)耳标，對后端數(shù)據(jù)庫造成極大的沖擊，甚至導致 “雪崩”現(xiàn)象邑跪。此外次坡，當某個緩存key在被更新時，同時也可能被大量請求在獲取画畅，這也會導致一致性的問題砸琅。那如何避免類似問題呢？我們會想到類似“鎖”的機制轴踱，在緩存更新或者過期的情況下症脂，先嘗試獲取到鎖，當更新或者從數(shù)據(jù)庫獲取完成后再釋放鎖，其他的請求只需要犧牲一定的等待時間诱篷，即可直接從緩存中繼續(xù)獲取數(shù)據(jù)壶唤。
緩存穿透問題
緩存穿透在有些地方也稱為“擊穿”。很多朋友對緩存穿透的理解是：由于緩存故障或者緩存過期導致大量請求穿透到后端數(shù)據(jù)庫服務器棕所，從而對數(shù)據(jù)庫造成巨大沖擊闸盔。
這其實是一種誤解。真正的緩存穿透應該是這樣的：
在高并發(fā)場景下橙凳，如果某一個key被高并發(fā)訪問，沒有被命中笑撞，出于對容錯性考慮岛啸，會嘗試去從后端數(shù)據(jù)庫中獲取，從而導致了大量請求達到數(shù)據(jù)庫茴肥，而當該key對應的數(shù)據(jù)本身就是空的情況下坚踩，這就導致數(shù)據(jù)庫中并發(fā)的去執(zhí)行了很多不必要的查詢操作，從而導致巨大沖擊和壓力瓤狐。
可以通過下面的幾種常用方式來避免緩存?zhèn)鹘y(tǒng)問題：
1. 緩存空對象
對查詢結(jié)果為空的對象也進行緩存瞬铸，如果是集合，可以緩存一個空的集合（非null）础锐，如果是緩存單個對象嗓节，可以通過字段標識來區(qū)分。這樣避免請求穿透到后端數(shù)據(jù)庫皆警。同時拦宣，也需要保證緩存數(shù)據(jù)的時效性。這種方式實現(xiàn)起來成本較低信姓，比較適合命中不高鸵隧，但可能被頻繁更新的數(shù)據(jù)。
2. 單獨過濾處理
對所有可能對應數(shù)據(jù)為空的key進行統(tǒng)一的存放意推，并在請求前做攔截豆瘫，這樣避免請求穿透到后端數(shù)據(jù)庫。這種方式實現(xiàn)起來相對復雜菊值，比較適合命中不高外驱，但是更新不頻繁的數(shù)據(jù)。
緩存顛簸問題
緩存的顛簸問題腻窒，有些地方可能被成為“緩存抖動”略步，可以看做是一種比“雪崩”更輕微的故障，但是也會在一段時間內(nèi)對系統(tǒng)造成沖擊和性能影響定页。一般是由于緩存節(jié)點故障導致趟薄。業(yè)內(nèi)推薦的做法是通過一致性Hash算法來解決。這里不做過多闡述典徊，可以參照其他章節(jié)
緩存的雪崩現(xiàn)象
緩存雪崩就是指由于緩存的原因杭煎，導致大量請求到達后端數(shù)據(jù)庫恩够，從而導致數(shù)據(jù)庫崩潰，整個系統(tǒng)崩潰羡铲，發(fā)生災難蜂桶。導致這種現(xiàn)象的原因有很多種，上面提到的“緩存并發(fā)”也切，“緩存穿透”扑媚，“緩存顛簸”等問題，其實都可能會導致緩存雪崩現(xiàn)象發(fā)生雷恃。這些問題也可能會被惡意攻擊者所利用疆股。還有一種情況，例如某個時間點內(nèi)倒槐，系統(tǒng)預加載的緩存周期性集中失效了旬痹，也可能會導致雪崩。為了避免這種周期性失效讨越，可以通過設置不同的過期時間两残，來錯開緩存過期，從而避免緩存集中失效把跨。
從應用架構(gòu)角度人弓，我們可以通過限流、降級着逐、熔斷等手段來降低影響票从，也可以通過多級緩存來避免這種災難。
此外滨嘱，從整個研發(fā)體系流程的角度峰鄙，應該加強壓力測試，盡量模擬真實場景太雨，盡早的暴露問題從而防范吟榴。
緩存無底洞現(xiàn)象
該問題由 facebook 的工作人員提出的， facebook 在 2010 年左右囊扳，memcached 節(jié)點就已經(jīng)達3000 個吩翻，緩存數(shù)千 G 內(nèi)容。
他們發(fā)現(xiàn)了一個問題---memcached 連接頻率锥咸，效率下降了狭瞎，于是加 memcached 節(jié)點，添加了后搏予，發(fā)現(xiàn)因為連接頻率導致的問題熊锭，仍然存在，并沒有好轉(zhuǎn)，稱之為”無底洞現(xiàn)象”碗殷。
目前主流的數(shù)據(jù)庫精绎、緩存、Nosql锌妻、搜索中間件等技術(shù)棧中代乃，都支持“分片”技術(shù)，來滿足“高性能仿粹、高并發(fā)搁吓、高可用、可擴展”等要求吭历。有些是在client端通過Hash取模（或一致性Hash）將值映射到不同的實例上堕仔，有些是在client端通過范圍取值的方式映射的。當然毒涧，也有些是在服務端進行的贮预。但是贝室，每一次操作都可能需要和不同節(jié)點進行網(wǎng)絡通信來完成契讲，實例節(jié)點越多，則開銷會越大滑频，對性能影響就越大捡偏。
主要可以從如下幾個方面避免和優(yōu)化：
1. 數(shù)據(jù)分布方式
有些業(yè)務數(shù)據(jù)可能適合Hash分布，而有些業(yè)務適合采用范圍分布峡迷，這樣能夠從一定程度避免網(wǎng)絡IO的開銷银伟。
2. IO優(yōu)化
可以充分利用連接池，NIO等技術(shù)來盡可能降低連接開銷绘搞，增強并發(fā)連接能力彤避。
3. 數(shù)據(jù)訪問方式
一次性獲取大的數(shù)據(jù)集，會比分多次去獲取小數(shù)據(jù)集的網(wǎng)絡IO開銷更小夯辖。
當然琉预，緩存無底洞現(xiàn)象并不常見。在絕大多數(shù)的公司里可能根本不會遇到蒿褂。
歡迎工作一到五年的Java工程師朋友們加入Java高并發(fā)： 957734884圆米，群內(nèi)提供免費的Java架構(gòu)學習資料（里面有高可用、高并發(fā)啄栓、高性能及分布式娄帖、Jvm性能調(diào)優(yōu)、Spring源碼昙楚，MyBatis近速，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構(gòu)資料）合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕数焊，使勁拼永淌，給未來的自己一個交代！
出處：https://blog.csdn.net/dinglang_2009/article/details/53464196
版權(quán)申明：內(nèi)容來源網(wǎng)絡佩耳，版權(quán)歸原創(chuàng)者所有遂蛀。除非無法確認，我們都會標明作者及出處干厚，如有侵權(quán)煩請告知李滴，我們會立即刪除并表示歉意。謝謝蛮瞄。
