文章目錄

• Pre
• 需求 ：集群不完整仍然需要對外提供服務
• 驗證
• • Redis Cluster 架構
  • 高可用切換
  • Code訪問測試
  • 繼續停掉8006 ，驗證集群是否down掉

---

Pre

Redis進階-Redis集群原理剖析及gossip協議初探 中提到了 “ 集群是否完整才能對外提供服務” ，這里我們詳細展開驗證下

---

需求 ：集群不完整仍然需要對外提供服務

假設我們現在的集群架構是 3主 6從 的redis cluster .

那3個master 平分16384個slot，每個master的小集群 負責 1/3的slot，對應一部分數據。

通常情況，如果這3個小集群中，任何一個（1主2從） 掛了，你這個集群對外可提供的數據只有2/3了， 整個集群是不完整的， redis 默認在這種情況下，是不會對外提供服務的。

如果你的訴求是，集群不完整的話 也需要對外提供服務，比如如下，你也希望redis cluster 對外提供服務

Redis也考慮到了這一點，提供了參數cluster-require-full-coverage

cluster-require-full-coverage： 默認值 yes , 即需要集群完整性，方可對外提供服務 ,

如果你要支持上述你的需求，需要將該參數設置為no ，這樣的話，你掛了的那個小集群是不行了，但是其他的小集群仍然可以對外提供服務。

redis.conf中說明和配置如下：

---

驗證

Redis Cluster 架構

我們先看下默認參數下的場景 ， 先看下我們目前的redis nodes 情況 （簡單的3主3從）

[redis@artisan bin]$ ./redis-cli -c -h 192.168.18.131 -p 8001 -a artisan Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. 192.168.18.131:8001> CLUSTER NODES 3410ea1dd49144f5d02b59036641bde566f03ee0 192.168.18.132:8005@18005 master - 0 1586809003000 10 connected 10923-16383 9a6804a96f9351d3fd61ea1e4d7dd77976b4133b 192.168.18.132:8002@18002 master - 0 1586809002648 3 connected 5461-10922 c4083f856388cc73feb3223433d10500b5556abe 192.168.18.131:8004@18004 slave 9a6804a96f9351d3fd61ea1e4d7dd77976b4133b 0 1586809002547 3 connected 6bff20d4d3564180cb8f4e623d1e0cd9f79b68e1 192.168.18.131:8001@18001 myself,master - 0 1586809001000 9 connected 0-5460 80618eaa0de9524cf439294b7cb6df1a34d3ad22 192.168.18.133:8003@18003 slave 3410ea1dd49144f5d02b59036641bde566f03ee0 0 1586809003961 10 connected 3178d965b77e2967930d7ea6072cdb9d7e5ba8ef 192.168.18.133:8006@18006 slave 6bff20d4d3564180cb8f4e623d1e0cd9f79b68e1 0 1586809003000 9 connected 192.168.18.131:8001>

192.168.18.131:8001主 192.168.18.133:8006從

192.168.18.132:8005 主 192.168.18.133:8003 從

192.168.18.132:8002 主 192.168.18.131:8004從

高可用切換

手工kill 8001 ，模擬故障

[redis@artisan redis-5.0.3]$ cd bin/ [redis@artisan bin]$ ps -ef|grep redis-server redis 655 597 0 06:06 pts/1 00:00:00 grep --color=auto redis-server redis 2926 1 0 Apr12 ? 00:09:43 ./redis-5.0.3/bin/redis-server *:8001 [cluster] redis 2949 1 0 Apr12 ? 00:10:00 ./redis-5.0.3/bin/redis-server *:8004 [cluster] [redis@artisan bin]$ [redis@artisan bin]$ [redis@artisan bin]$ [redis@artisan bin]$ kill 2926 [redis@artisan bin]$

先看看他的從節點 8006的日志 ，仔細觀察日志

7834:S 14 Apr 2020 06:06:19.665 # Connection with master lost. 7834:S 14 Apr 2020 06:06:19.665 * Caching the disconnected master state. 7834:S 14 Apr 2020 06:06:19.804 * Connecting to MASTER 192.168.18.131:8001 7834:S 14 Apr 2020 06:06:19.804 * MASTER <-> REPLICA sync started 7834:S 14 Apr 2020 06:06:19.804 # Error condition on socket for SYNC: Connection refused 7834:S 14 Apr 2020 06:06:20.812 * Connecting to MASTER 192.168.18.131:8001 7834:S 14 Apr 2020 06:06:20.812 * MASTER <-> REPLICA sync started 7834:S 14 Apr 2020 06:06:20.813 # Error condition on socket for SYNC: Connection refused 7834:S 14 Apr 2020 06:06:21.822 * Connecting to MASTER 192.168.18.131:8001 7834:S 14 Apr 2020 06:06:21.822 * MASTER <-> REPLICA sync started 7834:S 14 Apr 2020 06:06:21.822 # Error condition on socket for SYNC: Connection refused 7834:S 14 Apr 2020 06:06:22.831 * Connecting to MASTER 192.168.18.131:8001 7834:S 14 Apr 2020 06:06:22.832 * MASTER <-> REPLICA sync started 7834:S 14 Apr 2020 06:06:22.833 # Error condition on socket for SYNC: Connection refused 7834:S 14 Apr 2020 06:06:23.843 * Connecting to MASTER 192.168.18.131:8001 7834:S 14 Apr 2020 06:06:23.844 * MASTER <-> REPLICA sync started 7834:S 14 Apr 2020 06:06:23.844 # Error condition on socket for SYNC: Connection refused 7834:S 14 Apr 2020 06:06:24.849 * Connecting to MASTER 192.168.18.131:8001 7834:S 14 Apr 2020 06:06:24.849 * MASTER <-> REPLICA sync started 7834:S 14 Apr 2020 06:06:24.849 # Error condition on socket for SYNC: Connection refused 7834:S 14 Apr 2020 06:06:25.858 * Connecting to MASTER 192.168.18.131:8001 7834:S 14 Apr 2020 06:06:25.858 * MASTER <-> REPLICA sync started 7834:S 14 Apr 2020 06:06:25.858 # Error condition on socket for SYNC: Connection refused 7834:S 14 Apr 2020 06:06:26.542 * FAIL message received from 9a6804a96f9351d3fd61ea1e4d7dd77976b4133b about 6bff20d4d3564180cb8f4e623d1e0cd9f79b68e1 7834:S 14 Apr 2020 06:06:26.542 # Cluster state changed: fail 7834:S 14 Apr 2020 06:06:26.567 # Start of election delayed for 663 milliseconds (rank #0, offset 211176). 7834:S 14 Apr 2020 06:06:26.869 * Connecting to MASTER 192.168.18.131:8001 7834:S 14 Apr 2020 06:06:26.869 * MASTER <-> REPLICA sync started 7834:S 14 Apr 2020 06:06:26.869 # Error condition on socket for SYNC: Connection refused 7834:S 14 Apr 2020 06:06:27.273 # Starting a failover election for epoch 15. 7834:S 14 Apr 2020 06:06:27.309 # Failover election won: I'm the new master. 7834:S 14 Apr 2020 06:06:27.309 # configEpoch set to 15 after successful failover 7834:M 14 Apr 2020 06:06:27.309 # Setting secondary replication ID to eb9734612ef543cff912182e38ad59e531770939, valid up to offset: 211177. New replication ID is 7dc4e4f8a55df7feac1dc7979ea7a783bad2d2e4 7834:M 14 Apr 2020 06:06:27.309 * Discarding previously cached master state. 7834:M 14 Apr 2020 06:06:27.309 # Cluster state changed: ok

看看8005（兩位一個主節點）

6926:M 14 Apr 2020 06:06:26.540 * Marking node 6bff20d4d3564180cb8f4e623d1e0cd9f79b68e1 as failing (quorum reached). 6926:M 14 Apr 2020 06:06:26.540 # Cluster state changed: fail 6926:M 14 Apr 2020 06:06:27.305 # Failover auth granted to 3178d965b77e2967930d7ea6072cdb9d7e5ba8ef for epoch 15 6926:M 14 Apr 2020 06:06:27.310 # Cluster state changed: ok

granted to 3178d965b77e2967930d7ea6072cdb9d7e5ba8ef （8006的NodeID） ， 主節點回應

再看看 8003 （8005的從節點）

7826:S 14 Apr 2020 06:06:26.543 * FAIL message received from 9a6804a96f9351d3fd61ea1e4d7dd77976b4133b about 6bff20d4d3564180cb8f4e623d1e0cd9f79b68e1 7826:S 14 Apr 2020 06:06:26.543 # Cluster state changed: fail 7826:S 14 Apr 2020 06:06:27.344 # Cluster state changed: ok

從節點不回應

符合我們之前說的集群選舉過程。

---

查看集群狀態

可以發現 8006 提升為了主節點 ，8001的狀態為fail

---

Code訪問測試

import redis.clients.jedis.HostAndPort; import redis.clients.jedis.JedisCluster; import redis.clients.jedis.JedisPoolConfig;import java.io.IOException; import java.util.HashSet; import java.util.Set;public class JedisClusterDemo {public static void main(String[] args) throws IOException {JedisPoolConfig config = new JedisPoolConfig();config.setMaxTotal(20);config.setMaxIdle(10);config.setMinIdle(5);Set<HostAndPort> jedisClusterNode = new HashSet<HostAndPort>();jedisClusterNode.add(new HostAndPort("192.168.18.131", 8001));jedisClusterNode.add(new HostAndPort("192.168.18.131", 8004));jedisClusterNode.add(new HostAndPort("192.168.18.132", 8002));jedisClusterNode.add(new HostAndPort("192.168.18.132", 8005));jedisClusterNode.add(new HostAndPort("192.168.18.133", 8003));jedisClusterNode.add(new HostAndPort("192.168.18.133", 8006));JedisCluster jedisCluster = null;try {//connectionTimeout：指的是連接一個url的連接等待時間//soTimeout：指的是連接上一個url，獲取response的返回等待時間jedisCluster = new JedisCluster(jedisClusterNode, 6000, 5000, 10, "artisan", config);System.out.println(jedisCluster.set("clusterArtisan", "artisanValue"));System.out.println(jedisCluster.get("clusterArtisan"));} catch (Exception e) {e.printStackTrace();} finally {if (jedisCluster != null)jedisCluster.close();}} }

---

繼續停掉8006 ，驗證集群是否down掉

[redis@artisan log]$ ps -ef|grep 8006 redis 6371 3391 0 06:21 pts/0 00:00:00 grep --color=auto 8006 redis 7834 1 0 Apr12 ? 00:09:30 ./redis-5.0.3/bin/redis-server *:8006 [cluster] [redis@artisan log]$ [redis@artisan log]$ [redis@artisan log]$ kill 7834 [redis@artisan log]$ [redis@artisan log]$

再次使用代碼訪問 ，CLUSTERDOWN The cluster is down

結果。。集群宕了。 默認情況下 cluster-require-full-coverage 為 yes ，需要集群完整性，才能對外提供服務

在查看下nodes的狀態

如果你想這個時候，還讓redis對外提供服務，cluster-require-full-coverage設置為no 即可。

已經驗證過了，未記錄筆記，周知~

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的Redis进阶-Redis集群 【高可用切换】【cluster-require-full-coverage】集群是否完整才能对外提供服务的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。