如今，快取系統的應用非常廣泛，能夠用來提高併發數、資料吞吐量，提高快速響應能力。那麼當資料量達到一定程度，單機環境可能就顯得有些力不從心了，就需要一個分散式快取系統。

1. 快取系統的選擇

1.1 快取分類

如上圖所示，首先快取大致可以分為四大類。

• CDN 快取：CDN 即內容分發網路，CDN 邊緣節點將資料快取起來。
• 反向代理快取：如 Nginx 的快取。
• 本地快取：代表的有 EhCache 和 Guava Cache。
• 分散式快取：各快取系統。

1.2 分散式快取

本文主要探討各分散式快取系統，如圖 1-1 所示，列出了五種：

其中 EvCache 和 Aerospike 使用場景不是那麼通用和廣泛。

• EvCache：是 Netflix 的基於 Memcached & Spymemcached 的快取方案。
• Aerospike：是可基於 SSD 的 KV NoSQL 資料庫。

除此之外，還有三種常見快取系統。

• Tair：阿里開源，跨機房、效能隨結點新增線性上升、適用大資料量。Tair 還有三種引擎。

• • LDB: 基於 google levelDB，支援 KV和類 HashMap 結構，效能稍低，持久化可靠性最高。
  • MDB: 基於 Memcache，支援 KV 和類 HashMap，效能最優，不支援持久化儲存。
  • RDB: 基於 Redis。

• Memcache: 不支援資料同步、分散式支援較差。

• Redis: 社群活躍、使用最多。

綜上所述，在一般情況下，考慮到適用性和穩定性，Redis 是搭建快取系統的最優選擇。以下將基於 Redis 介紹。

2. Redis 叢集快取方案

如頂部圖 1-1 所示，列出了 Redis 的叢集高可用的方案，基本可以分為三種。

2.1 主從機制

常見的叢集架構，搭建簡單，主要實現讀寫分離和備份，可以由 Master 負責讀寫，Slave 負責備份。但存在故障恢復複雜、水平拓展難、寫能力受限等問題。結構圖如下：

2.2 哨兵機制

Redis Sentinel 是社群版本推出的原生高可用解決方案。由一或多個哨兵例項監視任意個主從伺服器，且在 Master 宕機時，自動將宕機伺服器屬下的 Slave 伺服器升級為 主伺服器，從而保證系統的可用性。較主從實現的監控、選主。但問題主要是要保證 Master 的 HA 切換。結構圖如下：

2.3 "分散式"

到這裡以上兩種機制其實只能算作“叢集”，並非嚴格意義上的“分散式”。接著來看看分散式方案。

叢集強調高可用，分散式在叢集的基礎上又強調協作。

3. Redis分散式快取方案

任何分散式儲存系統，首先面臨的就是 sharding（分片）問題，如頂部圖 1-1 所示該問題有為三種解決方法。

3.1 客戶端分片

顧名思義，將資料分片的路由功能交給客戶端，但這是一種靜態分片，維護性差。基本是不予考慮的。

3.2 代理分片

通過代理分發到具體的 redis 例項。有兩個常用解決方案。

• Twemproxy：Twitter 開源，輕量級，不再維護，無法平滑地擴容/縮容，運維也不是很友好，效能一般。
• Codis：豌豆莢開源，支援水平拓展，運維平臺完善，效能較 Twemproxy 快。Codis 在國內使用的較多，同時代理分片的思路也有很多公司在此基礎開發了自己的二次方案。不過 Codis 也不再維護。

其實，這兩種代理分片的方案，都是在 Redis 官方未推出良好的分散式方案時的產生的，在官方更新提供更優策略後都不再維護。

3.3 伺服器端分片

這就要談到 Redis 官方方案 Redis-cluster 。

在 Redis 3.0 之前是沒有較好的分散式方案的，這也是第三方方案出現的原因。3.0 開始，官方推出了去中心化的分散式方案。叢集中包含 16384 個雜湊槽，每個節點負責其中一部分。

先看下拓撲圖：

每個節點開啟兩個 TCP 連線，一個負責給客戶端提供服務，一個負責節點間通訊。

此刻要說說 CAP 了 ：Consistency（一致性）、Availability（可用性）、Partition tolerance（分割槽容錯性） 。對分散式系統而言，CAP 必須犧牲一者。Redis Cluster 的設計目標主要是高效能、高可用和高擴充套件，只好拋棄一部分資料一致性。

• 資料一致性：由於Redis Cluster 使用非同步複製， 在某些情況下如 Master 宕機但未同步至 Slave，可能會導致丟失寫入。在絕對需要支援同步寫入時，可通過 WAIT 命令實現，可使得丟失寫入的可能性大大降低。

• 可用性：當叢集中一部分節點故障後，叢集整體能響應客戶端讀寫請求。

• • 節點間定時互 ping ，當超過一半 Master 判定某節點失敗，則標記為 FAIL，且會向叢集廣播節點下線的訊息。如下線節點是帶有槽的主節點，則要從它的從節點選出一個替換。

• 高效能和拓展：操作某個 key 時，不會先找到節點再處理，而是直接直接重定向到該節點，同時相較代理分片也少了 proxy 的連線損耗。

• • 但是在進行 multiple key 操作時需要 keys 位於同一個 slot 上，需要使用 hash tags，使用 {} 強制將某些 key 對映到每個 slot，以便進行 multiple 。
  • 在拓展方面，Redis Cluster 最大支援線性拓展 1000 個節點，將新節點加入集群后可以通過命令指定和平均的從已有節點分配 slot。

4. 快取常見問題

以上介紹了簡單介紹了常見快取系統，並具體列出了基於 Redis 的叢集方案。下面談一談快取系統常見的問題。

如下圖所示，列出七個常見問題。

4.1. 快取穿透

指訪問不存在的資料，從而繞過快取，直接請求到了資料來源，當請求過多，就會對 DB 造成壓力。

• 空 key：指對於不存在的資料也將 key 存空值入快取系統，這樣下次訪問也會得到返回。但只適用於空資料 key 有限、key 重複請求概率高，如果量大且不重複，就會造成很多無用 key 的建立。
• 布隆過濾器：布隆過濾器是一個很長的二進位制向量和一系列隨機對映函式。可用於檢索一個元素是否在一個集合中加一層對空值的過濾器，空間和時間效率都很高。但由於 hash 產生的碰撞可能存在誤判，以及因不儲存 key 導致的無法刪除。適用於空資料 key 各不同、重複請求概率低。

4.2. 快取擊穿

快取擊穿實際是快取雪崩的一個特例。指當某些熱點 key 過期時，就會有大量的請求擊穿到 DB。

• 互斥鎖：在快取失效的時候，不立即 load db，可以先用如 SETNX 等命令去 set 一個 mutex key，當操作返回成功時，說明拿到鎖，此刻該執行緒進行 load db 的操作並更新快取；否則未拿到鎖就（可休眠一段）重試 get 快取的方法。但要注意死鎖風險。

• 不過期

• • 這裡的不過期有兩個概念，一個指未設過期時間，那是真的不過期，那沒事了。
  • 另一個是指通過業務邏輯，將 key 的過期時間進行儲存，請求是判斷是否小於值，是則後臺非同步更新。

4.3. 快取雪崩

同一時刻大量快取失效（故障）, 請求到了 DB。

• 隨機時間：在設定過期時間時，可以在基礎時間上 + 一個隨機的時間，等於實現了分批過期。
• 後臺更新：將更新失效的工作交給後臺定時執行緒。
• 限流 + 本地快取：如 ehcache 本地快取 + Hystrix 限流。
• 雙快取：類似於設定主從快取，從 key 不過期。

4.4. 快取更新與一致性

如果保證資料一致性。列出四種更新策略：

• Cache Aside ：最常用的。失效時回源取資料，更新；命中時，返回快取資料；更新時先資料來源更新，再更新快取。

• Write Back ：更新資料時，只更新快取，不更新資料來源。快取非同步批量更新資料庫。

• Read/Write Through

• • Write Through ：當有資料更新時，如未命中快取，直接更新資料庫，並返回。如命中快取，則更新快取，再由 Cache 自己更新資料庫。
  • Read Through ：更新資料來源由快取系統操作，讀取資料時如快取失效，則取回源資料更新快取。

4.5. 熱點資料

對於熱點資料的處理方法。

• 拆分複雜結構：如二級資料結構，進行拆分，這樣熱點 key 就被拆為若干個的 key 分佈到不同節點。
• 遷移熱點：對於 Redis Cluster 而言可以將熱點 key 所在的 slot 單獨遷移到一個節點，降低其他節點壓力。
• 多副本：複製多份快取副本，將請求分散到多個節點上，減輕單臺快取伺服器壓力，適合多讀少寫。

4.6. 快取預熱

指可以將某些的快取資料提前載入到快取系統，提前避免在如熱點資料大量請求到庫。

4.7. 快取降級

指當訪問量劇增、服務出現問題或非核心服務影響到核心流程的效能時，仍需保證主服務可用。可根據一些關鍵資料自動降級，也可配置開關人工降級。

5. Redis Cluster 使用

對於 Redis Cluster 環境的搭建和基礎使用非常簡單。

無論基於何種方式，只要搭建好 n 臺 redis 服務並保證各服務間可以互相通訊後，任意進入一個 redis 服務鍵入：

redis-cli --cluster create IP1:port1 IP2:port2 IP3:port3 IP4:port4 IP5:port5 IP6:port6 ... --cluster-replicas 1

即可。之後可以使用 cluster node 和 cluster info 命令檢視叢集、節點資訊。

而對於廣大 JAVA 開發，Spring Data Redis 從 1.7 起即支援 Redis Cluster，只需配置 Master 節點地址（和密碼）。

spring.redis.cluster.nodes=ip1:port1,ip2:port2,ip3:port3

加入依賴

compile("org.springframework.boot:spring-boot-starter-data-redis")

即可通過 RedisTemplate 使用。

6. 總結

本文從快取系統的選擇出發，基於 Redis 介紹了幾種叢集方案並重點說明了 Redis Cluster 方案。之後列出快取系統常見問題及常見解決方案，最後對使用做了簡單說明。

當然，如何去落地，如何解決這些問題還需要根據實際場景具體分析和處理。

參考資料

• Redis Cluster Specification：https://redis.io/topics/cluster-spec
• 深入理解分散式系統中的快取架構：https://juejin.im/entry/5b514768f265da0fa21a800f
• 快取更新的套路：https://coolshell.cn/articles/17416.html
• 一種高效的Redis Cluster的分散式快取系統[J].計算機系統應用,2018,27(10):91-98 ：https://kns.cnki.net/KCMS/detail/detail.aspx?dbcode=CJFQ&dbname=CJFDLAST2018&filename=XTYY201810014

原文連結：https://mp.weixin.qq.com/s/cONKlGQze1WzyC2yzbZ0RA
歡迎關注公眾號 【碼農開花】一起學習成長
我會一直分享Java乾貨，也會分享免費的學習資料課程和麵試寶典
回覆：【計算機】【設計模式】【面試】有驚喜哦