1、先查快取，快取不存在查資料庫，資料庫中如果存在則存入快取
問題：大量不存在的資料導致資料庫的查詢頻次高，有900多萬次；因為該功能上線預設為不存在，所以正常使用者訪問也是每次都查詢
2、先查快取，快取中不存在查資料庫，資料庫如果存在則存結果入快取；如果不存在則存-1入快取；
資料庫的查詢次數明顯降低為不到50萬
3、先查bloom過濾器，如果不存在則返回；如果存在則查詢快取，快取中不存在查資料庫，資料庫如果存在則存結果入快取，設定bloom過濾器
開發庫中memorys表是redis中資料大小
7391未設定之前的資訊
127.0.0.1:7391> info
used_memory:857656
used_memory_human:837.55k
設定1000萬 bit後的資訊：
used_memory:2958968
used_memory_human:2.82m
設定10億 bit後的資訊：
used_memory:126693872
used_memory_human:120.82m
設定100億 bit後的資訊：
used_memory:541955448
used_memory_human:516.85m
設定100萬個key為uif:userid,field為aqs,value：-1後
used_memory:121227320
used_memory_human:115.61m
設定1萬個最大值為100億的key為uif:userid,field為aqs,value：-1後
used_memory:2134728
used_memory_human:2.04m
寫入1000萬個1至檔案.txt中，較快，大小為9.53m
在目前的大小下，占用記憶體較小；
結論：根據最大值和值的稀疏程度來確定使用哪種方案
如果最大值較大且值比較稀，則選擇使用方案2；否則可以使用方案1
快取雪崩，快取穿透解決方案
負載過高，甚至宕機。解決思路 1，採用加鎖計數，或者使用合理的佇列數量來避免快取失效時對資料庫造成太大的壓力。這種辦法雖然能緩解資料庫的壓力，但是同時又降低了系統的吞吐量。2，分析使用者行為，盡量讓失效時間點均勻分布。避免快取雪崩的出現。3，如果是因為某台快取伺服器宕機，可以考慮做主備，比如 red...
快取雪崩，快取穿透解決方案
快取雪崩可能是因為資料未載入到快取中，或者快取同一時間大面積的失效，從而導致所有請求都去查資料庫，導致資料庫cpu和記憶體負載過高，甚至宕機。解決思路 1，採用加鎖計數，或者使用合理的佇列數量來避免快取失效時對資料庫造成太大的壓力。這種辦法雖然能緩解資料庫的壓力，但是同時又降低了系統的吞吐量。2，分...
快取雪崩，快取穿透解決方案
解決辦法 對所有可能查詢的引數以hash形式儲存，在控制層先進行校驗，不符合則丟棄。2.快取失效 如果快取集中在一段時間內失效，db的壓力凸顯。這個沒有完美解決辦法，但可以分析使用者行為，盡量讓失效時間點均勻分布。快取雪崩可能是因為資料未載入到快取中，或者快取同一時間大面積的失效，從而導致所有請求都...