解決辦法：對所有可能查詢的引數以hash形式儲存，在控制層先進行校驗，不符合則丟棄。
2.快取失效：如果快取集中在一段時間內失效，db的壓力凸顯。這個沒有完美解決辦法，但可以分析使用者行為，盡量讓失效時間點均勻分布。
快取雪崩可能是因為資料未載入到快取中，或者快取同一時間大面積的失效，從而導致所有請求都去查資料庫，導致資料庫cpu和記憶體負載過高，甚至宕機。
解決思路：
1，採用加鎖計數，或者使用合理的佇列數量來避免快取失效時對資料庫造成太大的壓力。這種辦法雖然能緩解資料庫的壓力，但是同時又降低了系統的吞吐量。
2，分析使用者行為，盡量讓失效時間點均勻分布。避免快取雪崩的出現。
3，如果是因為某台快取伺服器宕機，可以考慮做主備，比如：redis主備，但是雙快取涉及到更新事務的問題，update可能讀到髒資料，需要好好解決。
快取穿透是指使用者查詢資料，在資料庫沒有，自然在快取中也不會有。這樣就導致使用者查詢的時候，在快取中找不到，每次都要去資料庫中查詢。
解決思路：
2，根據快取資料key的規則。例如我們公司是做機頂盒的，快取資料以mac為key，mac是有規則，如果不符合規則就過濾掉，這樣可以過濾一部分查詢。在做快取規劃的時候，key有一定規則的話，可以採取這種辦法。這種辦法只能緩解一部分的壓力，過濾和系統無關的查詢，但是無法**。
大併發的快取穿透會導致快取雪崩。
單機web系統情況下比較簡單。
解決思路：
1，直接寫個快取重新整理頁面，上線時手工操作下。
2，資料量不大，可以在web系統啟動的時候載入。
解決思路：
1，寫個程式去跑。
快取預熱的目標就是在系統上線前，將資料載入到快取中。
快取穿透
一般的快取系統，都是按照key去快取查詢，如果不存在對應的value，就應該去後端系統查詢（比如db）。如果key對應的value是一定不存在的，並且對該key併發請求量很大，就會對後端系統造成很大的壓力。這就叫做快取穿透。
1：對查詢結果為空的情況也進行快取，快取時間設定短一點，或者該key對應的資料insert了之後清理快取。 2：對一定不存在的key進行過濾。可以把所有的可能存在的key放到乙個大的bitmap中，查詢時通過該bitmap過濾。【感覺應該用的不多吧】
快取雪崩
當快取伺服器重啟或者大量快取集中在某乙個時間段失效，這樣在失效的時候，也會給後端系統(比如db)帶來很大壓力。
1：在快取失效後，通過加鎖或者佇列來控制讀資料庫寫快取的執行緒數量。比如對某個key只允許乙個執行緒查詢資料和寫快取，其他執行緒等待。 2：不同的key，設定不同的過期時間，讓快取失效的時間點盡量均勻。 3：做二級快取，a1為原始快取，a2為拷貝快取，a1失效時，可以訪問a2，a1快取失效時間設定為短期，a2設定為長期（此點為補充）
分布式快取系統
快取一致性問題
1：快取系統與底層資料的一致性。這點在底層系統是「可讀可寫」時，寫得尤為重要
2：有繼承關係的快取之間的一致性。為了盡量提高快取命中率，快取也是分層：全域性快取，二級快取。他們是存在繼承關係的。全域性快取可以有二級快取來組成。
3：多個快取副本之間的一致性。為了保證系統的高可用性，快取系統背後往往會接兩套儲存系統（如memcache，redis等）
快取穿透和快取雪崩
上面有講述。
快取淘汰的策略有兩種： (1) 定時去清理過期的快取。 （2）當有使用者請求過來時，再判斷這個請求所用到的快取是否過期，過期的話就去底層系統得到新資料並更新快取。 兩者各有優劣，第一種的缺點是維護大量快取的key是比較麻煩的，第二種的缺點就是每次使用者請求過來都要判斷快取失效，邏輯相對比較複雜，具體用哪種方案，大家可以根據自己的應用場景來權衡。 1. 預估失效時間 2. 版本號（必須單調遞增，時間戳是最好的選擇）3. 提供手動清理快取的介面。
fifo演算法：first in first out，先進先出。原則：乙個資料最先進入快取中，則應該最早淘汰掉。也就是說，當快取滿的時候，應當把最先進入快取的資料給淘汰掉。
lfu演算法：least frequently used，最不經常使用演算法。
lru演算法：least recently used，近期最少使用演算法。請檢視：memcached之你真正理解lru嗎(4)
lru和lfu的區別。lfu演算法是根據在一段時間裡資料項被使用的次數選擇出最少使用的資料項，即根據使用次數的差異來決定。而lru是根據使用時間的差異來決定的
技術改變世界！ --狂詩絕劍
快取雪崩，快取穿透解決方案
負載過高，甚至宕機。解決思路 1，採用加鎖計數，或者使用合理的佇列數量來避免快取失效時對資料庫造成太大的壓力。這種辦法雖然能緩解資料庫的壓力，但是同時又降低了系統的吞吐量。2，分析使用者行為，盡量讓失效時間點均勻分布。避免快取雪崩的出現。3，如果是因為某台快取伺服器宕機，可以考慮做主備，比如 red...
快取雪崩，快取穿透解決方案
快取雪崩可能是因為資料未載入到快取中，或者快取同一時間大面積的失效，從而導致所有請求都去查資料庫，導致資料庫cpu和記憶體負載過高，甚至宕機。解決思路 1，採用加鎖計數，或者使用合理的佇列數量來避免快取失效時對資料庫造成太大的壓力。這種辦法雖然能緩解資料庫的壓力，但是同時又降低了系統的吞吐量。2，分...
快取雪崩和快取穿透解決方案
快取雪崩和快取穿透 快取雪崩 簡單的說就是快取失效，原本該訪問快取的資料直接訪問資料庫，從而造成資料庫和記憶體壓力大，嚴重的可能導致資料庫宕機 伺服器崩潰。解決方案 1.使用分布式鎖或者對列控制讀資料庫寫快取的執行緒數，保證這有乙個個執行緒進行操作。缺 點降低了系統的吞吐量 2.redis中的key...