後端分布式快取是**服務端經常用到的一種技術，在讀多寫少的業務場景中，通過使用快取可以有效地支撐高併發的訪問量，對後端的資料庫等資料來源做到很好地保護。現在市面上有很多分布式快取，比如redis、memcached以及阿里的tair等，不管我們使用的哪種快取產品，基本上都會遇到快取擊穿、快取失效以及熱點key的問題。如何有效地防止這些問題，也是我們在享受快取帶來的紅利地同時，必須要解決地難題。
通常我們在使用快取時候都是先檢查快取中是否存在，如果存在直接返回快取內容，如果不存在就直接查詢資料庫然後再快取查詢結果返回，例如下圖所示，
查詢乙個資料庫中不存在的資料，比如商品詳情，查詢乙個不存在的id，每次都會訪問db，如果有人惡意破壞，很可能直接對db造成過大地壓力。
當通過某乙個key去查詢資料的時候，如果對應在資料庫中的資料都不存在，我們將此key對應的value設定為乙個預設的值，比如「null」，並設定乙個快取的失效時間，這時在快取失效之前，所有通過此key的訪問都被快取擋住了。後面如果此key對應的資料在db中存在時，快取失效之後，通過此key再去訪問資料，就能拿到新的value了。
在高併發的環境下，如果此時key對應的快取失效，此時有多個程序就會去同時去查詢db，然後再去同時設定快取。這個時候如果這個key是系統中的熱點key或者同時失效的數量比較多時，db訪問量會瞬間增大，造成過大的壓力。
將系統中key的快取失效時間均勻地錯開，防止統一時間點有大量的key對應的快取失效；
重新設計快取的使用方式，當我們通過key去查詢資料時，首先查詢快取，如果此時快取中查詢不到，就通過分布式鎖進行加鎖，取得鎖的程序查db並設定快取，然後解鎖；其他程序如果發現有鎖就等待，然後等解鎖後返回快取資料或者再次查詢db。
快取中的某些key(可能對應用與某個**商品)對應的value儲存在集群中一台機器，使得所有流量湧向同一機器，成為系統的瓶頸，該問題的挑戰在於它無法通過增加機器容量來解決。
客戶端熱點key快取：將熱點key對應value並快取在客戶端本地，並且設定乙個失效時間。對於每次讀請求，將首先檢查key是否存在於本地快取中，如果存在則直接返回，如果不存在再去訪問分布式快取的機器。
將熱點key分散為多個子key，然後儲存到快取集群的不同機器上，這些子key對應的value都和熱點key是一樣的。當通過熱點key去查詢資料時，通過某種hash演算法隨機選擇乙個子key，然後再去訪問快取機器，將熱點分散到了多個子key上。
架構 快取擊穿問題解決方案
先看一下這個偽 邏輯 data redis.getdata if data null data db.getdata redis.set data return data 這段 看起來沒什麼問題，當從快取中取不到資料時，穿透到db獲取資料，並將資料寫入快取。邏輯是沒有問題的，但是在高併發下會有問題，...
Mysql問題解決思路
資料庫層面 一 檢查問題常用工具 1 msyqladmin mysql客戶端，可進行管理操作 2 mysqlshow 功能強大的檢視shell命令 3 show session global variables 檢視資料庫引數資訊 4 show session global status 檢視資料庫...
快取穿透問題解決！！！
快取穿透是指查詢乙個一定不存在的資料，由於快取是不命中時被動寫的，並且出於容錯考慮，如果從儲存層查不到資料則不寫入快取，這將導致這個不存在的資料每次請求都要到儲存層去查詢，失去了快取的意義。在流量大時，可能db就掛掉了，要是有人利用不存在的key頻繁攻擊我們的應用，這就是漏洞。有很多種方法可以有效地...