深入剖析Redis系列： Redis集群模式搭建與原理詳解

前言

在 Redis 3.0 之前，使用 哨兵（sentinel）機制來監控各個節點之間的狀態。Redis Cluster 是 Redis 的 分布式解決方案，在 3.0 版本正式推出，有效地解決了 Redis 在 分布式 方面的需求。當遇到 單機內存、並發、流量 等瓶頸時，可以采用 Cluster 架構方案達到 負載均衡 的目的。

本文將從 集群方案、數據分布、搭建集群、節點通信、集群伸縮、請求路由、故障轉移、集群運維 等幾個方面介紹 Redis Cluster。

正文

1. Redis集群方案

Redis Cluster 集群模式通常具有 高可用、可擴展性、分布式、容錯 等特性。Redis 分布式方案一般有兩種：

1.1 客戶端分區方案

客戶端 就已經決定數據會被 存儲 到哪個 redis 節點或者從哪個 redis 節點 讀取數據。其主要思想是采用 哈希算法 將 Redis 數據的 key 進行散列，通過 hash 函數，特定的 key會 映射到特定的 Redis 節點上。

客戶端分區方案 的代表為 Redis Sharding，Redis Sharding 是 Redis Cluster 出來之前，業界普遍使用的 Redis 多實例集群 方法。Java 的 Redis 客戶端驅動庫 Jedis，支持 Redis Sharding 功能，即 ShardedJedis 以及 結合緩存池 的 ShardedJedisPool。

• 優點

不使用 第三方中間件，分區邏輯 可控，配置 簡單，節點之間無關聯，容易 線性擴展，靈活性強。

• 缺點

客戶端 無法 動態增刪 服務節點，客戶端需要自行維護 分發邏輯，客戶端之間 無連接共享，會造成 連接浪費。

1.2. 代理分區方案

客戶端 發送請求到一個 代理組件，代理 解析 客戶端 的數據，並將請求轉發至正確的節點，最后將結果回復給客戶端。

• 優點：簡化 客戶端 的分布式邏輯，客戶端 透明接入，切換成本低，代理的 轉發 和 存儲 分離。
• 缺點：多了一層 代理層，加重了 架構部署復雜度 和 性能損耗。

代理分區 主流實現的有方案有 Twemproxy 和 Codis。

1.2.1. Twemproxy

Twemproxy 也叫 nutcraker，是 twitter 開源的一個 redis 和 memcache 的 中間代理服務器 程序。Twemproxy 作為 代理，可接受來自多個程序的訪問，按照 路由規則，轉發給后台的各個 Redis 服務器，再原路返回。Twemproxy 存在 單點故障 問題，需要結合 Lvs 和 Keepalived 做 高可用方案。

• 優點：應用范圍廣，穩定性較高，中間代理層 高可用。
• 缺點：無法平滑地 水平擴容/縮容，無 可視化管理界面，運維不友好，出現故障，不能 自動轉移。

1.2.2. Codis

Codis 是一個 分布式 Redis 解決方案，對於上層應用來說，連接 Codis-Proxy 和直接連接 原生的 Redis-Server 沒有的區別。Codis 底層會 處理請求的轉發，不停機的進行 數據遷移 等工作。Codis 采用了無狀態的 代理層，對於 客戶端 來說，一切都是透明的。

• 優點

實現了上層 Proxy 和底層 Redis 的 高可用，數據分片 和 自動平衡，提供 命令行接口 和 RESTful API，提供 監控 和 管理 界面，可以動態 添加 和 刪除 Redis 節點。

• 缺點

部署架構 和 配置 復雜，不支持 跨機房 和 多租戶，不支持 鑒權管理。

1.3. 查詢路由方案

客戶端隨機地 請求任意一個 Redis 實例，然后由 Redis 將請求 轉發 給 正確 的 Redis 節點。Redis Cluster 實現了一種 混合形式 的 查詢路由，但並不是 直接 將請求從一個 Redis 節點 轉發 到另一個 Redis 節點，而是在 客戶端 的幫助下直接 重定向（ redirected）到正確的 Redis 節點。

• 優點

無中心節點，數據按照 槽 存儲分布在多個 Redis 實例上，可以平滑的進行節點 擴容/縮容，支持 高可用 和 自動故障轉移，運維成本低。

• 缺點

嚴重依賴 Redis-trib 工具，缺乏 監控管理，需要依賴 Smart Client (維護連接，緩存路由表，MultiOp 和 Pipeline 支持)。Failover 節點的 檢測過慢，不如 中心節點 ZooKeeper 及時。Gossip 消息具有一定開銷。無法根據統計區分 冷熱數據。

2. 數據分布

2.1. 數據分布理論

分布式數據庫 首先要解決把 整個數據集 按照 分區規則 映射到 多個節點 的問題，即把 數據集 划分到 多個節點 上，每個節點負責 整體數據 的一個 子集。

數據分布通常有 哈希分區 和 順序分區 兩種方式，對比如下：

由於 Redis Cluster 采用 哈希分區規則，這里重點討論 哈希分區。常見的 哈希分區 規則有幾種，下面分別介紹：

2.1.1. 節點取余分區

使用特定的數據，如 Redis 的 鍵 或 用戶 ID，再根據 節點數量 N 使用公式：hash（key）% N 計算出 哈希值，用來決定數據 映射 到哪一個節點上。

image

• 優點

這種方式的突出優點是 簡單性，常用於 數據庫 的 分庫分表規則。一般采用 預分區 的方式，提前根據 數據量 規划好 分區數，比如划分為 512 或 1024 張表，保證可支撐未來一段時間的 數據容量，再根據 負載情況 將 表 遷移到其他 數據庫 中。擴容時通常采用 翻倍擴容，避免 數據映射 全部被 打亂，導致 全量遷移 的情況。

• 缺點

當 節點數量 變化時，如 擴容 或 收縮 節點，數據節點 映射關系 需要重新計算，會導致數據的 重新遷移。

2.1.2. 一致性哈希分區

一致性哈希 可以很好的解決 穩定性問題，可以將所有的 存儲節點 排列在 收尾相接 的 Hash 環上，每個 key 在計算 Hash 后會 順時針 找到 臨接 的 存儲節點 存放。而當有節點 加入 或 退出 時，僅影響該節點在 Hash 環上 順時針相鄰 的 后續節點。

image

• 優點

加入 和 刪除 節點只影響 哈希環 中 順時針方向 的 相鄰的節點，對其他節點無影響。

• 缺點

加減節點 會造成 哈希環 中部分數據 無法命中。當使用 少量節點 時，節點變化 將大范圍影響 哈希環 中 數據映射，不適合 少量數據節點 的分布式方案。普通 的 一致性哈希分區 在增減節點時需要 增加一倍 或 減去一半 節點才能保證 數據 和 負載的均衡。

注意：因為 一致性哈希分區 的這些缺點，一些分布式系統采用 虛擬槽 對 一致性哈希 進行改進，比如 Dynamo 系統。

2.1.3. 虛擬槽分區

虛擬槽分區 巧妙地使用了 哈希空間，使用 分散度良好 的 哈希函數 把所有數據 映射 到一個 固定范圍 的 整數集合 中，整數定義為 槽（slot）。這個范圍一般 遠遠大於 節點數，比如 Redis Cluster 槽范圍是 0 ~ 16383。槽 是集群內 數據管理 和 遷移 的 基本單位。采用 大范圍槽 的主要目的是為了方便 數據拆分 和 集群擴展。每個節點會負責 一定數量的槽，如圖所示：

當前集群有 5 個節點，每個節點平均大約負責 3276 個 槽。由於采用 高質量 的 哈希算法，每個槽所映射的數據通常比較 均勻，將數據平均划分到 5 個節點進行 數據分區。Redis Cluster 就是采用 虛擬槽分區。

• 節點1： 包含 0 到 3276 號哈希槽。
• 節點2：包含 3277 到 6553 號哈希槽。
• 節點3：包含 6554 到 9830 號哈希槽。
• 節點4：包含 9831 到 13107 號哈希槽。
• 節點5：包含 13108 到 16383 號哈希槽。

這種結構很容易 添加 或者 刪除 節點。如果 增加 一個節點 6，就需要從節點 1 ~ 5 獲得部分 槽 分配到節點 6 上。如果想 移除 節點 1，需要將節點 1 中的 槽 移到節點 2 ~ 5 上，然后將 沒有任何槽 的節點 1 從集群中 移除 即可。

由於從一個節點將 哈希槽 移動到另一個節點並不會 停止服務，所以無論 添加刪除 或者 改變 某個節點的 哈希槽的數量 都不會造成 集群不可用 的狀態.

2.2. Redis的數據分區

Redis Cluster 采用 虛擬槽分區，所有的 鍵 根據 哈希函數 映射到 0~16383 整數槽內，計算公式：slot = CRC16（key）& 16383。每個節點負責維護一部分槽以及槽所映射的 鍵值數據，如圖所示：

2.2.1. Redis虛擬槽分區的特點

• 解耦 數據 和 節點 之間的關系，簡化了節點 擴容 和 收縮 難度。
• 節點自身 維護槽的 映射關系，不需要 客戶端 或者 代理服務 維護 槽分區元數據。
• 支持 節點、槽、鍵 之間的 映射查詢，用於 數據路由、在線伸縮 等場景。

2.3. Redis集群的功能限制

Redis 集群相對 單機 在功能上存在一些限制，需要 開發人員 提前了解，在使用時做好規避。

• key 批量操作 支持有限。

類似 mset、mget 操作，目前只支持對具有相同 slot 值的 key 執行 批量操作。對於 映射為不同 slot 值的 key 由於執行 mget、mget 等操作可能存在於多個節點上，因此不被支持。

• key 事務操作 支持有限。

只支持 多 key 在 同一節點上 的 事務操作，當多個 key 分布在 不同 的節點上時 無法 使用事務功能。

• key 作為 數據分區 的最小粒度

不能將一個 大的鍵值 對象如 hash、list 等映射到 不同的節點。

• 不支持 多數據庫空間

單機 下的 Redis 可以支持 16 個數據庫（db0 ~ db15），集群模式 下只能使用 一個 數據庫空間，即 db0。

• 復制結構 只支持一層

從節點 只能復制 主節點，不支持 嵌套樹狀復制 結構。

3. Redis集群搭建

Redis-Cluster 是 Redis 官方的一個 高可用 解決方案，Cluster 中的 Redis 共有 2^14（16384） 個 slot 槽。創建 Cluster 后，槽 會 平均分配 到每個 Redis 節點上。

下面介紹一下本機啟動 6 個 Redis 的 集群服務，並使用 redis-trib.rb 創建 3主3從 的 集群。搭建集群工作需要以下三個步驟：

3.1. 准備節點

Redis 集群一般由 多個節點 組成，節點數量至少為 6 個，才能保證組成 完整高可用 的集群。每個節點需要 開啟配置 cluster-enabled yes，讓 Redis 運行在 集群模式 下。

Redis 集群的節點規划如下：

注意：建議為集群內 所有節點 統一目錄，一般划分三個目錄：conf、data、log，分別存放 配置、數據 和 日志 相關文件。把 6 個節點配置統一放在 conf 目錄下。

3.1.1. 創建redis各實例目錄

$ sudo mkdir -p /usr/local/redis-cluster

$ cd /usr/local/redis-cluster

$ sudo mkdir conf data log

$ sudo mkdir -p data/redis-6379 data/redis-6389 data/redis-6380 data/redis-6390 data/redis-6381 data/redis-6391

3.1.2. redis配置文件管理

根據以下 模板 配置各個實例的 redis.conf，以下只是搭建集群需要的 基本配置，可能需要根據實際情況做修改。

# redis后台運行

daemonize yes

# 綁定的主機端口

bind 127.0.0.1

# 數據存放目錄

dir /usr/local/redis-cluster/data/redis-6379

# 進程文件

pidfile /var/run/redis-cluster/${自定義}.pid

# 日志文件

logfile /usr/local/redis-cluster/log/${自定義}.log

# 端口號

port 6379

# 開啟集群模式，把注釋#去掉

cluster-enabled yes

# 集群的配置，配置文件首次啟動自動生成

cluster-config-file /usr/local/redis-cluster/conf/${自定義}.conf

# 請求超時，設置10秒

cluster-node-timeout 10000

# aof日志開啟，有需要就開啟，它會每次寫操作都記錄一條日志

appendonly yes

• redis-6379.conf

daemonize yes

bind 127.0.0.1

dir /usr/local/redis-cluster/data/redis-6379

pidfile /var/run/redis-cluster/redis-6379.pid

logfile /usr/local/redis-cluster/log/redis-6379.log

port 6379

cluster-enabled yes

cluster-config-file /usr/local/redis-cluster/conf/node-6379.conf

cluster-node-timeout 10000

appendonly yes

• redis-6389.conf

daemonize yes

bind 127.0.0.1

dir /usr/local/redis-cluster/data/redis-6389

pidfile /var/run/redis-cluster/redis-6389.pid

logfile /usr/local/redis-cluster/log/redis-6389.log

port 6389

cluster-enabled yes

cluster-config-file /usr/local/redis-cluster/conf/node-6389.conf

cluster-node-timeout 10000

appendonly yes

• redis-6380.conf

daemonize yes

bind 127.0.0.1

dir /usr/local/redis-cluster/data/redis-6380

pidfile /var/run/redis-cluster/redis-6380.pid

logfile /usr/local/redis-cluster/log/redis-6380.log

port 6380

cluster-enabled yes

cluster-config-file /usr/local/redis-cluster/conf/node-6380.conf

cluster-node-timeout 10000

appendonly yes

• redis-6390.conf

daemonize yes

bind 127.0.0.1

dir /usr/local/redis-cluster/data/redis-6390

pidfile /var/run/redis-cluster/redis-6390.pid

logfile /usr/local/redis-cluster/log/redis-6390.log

port 6390

cluster-enabled yes

cluster-config-file /usr/local/redis-cluster/conf/node-6390.conf

cluster-node-timeout 10000

appendonly yes

• redis-6381.conf

daemonize yes

bind 127.0.0.1

dir /usr/local/redis-cluster/data/redis-6381

pidfile /var/run/redis-cluster/redis-6381.pid

logfile /usr/local/redis-cluster/log/redis-6381.log

port 6381

cluster-enabled yes

cluster-config-file /usr/local/redis-cluster/conf/node-6381.conf

cluster-node-timeout 10000

appendonly yes

• redis-6391.conf

daemonize yes

bind 127.0.0.1

dir /usr/local/redis-cluster/data/redis-6391

pidfile /var/run/redis-cluster/redis-6391.pid

logfile /usr/local/redis-cluster/log/redis-6391.log

port 6391

cluster-enabled yes

cluster-config-file /usr/local/redis-cluster/conf/node-6391.conf

cluster-node-timeout 10000

appendonly yes

3.2. 環境准備

3.2.1. 安裝Ruby環境

$ sudo brew install ruby

3.2.2. 准備rubygem redis依賴

$ sudo gem install redis

Password:

Fetching: redis-4.0.2.gem (100%)

Successfully installed redis-4.0.2

Parsing documentation for redis-4.0.2

Installing ri documentation for redis-4.0.2

Done installing documentation for redis after 1 seconds

1 gem installed

3.2.3. 拷貝redis-trib.rb到集群根目錄

redis-trib.rb 是 redis 官方推出的管理 redis 集群 的工具，集成在 redis 的源碼 src 目錄下，將基於 redis 提供的 集群命令 封裝成 簡單、便捷、實用 的 操作工具。

$ sudo cp /usr/local/redis-4.0.11/src/redis-trib.rb /usr/local/redis-cluster

查看 redis-trib.rb 命令環境是否正確，輸出如下：

$ ./redis-trib.rb

Usage: redis-trib <command> <options> <arguments ...>

create host1:port1 ... hostN:portN

--replicas <arg>

check host:port

info host:port

fix host:port

--timeout <arg>

reshard host:port

--from <arg>

--to <arg>

--slots <arg>

--yes

--timeout <arg>

--pipeline <arg>

rebalance host:port

--weight <arg>

--auto-weights

--use-empty-masters

--timeout <arg>

--simulate

--pipeline <arg>

--threshold <arg>

add-node new_host:new_port existing_host:existing_port

--slave

--master-id <arg>

del-node host:port node_id

set-timeout host:port milliseconds

call host:port command arg arg .. arg

import host:port

--from <arg>

--copy

--replace

help (show this help)

For check, fix, reshard, del-node, set-timeout you can specify the host and port of any working node in the cluster.

redis-trib.rb 是 redis 作者用 ruby 完成的。redis-trib.rb 命令行工具 的具體功能如下：

3.3. 安裝集群

3.3.1. 啟動redis服務節點

運行如下命令啟動 6 台 redis 節點：

sudo redis-server conf/redis-6379.conf

sudo redis-server conf/redis-6389.conf

sudo redis-server conf/redis-6380.conf

sudo redis-server conf/redis-6390.conf

sudo redis-server conf/redis-6381.conf

sudo redis-server conf/redis-6391.conf

啟動完成后，redis 以集群模式啟動，查看各個 redis 節點的進程狀態：

$ ps -ef | grep redis-server

0 1908 1 0 4:59下午 ?? 0:00.01 redis-server *:6379 [cluster]

0 1911 1 0 4:59下午 ?? 0:00.01 redis-server *:6389 [cluster]

0 1914 1 0 4:59下午 ?? 0:00.01 redis-server *:6380 [cluster]

0 1917 1 0 4:59下午 ?? 0:00.01 redis-server *:6390 [cluster]

0 1920 1 0 4:59下午 ?? 0:00.01 redis-server *:6381 [cluster]

0 1923 1 0 4:59下午 ?? 0:00.01 redis-server *:6391 [cluster]

在每個 redis 節點的 redis.conf 文件中，我們都配置了 cluster-config-file 的文件路徑，集群啟動時，conf 目錄會新生成 集群 節點配置文件。查看文件列表如下：

$ tree -L 3 .

.

├── appendonly.aof

├── conf

│ ├── node-6379.conf

│ ├── node-6380.conf

│ ├── node-6381.conf

│ ├── node-6389.conf

│ ├── node-6390.conf

│ ├── node-6391.conf

│ ├── redis-6379.conf

│ ├── redis-6380.conf

│ ├── redis-6381.conf

│ ├── redis-6389.conf

│ ├── redis-6390.conf

│ └── redis-6391.conf

├── data

│ ├── redis-6379

│ ├── redis-6380

│ ├── redis-6381

│ ├── redis-6389

│ ├── redis-6390

│ └── redis-6391

├── log

│ ├── redis-6379.log

│ ├── redis-6380.log

│ ├── redis-6381.log

│ ├── redis-6389.log

│ ├── redis-6390.log

│ └── redis-6391.log

└── redis-trib.rb

9 directories, 20 files

3.3.2. redis-trib關聯集群節點

按照 從主到從 的方式 從左到右 依次排列 6 個 redis 節點。

$ sudo ./redis-trib.rb create --replicas 1 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6389 127.0.0.1:6390 127.0.0.1:6391

集群創建后，redis-trib 會先將 16384 個 哈希槽 分配到 3 個 主節點，即 redis-6379，redis-6380 和 redis-6381。然后將各個 從節點 指向 主節點，進行 數據同步。

>>> Creating cluster

>>> Performing hash slots allocation on 6 nodes...

Using 3 masters:

127.0.0.1:6379

127.0.0.1:6380

127.0.0.1:6381

Adding replica 127.0.0.1:6390 to 127.0.0.1:6379

Adding replica 127.0.0.1:6391 to 127.0.0.1:6380

Adding replica 127.0.0.1:6389 to 127.0.0.1:6381

>>> Trying to optimize slaves allocation for anti-affinity

[WARNING] Some slaves are in the same host as their master

M: ad4b9ffceba062492ed67ab336657426f55874b7 127.0.0.1:6379

slots:0-5460 (5461 slots) master

M: df23c6cad0654ba83f0422e352a81ecee822702e 127.0.0.1:6380

slots:5461-10922 (5462 slots) master

M: ab9da92d37125f24fe60f1f33688b4f8644612ee 127.0.0.1:6381

slots:10923-16383 (5461 slots) master

S: 25cfa11a2b4666021da5380ff332b80dbda97208 127.0.0.1:6389

replicates ad4b9ffceba062492ed67ab336657426f55874b7

S: 48e0a4b539867e01c66172415d94d748933be173 127.0.0.1:6390

replicates df23c6cad0654ba83f0422e352a81ecee822702e

S: d881142a8307f89ba51835734b27cb309a0fe855 127.0.0.1:6391

replicates ab9da92d37125f24fe60f1f33688b4f8644612ee

然后輸入 yes，redis-trib.rb 開始執行 節點握手 和 槽分配 操作，輸出如下：

Can I set the above configuration? (type 'yes' to accept): yes

>>> Nodes configuration updated

>>> Assign a different config epoch to each node

>>> Sending CLUSTER MEET messages to join the cluster

Waiting for the cluster to join....

>>> Performing Cluster Check (using node 127.0.0.1:6379)

M: ad4b9ffceba062492ed67ab336657426f55874b7 127.0.0.1:6379

slots:0-5460 (5461 slots) master

1 additional replica(s)

M: ab9da92d37125f24fe60f1f33688b4f8644612ee 127.0.0.1:6381

slots:10923-16383 (5461 slots) master

1 additional replica(s)

S: 48e0a4b539867e01c66172415d94d748933be173 127.0.0.1:6390

slots: (0 slots) slave

replicates df23c6cad0654ba83f0422e352a81ecee822702e

S: d881142a8307f89ba51835734b27cb309a0fe855 127.0.0.1:6391

slots: (0 slots) slave

replicates ab9da92d37125f24fe60f1f33688b4f8644612ee

M: df23c6cad0654ba83f0422e352a81ecee822702e 127.0.0.1:6380

slots:5461-10922 (5462 slots) master

1 additional replica(s)

S: 25cfa11a2b4666021da5380ff332b80dbda97208 127.0.0.1:6389

slots: (0 slots) slave

replicates ad4b9ffceba062492ed67ab336657426f55874b7

[OK] All nodes agree about slots configuration.

>>> Check for open slots...

>>> Check slots coverage...

[OK] All 16384 slots covered.

執行 集群檢查，檢查各個 redis 節點占用的 哈希槽（slot）的個數以及 slot 覆蓋率。16384 個槽位中，主節點 redis-6379、redis-6380 和 redis-6381 分別占用了 5461、5461 和 5462 個槽位。

3.3.3. redis主節點的日志

可以發現，通過 BGSAVE 命令，從節點 redis-6389 在 后台 異步地從 主節點 redis-6379 同步數據。

$ cat log/redis-6379.log

1907:C 05 Sep 16:59:52.960 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo

1907:C 05 Sep 16:59:52.961 # Redis version=4.0.11, bits=64, commit=00000000, modified=0, pid=1907, just started

1907:C 05 Sep 16:59:52.961 # Configuration loaded

1908:M 05 Sep 16:59:52.964 * Increased maximum number of open files to 10032 (it was originally set to 256).

1908:M 05 Sep 16:59:52.965 * No cluster configuration found, I'm ad4b9ffceba062492ed67ab336657426f55874b7

1908:M 05 Sep 16:59:52.967 * Running mode=cluster, port=6379.

1908:M 05 Sep 16:59:52.967 # Server initialized

1908:M 05 Sep 16:59:52.967 * Ready to accept connections

1908:M 05 Sep 17:01:17.782 # configEpoch set to 1 via CLUSTER SET-CONFIG-EPOCH

1908:M 05 Sep 17:01:17.812 # IP address for this node updated to 127.0.0.1

1908:M 05 Sep 17:01:22.740 # Cluster state changed: ok

1908:M 05 Sep 17:01:23.681 * Slave 127.0.0.1:6389 asks for synchronization

1908:M 05 Sep 17:01:23.681 * Partial resynchronization not accepted: Replication ID mismatch (Slave asked for '4c5afe96cac51cde56039f96383ea7217ef2af41', my replication IDs are '037b661bf48c80c577d1fa937ba55367a3692921' and '0000000000000000000000000000000000000000')

1908:M 05 Sep 17:01:23.681 * Starting BGSAVE for SYNC with target: disk

1908:M 05 Sep 17:01:23.682 * Background saving started by pid 1952

1952:C 05 Sep 17:01:23.683 * DB saved on disk

1908:M 05 Sep 17:01:23.749 * Background saving terminated with success

1908:M 05 Sep 17:01:23.752 * Synchronization with slave 127.0.0.1:6389 succeeded

3.3.4. redis集群完整性檢測

使用 redis-trib.rb check 命令檢測之前創建的 兩個集群 是否成功，check 命令只需要給出集群中 任意一個節點地址 就可以完成 整個集群 的 檢查工作，命令如下：

$ ./redis-trib.rb check 127.0.0.1:6379

當最后輸出如下信息，提示集群 所有的槽 都已分配到節點：

[OK] All nodes agree about slots configuration.

>>> Check for open slots...

>>> Check slots coverage...

[OK] All 16384 slots covered.

小結

本文介紹了 Redis 集群解決方案，數據分布 和 集群搭建。集群方案包括 客戶端分區 方案，代理分區 方案 和 查詢路由 方案。數據分布 部分簡單地對 節點取余 分區，一致性哈希 分區以及 虛擬槽 分區進行了闡述和對比。最后對使用 Redis-trib 搭建了一個 三主三從 的 虛擬槽集群示例。