redis使用中存在的問題及如何避免(二)

redis使用中存在的問題及如何避免(一)闡述了redis的阻塞問題及緩存穿透問題，本文將繼續總結redis在使用中的問題及方案。

• 無底洞問題
  隨着數據量和訪問量的增加，須要增長更多的節點作水平擴容，鍵值會分佈到更多的節點上，若客戶端進行批量操做則一般會從不一樣的節點上獲取數據，相比於單機批量操做只涉及一次網絡操做，分佈式批量操做會涉及屢次網絡交互。
  隨着節點數的增多，客戶端一次批量操做涉及的網絡交互耗時也會不斷增大；網絡鏈接數增多，對節點性能也有必定影響。
  更多的節點不表明更高的性能，這就是無底洞問題。

• 雪崩問題
  因爲緩存層承載着大量請求，有效的保護了存儲層，但若是緩存層因爲某些緣由不能提供服務，全部請求都會壓到存儲層，存儲層流量暴增，致使存儲層也會級聯宕機。

  1. 保證緩存層服務高可用性
     Redis Sentinel或者Redis Cluster都實現了高可用
  2. 隔離限流降級
     對重要的資源Redis、Mysql、外部接口調用都進行隔離，機器、進程、線程等層面均可作隔離。
     可以使用漏桶、令牌桶等方式進行限流操做，將流量擋在應用上層。
     對出現問題的數據或功能作降級處理，友好的展現給用戶。
  3. 提早演練測試

• 熱點key重建優化
  緩存+過時時間策略便可以加速數據讀寫，又保證數據的按期更新，若出現以下兩個問題，可能會對應用產生致命危害：

  1. 當前key是一個熱點key，併發量很是大

  2. 重建緩存不能在短期內完成，如：複雜的sql、屢次IO、多個依賴等。
     在緩存失效的瞬間，有大量的線程來建立緩存，形成後端負載加大，甚至致使系統崩潰。
     方案：

     a.互斥鎖
       只容許有一個線程去重建數據，其餘線程等待構建完緩存，從新從緩存中獲取數據。
     b.永遠不過時
       設置邏輯過時時間，判斷邏輯時間和當前時間大小，而後異步去構建數據覆蓋老數據。
       
     a方案思路簡單，能保證一致性；但代碼複雜度增大，存在死鎖風險，存在線程池阻塞風險。
     b方案基本能夠杜絕熱點key問題；但不保證一致性，邏輯過時時間增長代碼維護成本。