缺點
快取和資料庫雙寫一致性問題
快取雪崩問題
快取擊穿問題
快取的併發競爭key的問題
解決方案：
首先採取合適的更新策略，先更新資料庫 ，再刪除快取 。
其次可能因為存在刪除快取失敗的問題，提供乙個補償措施：例如 使用訊息佇列即快取同一時間大面積失效 ，這時候又來了一撥請求 ，結果都落到了資料庫上 ，導致資料庫連線異常
解決方案：
給快取加上隨機的失效時間，防止集體失效
使用互斥鎖，但是該方法吞吐量明顯下降
雙快取，快取a過期時間為20分鐘，快取b不設定過期時間 。自己做快取預熱
即黑客故意去請求快取中不存在的資料，導致請求全都落在了資料庫上，是的資料庫發生連線異常
解決方案：
利用互斥鎖，快取失效的時候，先去獲取鎖，得到鎖了再去請求資料庫。沒得到鎖，則休眠一段時間，重試
採用非同步更新策略，無論key是否取到值，都直接返回。value值中維護乙個快取失效時間，快取如果過期，非同步起乙個執行緒去讀資料庫，更新快取。需要做快取預熱（專案啟動前先載入快取）操作。
提供乙個可以迅速判斷請求是否有效的攔截機制。比如：布隆過濾器，內部維護一系列合法的有效的 key。迅速判斷出攜帶的key是否合法有效。如果不合法，則直接返回。u1
解決方案：
如果對這個key的執行不要求按照順序，那麼準備乙個分布式鎖，大家去搶鎖，搶到鎖就做set操作即可 ，比較簡單。
如果對這個key的執行要求按照順序
假設有乙個key1，系統a要將key1 設定為valuea，系統b要將key1 設定為valueb，系統c要將key1 設定為valuec。期望key1的value值按照 valuea–valueb–valuec 的順序進行變化。這時候我們在資料寫入資料庫的時候，應該儲存乙個時間戳。
分布式鎖 使用Redis實現分布式鎖
關於分布式鎖的實現，我的前一篇文章講解了如何使用zookeeper實現分布式鎖。關於分布式鎖的背景此處不再做贅述，我們直接討論下如何使用redis實現分布式鎖。關於redis，筆主不打算做長篇大論的介紹，只介紹下redis優秀的特性。支援豐富的資料型別，如string list map set zs...
redis實現分布式鎖
隨便 系統越來越大，各功能模組除了垂直切割以外，同時也得做集群處理，那麼問題來了，在多執行緒情況下對於資源的競爭就需要乙個統一的訪問限制。以選課系統為例子，集群中各節點對課程可選數量同時操作，這裡就需要同步了，否則會導致最後選到的數量比可選的數量大，這裡我們的分布式鎖就派上用場了。利用redis來實...
redis實現分布式鎖
分布式鎖可以基於很多種方式實現，比如zookeeper redis.不管哪種方式，他的 基本原理是不變的 用乙個狀態值表示鎖，對鎖的占用和釋放通過狀態值來標識。1 使用redis的setnx命令實現分布式鎖 1 實現的原理 redis為單程序單執行緒模式，採用佇列模式將併發訪問變成序列訪問，且多客戶...