使用Redis緩存所帶來的好處：
1.降低后端的負載：
對高消耗的SQL:join結果集/分組統計結果緩存
2.加速請求時間：
在內存中做IO操作很快
3.大量寫合並為批量寫：
頻繁更新某一個值，可以在緩存層面統一處理了，再寫入到數據庫中。
緩存更新策略
1.LRU/LFU/FIFO算法剔除，給緩存設置一個maxmemory-policy，緩沖自動選擇策略去更新（對於低一致性的，我們采用最大內存更新策略）
2.設置過期時間，對於一些一致性要求不高的，我們可以用這種方法。
3.主動更新，開發控制生命周期，一致性要求比較高的采用這種方法。（可以用一個消息隊列，當數據庫中內容修改了，通知到消費者去重新查數據庫）
當對一致性有一定要求的時候，我們采用2,3，最大內存更新策略兜底。
下面是主動更新的幾種情況：
一個服務調用的過程：
3種策略：
1.先更新數據庫，再更新緩存。
A更新數據庫->B更新數據庫->B更新緩存->A更新緩存（導致不一致）
2.先刪除緩存再更新數據庫。
A寫入數據庫，先刪除緩存->B去查詢，緩存沒有數據->B去查詢數據庫讀取舊值並更新緩存->A寫入數據庫（導致不一致）
延時雙刪策略：
A刪除緩存->A寫入數據庫->睡眠1s再刪除緩存
3.先更新再刪除
緩存剛好失效->A查詢數據庫得到舊值->B更新數據庫->B刪除緩存->A更新緩存（導致不一致）
出現這種的情況很低，寫很慢。
在實際的項目中，我們采用2,3兩種情況，對於並發量比較小的情況，我們可以直接采用 2，但是對於並發量很大的時候，2還是會出現不一致。
對於2在高並發的情況下我們的解決方案是：
對於一個工作線程建一個內存隊列，每個工作線程串行拿到對應的操作，然后一條一條的執行。這樣的話，一個數據變更的操作，先刪除緩存，然后再去更新數據庫，但是還沒完成更新。此時如果一個讀請求過來，讀到了空的緩存，那么可以先將緩存更新的請求發送到隊列中，此時會在隊列中積壓，然后同步等待緩存更新完成。（這樣就可以保證一致的問題了）。
這里的優化點就是更新數據庫同一個字段或者讀請求更新緩存都可以直接用后面的去替代前面的，不用重復操作。
待那個隊列對應的工作線程完成了上一個操作的數據庫的修改之后，才會去執行下一個操作，也就是緩存更新的操作，此時會從數據庫中讀取最新的值，然后寫入緩存中。
如果請求還在等待時間范圍內，不斷輪詢發現可以取到值了，那么就直接返回；如果請求等待的時間超過一定時長，那么這一次直接從數據庫中讀取當前的舊值。
出現的一些問題：
1、讀請求長時阻塞
由於讀請求進行了非常輕度的異步化，所以一定要注意讀超時的問題，每個讀請求必須在超時時間范圍內返回。
該解決方案，最大的風險點在於說，可能數據更新很頻繁，導致隊列中積壓了大量更新操作在里面，然后讀請求會發生大量的超時，最后導致大量的請求直接走數據庫。務必通過一些模擬真實的測試，看看更新數據的頻率是怎樣的。
另外一點，因為一個隊列中，可能會積壓針對多個數據項的更新操作，因此需要根據自己的業務情況進行測試，可能需要部署多個服務，每個服務分攤一些數據的更新操作。如果一個內存隊列里居然會擠壓 100 個商品的庫存修改操作，每隔庫存修改操作要耗費 10ms 去完成，那么最后一個商品的讀請求，可能等待 10 * 100 = 1000ms = 1s 后，才能得到數據，這個時候就導致讀請求的長時阻塞。
一定要做根據實際業務系統的運行情況，去進行一些壓力測試，和模擬線上環境，去看看最繁忙的時候，內存隊列可能會擠壓多少更新操作，可能會導致最后一個更新操作對應的讀請求，會 hang 多少時間，如果讀請求在 200ms 返回，如果你計算過后，哪怕是最繁忙的時候，積壓 10 個更新操作，最多等待 200ms，那還可以的。
如果一個內存隊列中可能積壓的更新操作特別多，那么你就要加機器，讓每個機器上部署的服務實例處理更少的數據，那么每個內存隊列中積壓的更新操作就會越少。
這主要還是強一致和性能的一個抉擇：（像上面的2加隊列這種情況就是一種強一致）
3這種方案就是在並不是很要求強一致的情況下，我們可以短暫的追求性能，在用戶讀的時候，可能並不是最實時的數據，但是不會出現阻塞這種問題。
具體的情況還是要根據具體的場景來決定
緩存粒度控制
選用全量屬性，通用性會更好，也便於維護，像user表這種，用全量屬性還可以，
但我們選用緩存就需要考慮性能和空間的問題，只保存我們需要的屬性就好了（但后期表結構改了，維護性很差）
緩存穿透：（直接對存儲層操作，失去了緩存層的意義）
查詢一個數據庫中不存在的數據，比如商品詳情，查詢一個不存在的ID，每次都會訪問DB，如果有人惡意破壞，很可能直接對DB造成過大地壓力。
解決方案：
1.當通過某一個key去查詢數據的時候，如果對應在數據庫中的數據都不存在，我們將此key對應的value設置為一個默認的值，比如“NULL”，並設置一個緩存的失效時間，這時在緩存失效之前，所有通過此key的訪問都被緩存擋住了。后面如果此key對應的數據在DB中存在時，緩存失效之后，通過此key再去訪問數據，就能拿到新的value了。
2.常見的則是采用布隆過濾器（可以用很小的內存保留很多的數據），將所有可能存在的數據哈希到一個足夠大的bitmap中，一個一定不存在的數據會被 這個bitmap攔截掉，從而避免了對底層存儲系統的查詢壓力。（布隆過濾器：實際上是一個很長的二進制向量和一系列隨機映射函數。布隆過濾器可以用於檢索一個元素是否在一個集合中。它的優點是空間效率和查詢時間都遠遠超過一般的算法，缺點是有一定的誤識別率和刪除困難。）
關於布隆過濾器：
緩存雪崩：（緩存失效）
緩存同一時間大面積的失效，所以，后面的請求都會落到數據庫上，造成數據庫短時間內承受大量請求而崩掉。
解決方案：
1.將系統中key的緩存失效時間均勻地錯開，防止統一時間點有大量的key對應的緩存失效；
2.重新設計緩存的使用方式，當我們通過key去查詢數據時，首先查詢緩存，如果此時緩存中查詢不到，就通過分布式鎖進行加鎖，取得鎖的進程查DB並設置緩存，然后解鎖；其他進程如果發現有鎖就等待，然后等解鎖后返回緩存數據或者再次查詢DB。
3.盡量保證整個 redis 集群的高可用性，發現機器宕機盡快補上
4.本地memcache緩存 + hystrix限流&降級，避免MySQL崩掉
假如已經崩潰了：也可以利用redis的持久化機制將保存的數據盡快恢復到緩存里。
緩存無底洞：
為了滿足業務大量加節點，但是性能沒提升反而下降。
當客戶端增加一個緩存的時候，只需要 mget 一次，但是如果增加到三台緩存，這個時候則需要 mget 三次了（網絡通信的時間增加了），每增加一台，客戶端都需要做一次新的 mget，給服務器造成性能上的壓力。
同時，mget 需要等待最慢的一台機器操作完成才能算是完成了 mget 操作。這還是並行的設計，如果是串行的設計就更加慢了。
通過上面這個實例可以總結出：更多的機器！=更高的性能
但是並不是沒辦法，一般在優化 IO 的時候可以采用以下幾個方法。
- 命令的優化。例如慢查下 keys、hgetall bigkey。
- 我們需要減少網絡通訊的次數。這個優化在實際應用中使用次數是最多的，我們盡量減少通訊次數。
- 降低接入成本。比如使用客戶端長連接或者連接池、NIO 等等。
參考：https://blog.csdn.net/hukaijun/article/details/81010475（講的非常好）緩存數據庫一致問題