Redis(9)——史上最強【集群】入門實踐教程

本文轉載自查看原文 2020-03-17 17:02 1155 Java Web

一、Redis 集群概述

Redis 主從復制

到目前為止，我們所學習的 Redis 都是 單機版 的，這也就意味着一旦我們所依賴的 Redis 服務宕機了，我們的主流程也會受到一定的影響，這當然是我們不能夠接受的。

所以一開始我們的想法是：搞一台備用機。這樣我們就可以在一台服務器出現問題的時候切換動態地到另一台去：

幸運的是，兩個節點數據的同步我們可以使用 Redis 的 主從同步 功能幫助到我們，這樣一來，有個備份，心里就踏實多了。

Redis 哨兵

后來因為某種神秘力量，Redis 老會在莫名其妙的時間點出問題 (比如半夜 2 點)，我總不能 24 小時時刻守在電腦旁邊切換節點吧，於是另一個想法又開始了：給所有的節點找一個 "管家"，自動幫我監聽照顧節點的狀態並切換：

這大概就是 Redis 哨兵 (Sentinel) 的簡單理解啦。什么？管家宕機了怎么辦？相較於有大量請求的 Redis 服務來說，管家宕機的概率就要小得多啦.. 如果真的宕機了，我們也可以直接切換成當前可用的節點保證可用..

Redis 集群化

好了，通過上面的一些解決方案我們對 Redis 的 穩定性 稍微有了一些底氣了，但單台節點的計算能力始終有限，所謂人多力量大，如果我們把 多個節點組合 成 一個可用的工作節點，那就大大增加了 Redis 的 高可用、可擴展、分布式、容錯 等特性：

二、主從復制

主從復制，是指將一台 Redis 服務器的數據，復制到其他的 Redis 服務器。前者稱為 主節點(master)，后者稱為 從節點(slave)。且數據的復制是單向的，只能由主節點到從節點。Redis 主從復制支持 主從同步 和 從從同步 兩種，后者是 Redis 后續版本新增的功能，以減輕主節點的同步負擔。

主從復制主要的作用

數據冗余： 主從復制實現了數據的熱備份，是持久化之外的一種數據冗余方式。
故障恢復： 當主節點出現問題時，可以由從節點提供服務，實現快速的故障恢復 (實際上是一種服務的冗余)。
負載均衡： 在主從復制的基礎上，配合讀寫分離，可以由主節點提供寫服務，由從節點提供讀服務 （即寫 Redis 數據時應用連接主節點，讀 Redis 數據時應用連接從節點），分擔服務器負載。尤其是在寫少讀多的場景下，通過多個從節點分擔讀負載，可以大大提高 Redis 服務器的並發量。
高可用基石： 除了上述作用以外，主從復制還是哨兵和集群能夠實施的基礎，因此說主從復制是 Redis 高可用的基礎。

快速體驗

在 Redis 中，用戶可以通過執行 SLAVEOF 命令或者設置 slaveof 選項，讓一個服務器去復制另一個服務器，以下三種方式是 完全等效 的：

配置文件：在從服務器的配置文件中加入：slaveof <masterip> <masterport>
啟動命令：redis-server 啟動命令后加入 --slaveof <masterip> <masterport>
客戶端命令：Redis 服務器啟動后，直接通過客戶端執行命令：slaveof <masterip> <masterport>，讓該 Redis 實例成為從節點。

需要注意的是：主從復制的開啟，完全是在從節點發起的，不需要我們在主節點做任何事情。

第一步：本地啟動兩個節點

在正確安裝好 Redis 之后，我們可以使用 redis-server --port <port> 的方式指定創建兩個不同端口的 Redis 實例，例如，下方我分別創建了一個 6379 和 6380 的兩個 Redis 實例：

# 創建一個端口為 6379 的 Redis 實例
redis-server --port 6379
# 創建一個端口為 6380 的 Redis 實例
redis-server --port 6380

此時兩個 Redis 節點啟動后，都默認為 主節點。

第二步：建立復制

我們在 6380 端口的節點中執行 slaveof 命令，使之變為從節點：

# 在 6380 端口的 Redis 實例中使用控制台
redis-cli -p 6380
# 成為本地 6379 端口實例的從節點
127.0.0.1:6380> SLAVEOF 127.0.0.1ø 6379
OK

第三步：觀察效果

下面我們來驗證一下，主節點的數據是否會復制到從節點之中：

先在 從節點 中查詢一個 不存在 的 key：

127.0.0.1:6380> GET mykey
(nil)

再在 主節點 中添加這個 key：

127.0.0.1:6379> SET mykey myvalue
OK

此時再從 從節點 中查詢，會發現已經從 主節點 同步到 從節點：

127.0.0.1:6380> GET mykey
"myvalue"

第四步：斷開復制

通過 slaveof <masterip> <masterport> 命令建立主從復制關系以后，可以通過 slaveof no one 斷開。需要注意的是，從節點斷開復制后，不會刪除已有的數據，只是不再接受主節點新的數據變化。

從節點執行 slaveof no one 之后，從節點和主節點分別打印日志如下：、

# 從節點打印日志
61496:M 17 Mar 2020 08:10:22.749 # Connection with master lost.
61496:M 17 Mar 2020 08:10:22.749 * Caching the disconnected master state.
61496:M 17 Mar 2020 08:10:22.749 * Discarding previously cached master state.
61496:M 17 Mar 2020 08:10:22.749 * MASTER MODE enabled (user request from 'id=4 addr=127.0.0.1:55096 fd=8 name= age=1664 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=34 qbuf-free=32734 obl=0 oll=0 omem=0 events=r cmd=slaveof')

# 主節點打印日志
61467:M 17 Mar 2020 08:10:22.749 # Connection with replica 127.0.0.1:6380 lost.

實現原理簡析

為了節省篇幅，我把主要的步驟都濃縮在了上圖中，其實也可以 簡化成三個階段：准備階段-數據同步階段-命令傳播階段。下面我們來進行一些必要的說明。

身份驗證 | 主從復制安全問題

在上面的 快速體驗 過程中，你會發現 slaveof 這個命令居然不需要驗證？這意味着只要知道了 ip 和端口就可以隨意拷貝服務器上的數據了？

那當然不能夠了，我們可以通過在 主節點 配置 requirepass 來設置密碼，這樣就必須在 從節點 中對應配置好 masterauth 參數 (與主節點 requirepass 保持一致) 才能夠進行正常復制了。

SYNC 命令是一個非常耗費資源的操作

每次執行 SYNC 命令，主從服務器需要執行如下動作：

主服務器 需要執行 BGSAVE 命令來生成 RDB 文件，這個生成操作會消耗主服務器大量的 CPU、內存和磁盤 I/O 的資源；
主服務器 需要將自己生成的 RDB 文件發送給從服務器，這個發送操作會消耗主服務器 大量的網絡資源 (帶寬和流量)，並對主服務器響應命令請求的時間產生影響；
接收到 RDB 文件的 從服務器 需要載入主服務器發來的 RBD 文件，並且在載入期間，從服務器 會因為阻塞而沒辦法處理命令請求；

特別是當出現 斷線重復制 的情況是時，為了讓從服務器補足斷線時確實的那一小部分數據，卻要執行一次如此耗資源的 SYNC 命令，顯然是不合理的。

PSYNC 命令的引入

所以在 Redis 2.8 中引入了 PSYNC 命令來代替 SYNC，它具有兩種模式：

全量復制： 用於初次復制或其他無法進行部分復制的情況，將主節點中的所有數據都發送給從節點，是一個非常重型的操作；
部分復制： 用於網絡中斷等情況后的復制，只將 中斷期間主節點執行的寫命令 發送給從節點，與全量復制相比更加高效。需要注意 的是，如果網絡中斷時間過長，導致主節點沒有能夠完整地保存中斷期間執行的寫命令，則無法進行部分復制，仍使用全量復制；

部分復制的原理主要是靠主從節點分別維護一個 復制偏移量，有了這個偏移量之后斷線重連之后一比較，之后就可以僅僅把從服務器斷線之后確實的這部分數據給補回來了。

更多的詳細內容可以參考下方 參考資料 3

三、Redis Sentinel 哨兵

上圖展示了一個典型的哨兵架構圖，它由兩部分組成，哨兵節點和數據節點：

哨兵節點： 哨兵系統由一個或多個哨兵節點組成，哨兵節點是特殊的 Redis 節點，不存儲數據；
數據節點： 主節點和從節點都是數據節點；

在復制的基礎上，哨兵實現了 自動化的故障恢復 功能，下方是官方對於哨兵功能的描述：

監控（Monitoring）： 哨兵會不斷地檢查主節點和從節點是否運作正常。
自動故障轉移（Automatic failover）： 當 主節點 不能正常工作時，哨兵會開始 自動故障轉移操作，它會將失效主節點的其中一個 從節點升級為新的主節點，並讓其他從節點改為復制新的主節點。
配置提供者（Configuration provider）： 客戶端在初始化時，通過連接哨兵來獲得當前 Redis 服務的主節點地址。
通知（Notification）： 哨兵可以將故障轉移的結果發送給客戶端。

其中，監控和自動故障轉移功能，使得哨兵可以及時發現主節點故障並完成轉移。而配置提供者和通知功能，則需要在與客戶端的交互中才能體現。

快速體驗

第一步：創建主從節點配置文件並啟動

正確安裝好 Redis 之后，我們去到 Redis 的安裝目錄 (mac 默認在 /usr/local/)，找到 redis.conf 文件復制三份分別命名為 redis-master.conf/redis-slave1.conf/redis-slave2.conf，分別作為 1 個主節點和 2 個從節點的配置文件 (下圖演示了我本機的 redis.conf 文件的位置)

打開可以看到這個 .conf 后綴的文件里面有很多說明的內容，全部刪除然后分別改成下面的樣子：

#redis-master.conf
port 6379
daemonize yes
logfile "6379.log"
dbfilename "dump-6379.rdb"
 
#redis-slave1.conf
port 6380
daemonize yes
logfile "6380.log"
dbfilename "dump-6380.rdb"
slaveof 127.0.0.1 6379
 
#redis-slave2.conf
port 6381
daemonize yes
logfile "6381.log"
dbfilename "dump-6381.rdb"
slaveof 127.0.0.1 6379

然后我們可以執行 redis-server <config file path> 來根據配置文件啟動不同的 Redis 實例，依次啟動主從節點：

redis-server /usr/local/redis-5.0.3/redis-master.conf
redis-server /usr/local/redis-5.0.3/redis-slave1.conf
redis-server /usr/local/redis-5.0.3/redis-slave2.conf

節點啟動后，我們執行 redis-cli 默認連接到我們端口為 6379 的主節點執行 info Replication 檢查一下主從狀態是否正常：(可以看到下方正確地顯示了兩個從節點)

第二步：創建哨兵節點配置文件並啟動

按照上面同樣的方法，我們給哨兵節點也創建三個配置文件。(哨兵節點本質上是特殊的 Redis 節點，所以配置幾乎沒什么差別，只是在端口上做區分就好)

# redis-sentinel-1.conf
port 26379
daemonize yes
logfile "26379.log"
sentinel monitor mymaster 127.0.0.1 6379 2

# redis-sentinel-2.conf
port 26380
daemonize yes
logfile "26380.log"
sentinel monitor mymaster 127.0.0.1 6379 2

# redis-sentinel-3.conf
port 26381
daemonize yes
logfile "26381.log"
sentinel monitor mymaster 127.0.0.1 6379 2

其中，sentinel monitor mymaster 127.0.0.1 6379 2 配置的含義是：該哨兵節點監控 127.0.0.1:6379 這個主節點，該主節點的名稱是 mymaster，最后的 2 的含義與主節點的故障判定有關：至少需要 2 個哨兵節點同意，才能判定主節點故障並進行故障轉移。

執行下方命令將哨兵節點啟動起來：

redis-server /usr/local/redis-5.0.3/redis-sentinel-1.conf --sentinel
redis-server /usr/local/redis-5.0.3/redis-sentinel-2.conf --sentinel
redis-server /usr/local/redis-5.0.3/redis-sentinel-3.conf --sentinel

使用 redis-cil 工具連接哨兵節點，並執行 info Sentinel 命令來查看是否已經在監視主節點了：

# 連接端口為 26379 的 Redis 節點
➜  ~ redis-cli -p 26379
127.0.0.1:26379> info Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3

此時你打開剛才寫好的哨兵配置文件，你還會發現出現了一些變化：

第三步：演示故障轉移

首先，我們使用 kill -9 命令來殺掉主節點，同時在哨兵節點中執行 info Sentinel 命令來觀察故障節點的過程：

➜  ~ ps aux | grep 6379
longtao          74529   0.3  0.0  4346936   2132   ??  Ss   10:30上午   0:03.09 redis-server *:26379 [sentinel]
longtao          73541   0.2  0.0  4348072   2292   ??  Ss   10:18上午   0:04.79 redis-server *:6379
longtao          75521   0.0  0.0  4286728    728 s008  S+   10:39上午   0:00.00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn 6379
longtao          74836   0.0  0.0  4289844    944 s006  S+   10:32上午   0:00.01 redis-cli -p 26379
➜  ~ kill -9 73541

如果 剛殺掉瞬間 在哨兵節點中執行 info 命令來查看，會發現主節點還沒有切換過來，因為哨兵發現主節點故障並轉移需要一段時間：

# 第一時間查看哨兵節點發現並未轉移，還在 6379 端口
127.0.0.1:26379> info Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3

一段時間之后你再執行 info 命令，查看，你就會發現主節點已經切換成了 6381 端口的從節點：

# 過一段時間之后在執行，發現已經切換了 6381 端口
127.0.0.1:26379> info Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:6381,slaves=2,sentinels=3

但同時還可以發現，哨兵節點認為新的主節點仍然有兩個從節點 (上方 slaves=2)，這是因為哨兵在將 6381 切換成主節點的同時，將 6379 節點置為其從節點。雖然 6379 從節點已經掛掉，但是由於 哨兵並不會對從節點進行客觀下線，因此認為該從節點一直存在。當 6379 節點重新啟動后，會自動變成 6381 節點的從節點。

另外，在故障轉移的階段，哨兵和主從節點的配置文件都會被改寫：

對於主從節點： 主要是 slaveof 配置的變化，新的主節點沒有了 slaveof 配置，其從節點則 slaveof 新的主節點。
對於哨兵節點： 除了主從節點信息的變化，紀元(epoch) (記錄當前集群狀態的參數) 也會變化，紀元相關的參數都 +1 了。

客戶端訪問哨兵系統代碼演示

上面我們在 快速體驗 中主要感受到了服務端自己對於當前主從節點的自動化治理，下面我們以 Java 代碼為例，來演示一下客戶端如何訪問我們的哨兵系統：

public static void testSentinel() throws Exception {
         String masterName = "mymaster";
         Set<String> sentinels = new HashSet<>();
         sentinels.add("127.0.0.1:26379");
         sentinels.add("127.0.0.1:26380");
         sentinels.add("127.0.0.1:26381");
         
         // 初始化過程做了很多工作
         JedisSentinelPool pool = new JedisSentinelPool(masterName, sentinels); 
         Jedis jedis = pool.getResource();
         jedis.set("key1", "value1");
         pool.close();
}

客戶端原理

Jedis 客戶端對哨兵提供了很好的支持。如上述代碼所示，我們只需要向 Jedis 提供哨兵節點集合和 masterName ，構造 JedisSentinelPool 對象，然后便可以像使用普通 Redis 連接池一樣來使用了：通過 pool.getResource() 獲取連接，執行具體的命令。

在整個過程中，我們的代碼不需要顯式的指定主節點的地址，就可以連接到主節點；代碼中對故障轉移沒有任何體現，就可以在哨兵完成故障轉移后自動的切換主節點。之所以可以做到這一點，是因為在 JedisSentinelPool 的構造器中，進行了相關的工作；主要包括以下兩點：

遍歷哨兵節點，獲取主節點信息： 遍歷哨兵節點，通過其中一個哨兵節點 + masterName 獲得主節點的信息；該功能是通過調用哨兵節點的 sentinel get-master-addr-by-name 命令實現；
增加對哨兵的監聽： 這樣當發生故障轉移時，客戶端便可以收到哨兵的通知，從而完成主節點的切換。具體做法是：利用 Redis 提供的 發布訂閱 功能，為每一個哨兵節點開啟一個單獨的線程，訂閱哨兵節點的 + switch-master 頻道，當收到消息時，重新初始化連接池。

新的主服務器是怎樣被挑選出來的？

故障轉移操作的第一步 要做的就是在已下線主服務器屬下的所有從服務器中，挑選出一個狀態良好、數據完整的從服務器，然后向這個從服務器發送 slaveof no one 命令，將這個從服務器轉換為主服務器。但是這個從服務器是怎么樣被挑選出來的呢？

簡單來說 Sentinel 使用以下規則來選擇新的主服務器：

在失效主服務器屬下的從服務器當中，那些被標記為主觀下線、已斷線、或者最后一次回復 PING 命令的時間大於五秒鍾的從服務器都會被淘汰。
在失效主服務器屬下的從服務器當中，那些與失效主服務器連接斷開的時長超過 down-after 選項指定的時長十倍的從服務器都會被淘汰。
在 經歷了以上兩輪淘汰之后 剩下來的從服務器中，我們選出 復制偏移量（replication offset）最大 的那個 從服務器 作為新的主服務器；如果復制偏移量不可用，或者從服務器的復制偏移量相同，那么 帶有最小運行 ID 的那個從服務器成為新的主服務器。

四、Redis 集群

上圖展示了 Redis Cluster 典型的架構圖，集群中的每一個 Redis 節點都 互相兩兩相連，客戶端任意直連到集群中的 任意一台，就可以對其他 Redis 節點進行讀寫的操作。

基本原理

Redis 集群中內置了 16384 個哈希槽。當客戶端連接到 Redis 集群之后，會同時得到一份關於這個 集群的配置信息，當客戶端具體對某一個 key 值進行操作時，會計算出它的一個 Hash 值，然后把結果對 16384 求余數，這樣每個 key 都會對應一個編號在 0-16383 之間的哈希槽，Redis 會根據節點數量 大致均等 的將哈希槽映射到不同的節點。

再結合集群的配置信息就能夠知道這個 key 值應該存儲在哪一個具體的 Redis 節點中，如果不屬於自己管，那么就會使用一個特殊的 MOVED 命令來進行一個跳轉，告訴客戶端去連接這個節點以獲取數據：

GET x
-MOVED 3999 127.0.0.1:6381

MOVED 指令第一個參數 3999 是 key 對應的槽位編號，后面是目標節點地址，MOVED 命令前面有一個減號，表示這是一個錯誤的消息。客戶端在收到 MOVED 指令后，就立即糾正本地的 槽位映射表，那么下一次再訪問 key 時就能夠到正確的地方去獲取了。

集群的主要作用

數據分區： 數據分區 (或稱數據分片) 是集群最核心的功能。集群將數據分散到多個節點，一方面 突破了 Redis 單機內存大小的限制，存儲容量大大增加；另一方面 每個主節點都可以對外提供讀服務和寫服務，大大提高了集群的響應能力。Redis 單機內存大小受限問題，在介紹持久化和主從復制時都有提及，例如，如果單機內存太大，bgsave 和 bgrewriteaof 的 fork 操作可能導致主進程阻塞，主從環境下主機切換時可能導致從節點長時間無法提供服務，全量復制階段主節點的復制緩沖區可能溢出……
高可用： 集群支持主從復制和主節點的 自動故障轉移 （與哨兵類似），當任一節點發生故障時，集群仍然可以對外提供服務。

快速體驗

第一步：創建集群節點配置文件

首先我們找一個地方創建一個名為 redis-cluster 的目錄：

mkdir -p ~/Desktop/redis-cluster

然后按照上面的方法，創建六個配置文件，分別命名為：redis_7000.conf/redis_7001.conf.....redis_7005.conf，然后根據不同的端口號修改對應的端口值就好了：

# 后台執行
daemonize yes
# 端口號
port 7000
# 為每一個集群節點指定一個 pid_file
pidfile ~/Desktop/redis-cluster/redis_7000.pid
# 啟動集群模式
cluster-enabled yes
# 每一個集群節點都有一個配置文件，這個文件是不能手動編輯的。確保每一個集群節點的配置文件不通
cluster-config-file nodes-7000.conf
# 集群節點的超時時間，單位：ms，超時后集群會認為該節點失敗
cluster-node-timeout 5000
# 最后將 appendonly 改成 yes(AOF 持久化)
appendonly yes

記得把對應上述配置文件中根端口對應的配置都修改掉 (port/ pidfile/ cluster-config-file)。

第二步：分別啟動 6 個 Redis 實例

redis-server ~/Desktop/redis-cluster/redis_7000.conf
redis-server ~/Desktop/redis-cluster/redis_7001.conf
redis-server ~/Desktop/redis-cluster/redis_7002.conf
redis-server ~/Desktop/redis-cluster/redis_7003.conf
redis-server ~/Desktop/redis-cluster/redis_7004.conf
redis-server ~/Desktop/redis-cluster/redis_7005.conf

然后執行 ps -ef | grep redis 查看是否啟動成功：

可以看到 6 個 Redis 節點都以集群的方式成功啟動了，但是現在每個節點還處於獨立的狀態，也就是說它們每一個都各自成了一個集群，還沒有互相聯系起來，我們需要手動地把他們之間建立起聯系。

第三步：建立集群

執行下列命令：

redis-cli --cluster create --cluster-replicas 1 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005

這里稍微解釋一下這個 --replicas 1 的意思是：我們希望為集群中的每個主節點創建一個從節點。

觀察控制台輸出：

看到 [OK] 的信息之后，就表示集群已經搭建成功了，可以看到，這里我們正確地創建了三主三從的集群。

第四步：驗證集群

我們先使用 redic-cli 任意連接一個節點：

redis-cli -c -h 127.0.0.1 -p 7000
127.0.0.1:7000>

-c表示集群模式；-h 指定 ip 地址；-p 指定端口。

然后隨便 set 一些值觀察控制台輸入：

127.0.0.1:7000> SET name wmyskxz
-> Redirected to slot [5798] located at 127.0.0.1:7001
OK
127.0.0.1:7001>

可以看到這里 Redis 自動幫我們進行了 Redirected 操作跳轉到了 7001 這個實例上。

我們再使用 cluster info (查看集群信息) 和 cluster nodes (查看節點列表) 來分別看看：(任意節點輸入均可)

127.0.0.1:7001> CLUSTER INFO
cluster_state:ok
cluster_slots_assigned:16384
cluster_slots_ok:16384
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:6
cluster_size:3
cluster_current_epoch:6
cluster_my_epoch:2
cluster_stats_messages_ping_sent:1365
cluster_stats_messages_pong_sent:1358
cluster_stats_messages_meet_sent:4
cluster_stats_messages_sent:2727
cluster_stats_messages_ping_received:1357
cluster_stats_messages_pong_received:1369
cluster_stats_messages_meet_received:1
cluster_stats_messages_received:2727

127.0.0.1:7001> CLUSTER NODES
56a04742f36c6e84968cae871cd438935081e86f 127.0.0.1:7003@17003 slave 4ec8c022e9d546c9b51deb9d85f6cf867bf73db6 0 1584428884000 4 connected
4ec8c022e9d546c9b51deb9d85f6cf867bf73db6 127.0.0.1:7000@17000 master - 0 1584428884000 1 connected 0-5460
e2539c4398b8258d3f9ffa714bd778da107cb2cd 127.0.0.1:7005@17005 slave a3406db9ae7144d17eb7df5bffe8b70bb5dd06b8 0 1584428885222 6 connected
d31cd1f423ab1e1849cac01ae927e4b6950f55d9 127.0.0.1:7004@17004 slave 236cefaa9cdc295bc60a5bd1aed6a7152d4f384d 0 1584428884209 5 connected
236cefaa9cdc295bc60a5bd1aed6a7152d4f384d 127.0.0.1:7001@17001 myself,master - 0 1584428882000 2 connected 5461-10922
a3406db9ae7144d17eb7df5bffe8b70bb5dd06b8 127.0.0.1:7002@17002 master - 0 1584428884000 3 connected 10923-16383
127.0.0.1:7001>

數據分區方案簡析

方案一：哈希值 % 節點數

哈希取余分區思路非常簡單：計算 key 的 hash 值，然后對節點數量進行取余，從而決定數據映射到哪個節點上。

不過該方案最大的問題是，當新增或刪減節點時，節點數量發生變化，系統中所有的數據都需要 重新計算映射關系，引發大規模數據遷移。

方案二：一致性哈希分區

一致性哈希算法將 整個哈希值空間 組織成一個虛擬的圓環，范圍是 [0 - 2^{32 - 1}]，對於每一個數據，根據 key 計算 hash 值，確數據在環上的位置，然后從此位置沿順時針行走，找到的第一台服務器就是其應該映射到的服務器：

與哈希取余分區相比，一致性哈希分區將 增減節點的影響限制在相鄰節點。以上圖為例，如果在 node1 和 node2 之間增加 node5，則只有 node2 中的一部分數據會遷移到 node5；如果去掉 node2，則原 node2 中的數據只會遷移到 node4 中，只有 node4 會受影響。

一致性哈希分區的主要問題在於，當 節點數量較少 時，增加或刪減節點，對單個節點的影響可能很大，造成數據的嚴重不平衡。還是以上圖為例，如果去掉 node2，node4 中的數據由總數據的 1/4 左右變為 1/2 左右，與其他節點相比負載過高。

方案三：帶有虛擬節點的一致性哈希分區

該方案在 一致性哈希分區的基礎上，引入了 虛擬節點 的概念。Redis 集群使用的便是該方案，其中的虛擬節點稱為 槽（slot）。槽是介於數據和實際節點之間的虛擬概念，每個實際節點包含一定數量的槽，每個槽包含哈希值在一定范圍內的數據。

在使用了槽的一致性哈希分區中，槽是數據管理和遷移的基本單位。槽解耦了 數據和實際節點 之間的關系，增加或刪除節點對系統的影響很小。仍以上圖為例，系統中有 4 個實際節點，假設為其分配 16 個槽(0-15)；

槽 0-3 位於 node1；4-7 位於 node2；以此類推....

如果此時刪除 node2，只需要將槽 4-7 重新分配即可，例如槽 4-5 分配給 node1，槽 6 分配給 node3，槽 7 分配給 node4；可以看出刪除 node2 后，數據在其他節點的分布仍然較為均衡。

節點通信機制簡析

集群的建立離不開節點之間的通信，例如我們上訪在 快速體驗 中剛啟動六個集群節點之后通過 redis-cli 命令幫助我們搭建起來了集群，實際上背后每個集群之間的兩兩連接是通過了 CLUSTER MEET <ip> <port> 命令發送 MEET 消息完成的，下面我們展開詳細說說。

兩個端口

在 哨兵系統 中，節點分為 數據節點 和 哨兵節點：前者存儲數據，后者實現額外的控制功能。在集群中，沒有數據節點與非數據節點之分：所有的節點都存儲數據，也都參與集群狀態的維護。為此，集群中的每個節點，都提供了兩個 TCP 端口：

普通端口： 即我們在前面指定的端口 (7000等)。普通端口主要用於為客戶端提供服務 （與單機節點類似）；但在節點間數據遷移時也會使用。
集群端口： 端口號是普通端口 + 10000 （10000是固定值，無法改變），如 7000 節點的集群端口為 17000。集群端口只用於節點之間的通信，如搭建集群、增減節點、故障轉移等操作時節點間的通信；不要使用客戶端連接集群接口。為了保證集群可以正常工作，在配置防火牆時，要同時開啟普通端口和集群端口。

Gossip 協議

節點間通信，按照通信協議可以分為幾種類型：單對單、廣播、Gossip 協議等。重點是廣播和 Gossip 的對比。

廣播是指向集群內所有節點發送消息。優點是集群的收斂速度快(集群收斂是指集群內所有節點獲得的集群信息是一致的)，缺點是每條消息都要發送給所有節點，CPU、帶寬等消耗較大。
Gossip 協議的特點是：在節點數量有限的網絡中，每個節點都 “隨機” 的與部分節點通信 （並不是真正的隨機，而是根據特定的規則選擇通信的節點），經過一番雜亂無章的通信，每個節點的狀態很快會達到一致。Gossip 協議的優點有負載 (比廣播) 低、去中心化、容錯性高 (因為通信有冗余) 等；缺點主要是集群的收斂速度慢。

消息類型

集群中的節點采用 固定頻率（每秒10次） 的 定時任務 進行通信相關的工作：判斷是否需要發送消息及消息類型、確定接收節點、發送消息等。如果集群狀態發生了變化，如增減節點、槽狀態變更，通過節點間的通信，所有節點會很快得知整個集群的狀態，使集群收斂。

節點間發送的消息主要分為 5 種：meet 消息、ping 消息、pong 消息、fail 消息、publish 消息。不同的消息類型，通信協議、發送的頻率和時機、接收節點的選擇等是不同的：

MEET 消息： 在節點握手階段，當節點收到客戶端的 CLUSTER MEET 命令時，會向新加入的節點發送 MEET 消息，請求新節點加入到當前集群；新節點收到 MEET 消息后會回復一個 PONG 消息。
PING 消息： 集群里每個節點每秒鍾會選擇部分節點發送 PING 消息，接收者收到消息后會回復一個 PONG 消息。PING 消息的內容是自身節點和部分其他節點的狀態信息，作用是彼此交換信息，以及檢測節點是否在線。PING 消息使用 Gossip 協議發送，接收節點的選擇兼顧了收斂速度和帶寬成本，具體規則如下：(1)隨機找 5 個節點，在其中選擇最久沒有通信的 1 個節點；(2)掃描節點列表，選擇最近一次收到 PONG 消息時間大於 cluster_node_timeout / 2 的所有節點，防止這些節點長時間未更新。
PONG消息： PONG 消息封裝了自身狀態數據。可以分為兩種：第一種 是在接到 MEET/PING 消息后回復的 PONG 消息；第二種 是指節點向集群廣播 PONG 消息，這樣其他節點可以獲知該節點的最新信息，例如故障恢復后新的主節點會廣播 PONG 消息。
FAIL 消息： 當一個主節點判斷另一個主節點進入 FAIL 狀態時，會向集群廣播這一 FAIL 消息；接收節點會將這一 FAIL 消息保存起來，便於后續的判斷。
PUBLISH 消息： 節點收到 PUBLISH 命令后，會先執行該命令，然后向集群廣播這一消息，接收節點也會執行該 PUBLISH 命令。

數據結構簡析

節點需要專門的數據結構來存儲集群的狀態。所謂集群的狀態，是一個比較大的概念，包括：集群是否處於上線狀態、集群中有哪些節點、節點是否可達、節點的主從狀態、槽的分布……

節點為了存儲集群狀態而提供的數據結構中，最關鍵的是 clusterNode 和 clusterState 結構：前者記錄了一個節點的狀態，后者記錄了集群作為一個整體的狀態。

clusterNode 結構

clusterNode 結構保存了 一個節點的當前狀態，包括創建時間、節點 id、ip 和端口號等。每個節點都會用一個 clusterNode 結構記錄自己的狀態，並為集群內所有其他節點都創建一個 clusterNode 結構來記錄節點狀態。

下面列舉了 clusterNode 的部分字段，並說明了字段的含義和作用：

typedef struct clusterNode {
    //節點創建時間
    mstime_t ctime;
    //節點id
    char name[REDIS_CLUSTER_NAMELEN];
    //節點的ip和端口號
    char ip[REDIS_IP_STR_LEN];
    int port;
    //節點標識：整型，每個bit都代表了不同狀態，如節點的主從狀態、是否在線、是否在握手等
    int flags;
    //配置紀元：故障轉移時起作用，類似於哨兵的配置紀元
    uint64_t configEpoch;
    //槽在該節點中的分布：占用16384/8個字節，16384個比特；每個比特對應一個槽：比特值為1，則該比特對應的槽在節點中；比特值為0，則該比特對應的槽不在節點中
    unsigned char slots[16384/8];
    //節點中槽的數量
    int numslots;
    …………
} clusterNode;

除了上述字段，clusterNode 還包含節點連接、主從復制、故障發現和轉移需要的信息等。

clusterState 結構

clusterState 結構保存了在當前節點視角下，集群所處的狀態。主要字段包括：

typedef struct clusterState {
    //自身節點
    clusterNode *myself;
    //配置紀元
    uint64_t currentEpoch;
    //集群狀態：在線還是下線
    int state;
    //集群中至少包含一個槽的節點數量
    int size;
    //哈希表，節點名稱->clusterNode節點指針
    dict *nodes;
    //槽分布信息：數組的每個元素都是一個指向clusterNode結構的指針；如果槽還沒有分配給任何節點，則為NULL
    clusterNode *slots[16384];
    …………
} clusterState;

除此之外，clusterState 還包括故障轉移、槽遷移等需要的信息。

更多關於集群內容請自行閱讀《Redis 設計與實現》，其中有更多細節方面的介紹 - http://redisbook.com/

參考資料

《Redis 設計與實現》 | 黃健宏著 - http://redisbook.com/
《Redis 深度歷險》 | 錢文品著 - https://book.douban.com/subject/30386804/
深入學習Redis（3）：主從復制 - https://www.cnblogs.com/kismetv/p/9236731.html
Redis 主從復制原理與用法 - https://blog.csdn.net/Stubborn_Cow/article/details/50442950
深入學習Redis（4）：哨兵 - https://www.cnblogs.com/kismetv/p/9609938.html
Redis 5 之后版本的高可用集群搭建 - https://www.jianshu.com/p/8045b92fafb2

本文已收錄至我的 Github 程序員成長系列 【More Than Java】，學習，不止 Code，歡迎 star：https://github.com/wmyskxz/MoreThanJava

個人公眾號 ：wmyskxz，個人獨立域名博客：wmyskxz.com，堅持原創輸出，下方掃碼關注，2020，與您共同成長！

非常感謝各位人才能 看到這里，如果覺得本篇文章寫得不錯，覺得 「我沒有三顆心臟」有點東西 的話，求點贊，求關注，求分享，求留言！

創作不易，各位的支持和認可，就是我創作的最大動力，我們下篇文章見！

免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。

猜您在找 史上最強Tableau Server 安裝教程史上最強大的js圖表庫——ECharts帶你入門(轉) 史上最全最強SpringMVC詳細示例實戰教程可能是史上最強大的js圖表庫——ECharts帶你入門史上最全最強SpringMVC詳細示例實戰教程 Redis 集群架構（史上最全） Redis集群 - 圖解 - 秒懂（史上最全) 史上最強Java NIO入門：擔心從入門到放棄的，請讀這篇！ redis入門與集群部署 Redis集群入門

Redis(9)——史上最強【集群】入門實踐教程

一、Redis 集群概述

Redis 主從復制

Redis 哨兵

Redis 集群化

二、主從復制

主從復制主要的作用

快速體驗

第一步：本地啟動兩個節點

第二步：建立復制

第三步：觀察效果

第四步：斷開復制

實現原理簡析

身份驗證 | 主從復制安全問題

SYNC 命令是一個非常耗費資源的操作

PSYNC 命令的引入

三、Redis Sentinel 哨兵

快速體驗

第一步：創建主從節點配置文件並啟動

第二步：創建哨兵節點配置文件並啟動

第三步：演示故障轉移

客戶端訪問哨兵系統代碼演示

客戶端原理

新的主服務器是怎樣被挑選出來的？

四、Redis 集群

基本原理

集群的主要作用

快速體驗

第一步：創建集群節點配置文件

第二步：分別啟動 6 個 Redis 實例

第三步：建立集群

第四步：驗證集群

數據分區方案簡析

方案一：哈希值 % 節點數

方案二：一致性哈希分區

方案三：帶有虛擬節點的一致性哈希分區

節點通信機制簡析

兩個端口

Gossip 協議

消息類型

數據結構簡析

clusterNode 結構

clusterState 結構

相關閱讀

參考資料

免責聲明！