系統環境： Redis 版本：6.0.8 Docker 版本：19.03.12 系統版本：CoreOS 7.8 內核版本：5.8.5-1.el7.elrepo.x86_64一、什么是 Redis 集群模式

在 Redis 3.0 版本后正式推出 Redis 集群模式，該模式是 Redis 的分布式的解決方案，是一個提供在多個 Redis 節點間共享數據的程序集，且 Redis 集群是去中心化的，它的每個 Master 節點都可以進行讀寫數據，每個節點都擁有平等的關系，每個節點都保持各自的數據和整個集群的狀態。

Redis 集群設計的主要目的是讓 Redis 數據存儲能夠線性擴展，通過分區來提供一定程度的可用性，在實際環境中當某個節點宕機或者不可達的情況下其可以繼續處理命令。但是，如果發生較大故障（例如，大多數主站不可用時）時集群會停止運行，即 redis 集群不能保證數據的強一致性。

二、為什么需要 Redis 集群 高可用性： Redis 在集群模式下每個 Master 都是主從復制模式，其 Master 節點上的數據會實時同步到 Slave 節點上，當 Master 節點不可用時，其對應的 Slave 節點身份會更改為 Master 節點，保證集群的可用性。 數據橫向擴展： Redis 是一個內存數據庫，所有數據都存在內存中，在單節點中所在服務器能給與的內存是有一定限制。當數據量達到一定程度后，內存將不足以支撐這么多的數據存儲，這時候需要將數據進行分片存儲，而 Redis 集群模式就是將數據分片存儲，非常方便橫向擴展。三、Redis 集群的數據分片

Redis 集群沒有使用一致性 Hash, 而是引入了”哈希槽”的概念。Redis 集群有 16384 個哈希槽，每個 key 通過 CRC16 校驗后對 16384 取模來決定放置哪個槽，集群的每個節點負責一部分 hash 槽。

舉個例子，比如當前集群有3個節點，那么:

節點 A 包含 0 到 5460 號哈希槽； 節點 B 包含 5461 到 10922 號哈希槽； 節點 C 包含 10923 到 16383 號哈希槽；

這種結構很容易”添加”或者”刪除”節點. 比如如果我想新添加個節點 D，我需要從節點 A, B, C 中得部分槽轉移到節點 D 上， 如果我想移除節點 A，則需要將 A 中的槽移到 B 和 C 節點上，然后將沒有任何槽的 A 節點從集群中移除即可。由于從一個節點將哈希槽移動到另一個節點并不會停止服務，所以無論添加刪除或者改變某個節點的哈希槽的數量都不會造成集群不可用的狀態。

Redis 支持多個 key 操作，只要這些 key 在一個單個命令中執行（或者一個事務，或者 Lua 腳本執行），那么它們就屬于相同的 Hash 槽。你也可以用 hash tags 命令強制多個 key 都在相同的 hash 槽中。

四、Redis 集群的主從復制

集群中的主從模型

在 Redis 集群模式下，為了防止集群部分節點因宕機等情況造成不可用，故而 Redis 集群使用了主從復制模式。在該模式下要求 Redis 集群至少要存在六個節點，其中三個節點為主節點，能夠對外提供讀寫。還有三個節點為從節點，會同步其對應的主節點的數據。當某個主節點出現問題不可用時，Redis 將通過選舉算法從主節點對應的從節點中選擇一個節點（主節點存在多個從節點的情況下），將其更改為一個新的主節點，且能夠對外提供服務。

例如，在存在 A，B，C 三個主節點和其對應的 （A1、A2），（B1、B2），（C1、C2） 六個從節點，共九個節點中，如果節點 A 節點掛掉，那么其對應的從節點 A1、A2 節點將通過選舉算法，選擇其中一個節點提升為主節點，以確保集群能夠正常服務。不過當 A1、A2 兩個從節點或者或者半數以上主節點不可用時，那么集群也是不可用的。

在部署 Redis 集群模式時，至少需要六個節點組成集群才能保證集群的可用性。

主從復制的相關概念

(1)、全量復制與增量復制

在 Redis 主從復制中，分為”全量復制”和”增量復制”兩種數據同步方式：

全量復制： 用于初次復制或其它無法進行部分復制的情況，將主節點中的所有數據都發送給從節點。當數據量過大的時候，會造成很大的網絡開銷。 增量復制： 用于處理在主從復制中因網絡閃退等原因造成數據丟失場景，當從節點再次連上主節點，如果條件允許，主節點會補發丟失數據給從節點，因為補發的數據遠遠小于全量數據，可以有效避免全量復制的過高開銷。但需要注意，如果網絡中斷時間過長，造成主節點沒有能夠完整地保存中斷期間執行的寫命令，則無法進行部分復制，仍使用全量復制。

(2)、記錄復制位置的偏移量

參與復制的主從節點都會維護自身復制偏移量，主節點在處理完寫入命令操作后，會把命令的字節長度做累加記錄，可以使用 info replication 命令查詢 master_repl_offset 偏移量信息。 從節點每秒鐘上報自身的復制偏移量給主節點，因此主節點也會保存從節點的復制偏移量。 從節點在接收到主節點發送的命令后，也會累加記錄自身的偏移量，可以使用 info replication 命令查詢 slave_repl_offset 偏移量信息。

(3)、復制積壓緩沖區

復制積壓緩沖區（backlog）是保存在主節點上的一個固定長度的隊列，默認大小為 1MB，當主節點有連接的從節點時被創建，這時主節點響應寫命令時，不但會把命令發給從節點，還會寫入復制積壓緩沖區，作為寫命令的備份。

除了存儲寫命令，復制積壓緩沖區中還存儲了其中的每個字節對應的復制偏移量（offset） 。由于復制積壓緩沖區定長且先進先出，所以它保存的是主節點最近執行的寫命令，時間較早的寫命令會被擠出緩沖區。

(4)、節點運行的 ID

每個 Redis 節點啟動后都會動態分配一個 40 位的十六進制字符串為運行 ID。運行 ID 的主要作用是來唯一識別 Redis 節點，比如，從節點保存主節點的運行 ID 識別自已正在復制是哪個主節點。如果只使用 IP + Port 的方式識別主節點，那么主節點重啟變更了整體數據集（如替換 RDB/AOF 文件），從節點再基于偏移量復制數據將是不安全的，因此當運行 ID 變化后從節點將做全量復制。可以在 info server 命令查看當前節點的運行 ID。 需要注意的是 Redis 關閉再啟動，運行的 ID 會隨之變化。主從復制的執行過程

(1)、psync 命令

從節點使用 psync 從主節點獲取 runid 與 offset。

主節點會根據自身情況返回響應信息，可能是 FULLRESYNC runid offset 觸發全量復制，可能是 CONTINUE 觸發增量復制。

(2)、psync 觸發全量復制

從節點使用 psync 命令完成部分復制和全量復制功能：

當從節點第一次連接主節點時候，執行全量復制：

① Slave 節點發送 psync? - 1 命令，表示要求 Master 執行數據同步；

② Master 檢測到沒有 offset ，是第一次執行復制，執行全量復制，就發送 FULLRESYNC {runid} {offset} 命令，將 runid 和 offset 發送到 slave 節點。

③ Slave 節點保存 Master 節點傳遞的 runid 與 offset 信息。

④ Master 節點執行 bgsave 生成 RBD 快照文件，并使用緩沖區記錄從現在開始執行的全部命令。

⑤ Master 節點發送 RBD 文件到 Slave 節點。

⑥ Master 節點發送 BUFFER 緩存區記錄的寫命令到 Slave 節點。

⑦ Slave 節點清空舊數據。

⑧ Slave 節點載入 Master 節點傳入的 RBD 文件。

(2)、psync 觸發增量復制

當從節點與主節點發送中斷后，從節點會重新連接主節點，這時會觸發增量復制，過程如下：

① Slave 節點使用 psync 發送 runid 和 offset 值。

② Master 節點驗證 Slave 節點發送的 runid 是否和自己相同：

不相同： 不相同則執行全量復制； 相同： 則還需要驗證緩存區中是否存在對應的 offset，如果不存在就執行全量復制，否則執行增量復制；

③ 滿足存在對應 offset 這個條件后，則驗證緩存區中的 offset 值是否和 Slave 節點發送的 offset 相同：

相同： 返回 offset 值相同，不進行復制操作； 不相同： 發送 CONTINUE offset 命令（注意：這里的 offset 是 Master 節點緩存區記錄的 offset 值，不是 Slave 節點傳遞的 offset 值）；

④ Master 節點從復制緩存區拷貝數據，從 Slave 節點發送的 offset 開始，到 Master 節點緩存區記錄的 offset 結束，將這個范圍內的數據給 Slave 節點。

五、Redis 集群相關概念Redis 集群中的一致性

Redis 在官方文檔中提及，其并不能保證數據的強一致性，即 Redis 集群在特定的條件下寫入的數據可能會丟失，主要原因是因為 Redis 集群使用了異步復制模式，其寫入的操作過程如下：

執行順序如下：

① 客戶端向任意一臺主節點寫入一條命令；

② 主節點對向客戶端回復命令執行的狀態；

③ 主節點將寫操作命令傳遞給他的從節點；

Redis 集群對性能和一致性之間做出權衡，設置主節點在接收到客戶端寫命令后再將執行的命令發送到各個從節點進行同步，這個過程是異步操作，且主節點不會等待從節點回復信息就立即回復客戶端命令的執行狀態。這樣減少同步操作，可以很大提高系統的執行速度，避免等待從節點回復消息這個過程成為系統性能的瓶頸。

然而，因為主節點不等待從節點收到信息后進行回復，就將命令的執行狀態回復給了客戶端，那么在節點出現問題時很可能導致出現數據丟失問題，比如客戶端向主節點發送一條命令，然后主節點將該命令異步發送到它的從節點進行數據備份，然后立即回復客戶端命令的執行狀態。如果在這個過程中，主節點出現問導致宕機，且從節點在處理主節點發送過來的同步數據時，也發生錯誤。這時正好趕上主節點宕機等不可用情況，那么從節點將轉換為新的主節點，在之前主節點執行的命令將丟失。

Redis 集群間通信機制

在 Redis 集群中，數據節點提供兩個 TCP 端口，在配置防火墻時需要同時開啟下面兩類端口：

普通端口： 即客戶端訪問端口，如默認的 6379； 集群端口： 普通端口號加 10000，如 6379 的集群端口為 16379，用于集群節點之間的通訊；

集群的節點之間通訊采用 Gossip 協議，節點根據固定頻率(每秒10次)定時任務進行判斷，當集群狀態發生變化，如增刪節點、槽狀態變更時，會通過節點間通訊同步集群狀態，使集群收斂。集群間發送的 Gossip 消息有下面五種消息類型：

MEET： 在節點握手階段，對新加入的節點發送 meet 消息，請求新節點加入當前集群，新節點收到消息會回復 pong 消息； PING： 節點之間互相發送 ping 消息，收到消息的會回復 pong 消息。ping 消息內容包含本節點和其他節點的狀態信息，以此達到狀態同步； PONG： pong 消息包含自身的狀態數據，在接收到 ping 或 meet 消息時會回復 pong 消息，也會主動向集群廣播 pong 消息； FAIL： 當一個主節點判斷另一個主節點進入 fail 狀態時，會向集群廣播這個消息，接收到的節點會保存該消息并對該 fail 節點做狀態判斷； PUBLISH： 當節點收到 publish 命令時，會先執行命令，然后向集群廣播 publish 消息，接收到消息的節點也會執行 publish 命令；Redis 集群失敗狀態

在 Redis 集群模式下也不可能百分百保證集群可用性，當發生不可預知的事件導致 Redis 集群將進入失敗狀態，在這種狀態下 Redis 集群將不能正常提供服務。其中進入失敗狀態的條件主要為：

① 全部節點都宕機，集群將進入 fail 狀態；

② 半數以上主節點不可用，集群將進入 fail 狀態；

③ 任意主節點掛掉，且該主節點沒有對應的從節點或者從節點也全部掛掉，集群將進入 fail 狀態；

Redis 集群重新分片機制

Redis 集群重新分片（新增/移除節點）機制：

新增節點：別的節點上的槽分一些出來給新的節點

刪除節點：刪除節點的槽分給別的節點

但這些操作是需要手動完成的，可以在不停止服務器的情況下執行。

Redis 集群的不足

復制結構只支持單層結構，不支持樹型結構。

不支持多數據庫，只能使用 0 數據庫，執行 select 0 命令；

鍵是數據分區的最小粒度，不能將一個很大的鍵值對映射到不同的節點；

鍵事務支持有限，當多個鍵分布在不同節點時無法使用事務，同一節點才能支持事務；

鍵的批量操作支持有限，比如 mset, mget 命令，如果多個鍵映射在不同的槽中，就不能正常使用這些命令了；

Redis 群集配置參數

我們即將創建一個示例集群部署。在繼續之前，讓我們介紹Redis Cluster在redis.conf文件中引入的配置參數。

cluster-config-file： 設置 Redis 集群配置信息及狀態的存儲位置，該文件由 Redis 集群生成，我們只能指定其存儲的位置。

cluster-node-timeout： 設置 Redis 群集節點的通信的超時時間；

cluster-migration-barrier： 主節點需要的最小從節點數，只有達到這個數，主節點失敗時，它從節點才會進行遷移。

cluster-enabled： 是否開啟 Redis 集群模式。

yes：啟用 Redis 群集；

no：不啟用集群模式；

cluster-require-full-coverage： 設置集群可用性。

yes：表示當負責一個插槽的主庫下線，且沒有相應的從庫進行故障恢復時，集群不可用，下面論證該情況。

no：表示當負責一個插槽的主庫下線且沒有相應的從庫進行故障恢復時，集群仍然可用，下面論證該情況。

cluster-slave-validity-factor：

0：則無論從節點與主節點失聯多久，從節點都會嘗試升級成主節點。

正數：則 cluster-node-timeout * cluster-slave-validity-factor 得到的時間，是從節點與主節點失聯后，此從節點數據有效的最長時間，超過這個時間，從節點不會啟動故障遷移。假設 cluster-node-timeout=5，cluster-slave-validity-factor=10，則如果從節點跟主節點失聯超過50秒，此從節點不能成為主節點。

六、Docker 部署 Redis 集群1、Redis 部署機器分配

這里對待部署的 Redis 集群的節點進行分配，將其部署到不同的機器上，安排如下：

2、創建數據存儲目錄

提前創建好用于存儲 Redis 的配置文件和持久化數據的目錄：

第一臺服務器 192.168.2.11 中執行創建存儲目錄命令：

$ mkdir -p /var/lib/redis/7000 & mkdir -p /var/lib/redis/7003

第二臺服務器 192.168.2.12 中執行創建存儲目錄命令：

$ mkdir -p /var/lib/redis/7001 & mkdir -p /var/lib/redis/7004

第三臺服務器 192.168.2.13 中執行創建存儲目錄命令：

$ mkdir -p /var/lib/redis/7002 & mkdir -p /var/lib/redis/70053、創建 Redis 配置文件

第一臺服務器 192.168.2.11 配置文件：

## 7000 端口配置文件$ cat > /var/lib/redis/7000/redis.conf << EOFport 7000cluster-enabled yescluster-config-file nodes.confcluster-node-timeout 5000appendonly yesdaemonize noprotected-mode nopidfile /data/redis.pidEOF ## 7003 端口配置文件$ cat > /var/lib/redis/7003/redis.conf << EOFport 7003cluster-enabled yescluster-config-file nodes.confcluster-node-timeout 5000appendonly yesdaemonize noprotected-mode nopidfile /data/redis.pidEOF

第二臺服務器 192.168.2.12 配置文件

## 7001 端口配置：redis.conf$ cat > /var/lib/redis/7001/redis.conf << EOFport 7001cluster-enabled yescluster-config-file nodes.confcluster-node-timeout 5000appendonly yesdaemonize noprotected-mode nopidfile /data/redis.pidEOF ## 7004 端口配置：redis-7004.conf$ cat > /var/lib/redis/7004/redis.conf << EOFport 7004cluster-enabled yescluster-config-file nodes.confcluster-node-timeout 5000appendonly yesdaemonize noprotected-mode nopidfile /data/redis.pidEOF

第三臺服務器 192.168.2.13 配置文件

## 7002 端口配置：redis-7002.conf$ cat > /var/lib/redis/7002/redis.conf << EOFport 7002cluster-enabled yescluster-config-file nodes.confcluster-node-timeout 5000appendonly yesdaemonize noprotected-mode nopidfile /data/redis.pidEOF ## 7005 端口配置：redis-7005.conf$ cat > /var/lib/redis/7005/redis.conf << EOFport 7005cluster-enabled yescluster-config-file nodes.confcluster-node-timeout 5000appendonly yesdaemonize noprotected-mode nopidfile /data/redis.pidEOF4、提前拉取 Redis 鏡像

三臺服務器中提前拉取 Redis 鏡像，避免在執行運行時候還得拉取鏡像，導致運行慢。

$ docker pull redis:6.0.85、運行啟動 Redis 鏡像

三臺服務器分別執行 Docker 運行命令來啟動 Redis 鏡像。這里需要注意的是，不同服務器間的 Docker 是不能相互通信的，所有這里我們設置啟動的容器網絡模式為 host 模式，這樣容器不會創建虛擬網卡，而是使用宿主機的網絡。

-d：設置容器后臺運行； -v：指定掛載的宿主機存儲目錄； --name：指定運行后的容器名稱； --cpus：指定容器使用 CPU 數量； --memory：限制容器使用內存數量； --memory-swap：指定交換內存大小，這里設置為 0，即不用交換內存； --net：指定 Docker 使用的網絡模式； --restart：指定 Docker 重啟時容器的重啟策略； --privileged：設置容器擁有特權，能夠獲取宿主機 Root 權限；

第一臺服務器 192.168.2.11 執行如下命令

## 運行 Redis 鏡像 7000 端口 $ docker run -d -v /var/lib/redis/7000:/data --cpus=1 --memory=2GB --memory-swap=0 --privileged=true --restart=always --net host --name redis-7000 redis:6.0.8 redis-server /data/redis.conf ## 運行 Redis 鏡像 7003 端口 $ docker run -d -v /var/lib/redis/7003:/data --cpus=1 --memory=2GB --memory-swap=0 --privileged=true --restart=always --net host --name redis-7003 redis:6.0.8 redis-server /data/redis.conf

第二臺服務器 192.168.2.12 執行如下命令

## 運行 Redis 鏡像 7001 端口 $ docker run -d -v /var/lib/redis/7001:/data --cpus=1 --memory=2GB --memory-swap=0 --privileged=true --restart=always --net host --name redis-7001 redis:6.0.8 redis-server /data/redis.conf ## 運行 Redis 鏡像 7004端口 $ docker run -d -v /var/lib/redis/7004:/data --cpus=1 --memory=2GB --memory-swap=0 --privileged=true --restart=always --net host --name redis-7004 redis:6.0.8 redis-server /data/redis.conf

第三臺服務器 192.168.2.13 執行如下命令：

## 運行 Redis 鏡像 7002 端口 $ docker run -d -v /var/lib/redis/7002:/data --cpus=1 --memory=2GB --memory-swap=0 --privileged=true --restart=always --net host --name redis-7002 redis:6.0.8 redis-server /data/redis.conf ## 運行 Redis 鏡像 7005 端口 $ docker run -d -v /var/lib/redis/7005:/data --cpus=1 --memory=2GB --memory-swap=0 --privileged=true --restart=always --net host --name redis-7005 redis:6.0.8 redis-server /data/redis.conf6、創建 Redis 集群

隨意進入一臺服務器，使用 Redis 鏡像的 redis-cli 工具執行創建集群命令使各個 Redis 組成集群，這里本人進入第一臺服務器 192.168.2.11 中，使用端口為 7000 的 Redis 端鏡像，可以執行下面命令：

-p：指定連接 Redis 的端口；

create：創建 Redis 集群；

--cluster：使用 Redis 集群模式命令；

--cluster-replicas：指定副本數（slave 數量）；

$ docker exec -it redis-7000 redis-cli -p 7000 --cluster create 192.168.2.11:7000 192.168.2.12:7001 192.168.2.13:7002 192.168.2.11:7003 192.168.2.12:7004 192.168.2.13:7005 --cluster-replicas 1

然后會看到下面信息：

>>> Performing hash slots allocation on 6 nodes...Master[0] -> Slots 0 - 5460Master[1] -> Slots 5461 - 10922Master[2] -> Slots 10923 - 16383Adding replica 192.168.2.12:7004 to 192.168.2.11:7000Adding replica 192.168.2.13:7005 to 192.168.2.12:7001Adding replica 192.168.2.11:7003 to 192.168.2.13:7002M: 5e50824c55d4df42db4d2987796f0c0b468c273f 192.168.2.11:7000 slots:[0-5460] (5461 slots) masterM: 36565e0273fd62921aa1f2d85c5f7ac98a5b9466 192.168.2.12:7001 slots:[5461-10922] (5462 slots) masterM: 0cc1aaf960defae7332e9256dd25ee5e5c99e65f 192.168.2.13:7002 slots:[10923-16383] (5461 slots) masterS: 42d6e3979395ba93cd1352b6d17044f6b25d9379 192.168.2.11:7003 replicates 0cc1aaf960defae7332e9256dd25ee5e5c99e65fS: ac5d34b57a8f73dabc60d3a56469055ec64fcde7 192.168.2.12:7004 replicates 5e50824c55d4df42db4d2987796f0c0b468c273fS: 470b7ff823f10a309fb07311097456210506f6d8 192.168.2.13:7005 replicates 36565e0273fd62921aa1f2d85c5f7ac98a5b9466Can 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 clusterWaiting for the cluster to join.>>> Performing Cluster Check (using node 192.168.2.11:7000)M: 5e50824c55d4df42db4d2987796f0c0b468c273f 192.168.2.11:7000 slots:[0-5460] (5461 slots) master 1 additional replica(s)S: 470b7ff823f10a309fb07311097456210506f6d8 192.168.2.13:7005 slots: (0 slots) slave replicates 36565e0273fd62921aa1f2d85c5f7ac98a5b9466S: 42d6e3979395ba93cd1352b6d17044f6b25d9379 192.168.2.11:7003 slots: (0 slots) slave replicates 0cc1aaf960defae7332e9256dd25ee5e5c99e65fS: ac5d34b57a8f73dabc60d3a56469055ec64fcde7 192.168.2.12:7004 slots: (0 slots) slave replicates 5e50824c55d4df42db4d2987796f0c0b468c273fM: 0cc1aaf960defae7332e9256dd25ee5e5c99e65f 192.168.2.13:7002 slots:[10923-16383] (5461 slots) master 1 additional replica(s)M: 36565e0273fd62921aa1f2d85c5f7ac98a5b9466 192.168.2.12:7001 slots:[5461-10922] (5462 slots) master 1 additional replica(s)[OK] All nodes agree about slots configuration.>>> Check for open slots...>>> Check slots coverage...[OK] All 16384 slots covered.7、查看集群信息

進入 Redis 鏡像內部并折傭 redis-cli 命令：

-p：指定連接 Redis 的端點；

-c：使用集群模式；

$ docker exec -it redis-7000 redis-cli -p 7000 -c

查看集群信息：

> cluster info cluster_state:okcluster_slots_assigned:16384cluster_slots_ok:16384cluster_slots_pfail:0cluster_slots_fail:0cluster_known_nodes:6cluster_size:3cluster_current_epoch:6cluster_my_epoch:1cluster_stats_messages_ping_sent:866cluster_stats_messages_pong_sent:854cluster_stats_messages_sent:1720cluster_stats_messages_ping_received:849cluster_stats_messages_pong_received:866cluster_stats_messages_meet_received:5cluster_stats_messages_received:1720

查看集群節點信息：

> cluster nodes 470b7ff823f10a309fb07311097456210506f6d8 192.168.2.13:7005@17005 slave 36565e0273fd62921aa1f2d85c5f7ac98a5b9466 0 1600267217000 2 connected42d6e3979395ba93cd1352b6d17044f6b25d9379 192.168.2.11:7003@17003 slave 0cc1aaf960defae7332e9256dd25ee5e5c99e65f 0 1600267218171 3 connectedac5d34b57a8f73dabc60d3a56469055ec64fcde7 192.168.2.12:7004@17004 slave 5e50824c55d4df42db4d2987796f0c0b468c273f 0 1600267216161 1 connected0cc1aaf960defae7332e9256dd25ee5e5c99e65f 192.168.2.13:7002@17002 master - 0 1600267218070 3 connected 10923-1638336565e0273fd62921aa1f2d85c5f7ac98a5b9466 192.168.2.12:7001@17001 master - 0 1600267217163 2 connected 5461-109225e50824c55d4df42db4d2987796f0c0b468c273f 192.168.2.11:7000@17000 myself,master - 0 1600267217000 1 connected 0-5460

參考地址：

http://www.redis.cn/topics/cluster-tutorial.html

http://www.redis.cn/topics/cluster-spec.html

https://jasonkayzk.github.io

https://www.cnblogs.com/kevingrace/p/5685332.html

到此這篇關于通過Docker部署Redis 6.x集群的方法的文章就介紹到這了,更多相關Docker部署Redis 6.x集群內容請搜索好吧啦網以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持好吧啦網！