在做分布式快取的時候如何選擇，如何解決遇到的坑？

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

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干貨，也會分享免費的學習資料課程和面試寶典
回復：【計算機】【設計模式】【面試】有驚喜哦

標籤：其他

上一篇：nginx反向代理docker容器化django

下一篇：面試 | 分布式問題在怎么問，都跑不了這些內容