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問題；但不保證一致性，邏輯過期時間增加程式碼維護成本。