共計 3907 個字符，預計需要花費 10 分鐘才能閱讀完成。

這篇文章主要為大家展示了“Redis 中 cluster 集群的示例分析”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓丸趣 TV 小編帶領大家一起研究并學習一下“Redis 中 cluster 集群的示例分析”這篇文章吧。

1. 前言

Redis 集群模式主要有 2 種:

主從集群、分布式集群。

前者主要是為了高可用或是讀寫分離，后者為了更好的存儲數據，負載均衡。

redis 集群提供了以下兩個好處

1、將數據自動切分 (split) 到多個節點

2、當集群中的某一個節點故障時，redis 還可以繼續處理客戶端的請求。

一個 redis 集群包含 16384 個哈希槽（hash slot），數據庫中的每個數據都屬于這 16384 個哈希槽中的一個。集群使用公式 CRC16(key) % 16384 來計算鍵 key 屬于哪個槽。集群中的每一個節點負責處理一部分哈希槽。

集群中的主從復制

集群中的每個節點都有 1 個至 N 個復制品，其中一個為主節點，其余的為從節點，如果主節點下線了，集群就會把這個主節點的一個從節點設置為新的主節點，繼續工作。這樣集群就不會因為一個主節點的下線而無法正常工作

注意：

1、如果某一個主節點和他所有的從節點都下線的話，redis 集群就會停止工作了。redis 集群不保證數據的強一致性，在特定的情況下，redis 集群會丟失已經被執行過的寫命令

2、使用異步復制（asynchronous replication）是 redis 集群可能會丟失寫命令的其中一個原因，有時候由于網絡原因，如果網絡斷開時間太長，redis 集群就會啟用新的主節點，之前發給主節點的數據就會丟失。

2. 主從切換原理

Redis 的主從原理與 MySQL 相似，都是設置兩臺機器，一主一從。也就是常說的熱備與冷備。設置主從的同時，設置兩個哨兵進程，用來檢測主節點是否宕機。若發現主節點宕機，立馬從從節點內選取出合適的節點 作為新的主節點。這點與 VIP(虛擬 IP 技術有點相似)。

3.Redis 群集 TCP 端口

每個 Redis 群集的節點都需要打開兩個 TCP 連接，由于這兩個連接就需要兩個端口，分別是用于為客戶端提供服務的常規 Redis TCP 命令端口（例如 6379）以及通過將 10000 和命令端口相加（10000+6379）而獲得的端口，就是集群端口（例如 16379）。

第二個大號端口用于群集總線，即使用二進制協議的節點到節點通信通道。節點使用群集總線進行故障檢測，配置更新，故障轉移授權等。客戶端不應嘗試與群集總線端口通信，為了保證 Redis 命令端口的正常使用，請確保在防火墻中打開這兩個端口，否則 Redis 群集節點將無法通信。

命令端口和集群總線端口偏移量是固定的，始終為 10000。

請注意，為了讓 Redis 群集正常工作，您需要為每個節點：

1、用于與客戶端進行通信的普通客戶端通信端口（通常為 6379）對所有需要到達群集的客戶端以及所有其他群集節點（使用客戶端端口進行密鑰遷移）都是開放的。

2、集群總線端口（客戶端端口 + 10000）必須可從所有其他集群節點訪問。

如果您不打開這兩個 TCP 端口，則您的群集將無法正常工作。

集群總線使用不同的二進制協議進行節點到節點的數據交換，這更適合于使用很少的帶寬和處理時間在節點之間交換信息。

4.Redis 集群和 Docker

目前，Redis 群集不支持 NAT 地址環境，并且在 IP 地址或 TCP 端口被重新映射的一般環境中。

Docker 使用一種叫做端口映射的技術：Docker 容器中運行的程序可能會暴露在與程序認為使用的端口不同的端口上。這對于在同一服務器中同時使用相同端口運行多個容器很有用。

為了使 Docker 與 Redis Cluster 兼容，您需要使用 Docker 的主機聯網模式。請查看 Docker 文檔中的–net = host 選項以獲取更多信息。

5.Redis 集群數據分片

Redis 集群沒有使用一致的散列，而是一種不同的分片形式，其中每個 key 在概念上都是我們稱之為散列槽的部分。

Redis 集群中有 16384 個散列槽，為了計算給定 key 的散列槽，我們簡單地取 16384 模的 CRC16。

Redis 集群中的每個節點負責哈希槽的一個子集，例如，您可能有一個具有 3 個節點的集群，其中：

1、節點 A 包含從 0 到 5500 的散列槽。

2、節點 B 包含從 5501 到 11000 的散列槽。

3、節點 C 包含從 11001 到 16383 的散列槽。

這允許輕松地添加和刪除集群中的節點。例如，如果我想添加一個新節點 D，我需要將節點 A，B，C 中的一些散列槽移動到 D。同樣，如果我想從集群中刪除節點 A，我可以只移動由 A 使用的散列槽到 B 和 C，當節點 A 將為空時，我可以將它從群集中徹底刪除。

因為將散列槽從一個節點移動到另一個節點不需要停機操作，添加和移除節點或更改節點占用的散列槽的百分比也不需要任何停機時間。

只要涉及單個命令執行（或整個事務或 Lua 腳本執行）的所有 key 都屬于同一散列插槽，Redis 群集就支持多個 key 操作。用戶可以使用稱為散列標簽的概念強制多個 key 成為同一個散列槽的一部分。

Hash 標記記錄在 Redis 集群規范文檔中，但要點是如果在關鍵字 {} 括號內有一個子字符串，那么只有該花括號“{}”內部的內容被散列，例如 this{foo}key 和 another{foo}key 保證在同一散列槽中，并且可以在具有多個 key 作為參數的命令中一起使用。

6.Redis 集群之主從模型

為了在主服務器節點的子集失敗或不能與大多數節點通信時保持可用，Redis 集群使用主從模型，其中每個散列槽從 1（主服務器本身）到 N 個副本（N - 1 個附加從節點）。

在我們具有節點 A，B，C 的示例的群集中，如果節點 B 失敗，則群集無法繼續，因為我們沒有辦法再在 5501-11000 范圍內提供散列槽。然而，當創建集群時（或稍后），我們為每個主服務器節點添加一個從服務器節點，以便最終集群由作為主服務器節點的 A，B，C 以及作為從服務器節點的 A1，B1，C1 組成，如果節點 B 發生故障，系統能夠繼續運行。節點 B1 復制 B，并且 B 失敗，則集群將促使節點 B1 作為新的主服務器節點并且將繼續正確地操作。

但請注意，如果節點 B 和 B1 在同一時間發生故障，則 Redis 群集無法繼續運行。

7.Redis 集群一致性保證

Redis 集群無法保證很強的一致性。實際上，這意味著在某些情況下，Redis 集群可能會丟失系統向客戶確認的寫入。

Redis 集群可能會丟失寫入的第一個原因是因為它使用異步復制。這意味著在寫入期間會發生以下事情：

1、你的客戶端寫給主服務器節點 B

2、主服務器節點 B 向您的客戶端回復確認。

3、主服務器節點 B 將寫入傳播到它的從服務器 B1，B2 和 B3。

正如你可以看到主服務器節點 B 在回復客戶端之前不等待 B1，B2，B3 的確認，因為這會對 Redis 造成嚴重的延遲損失，所以如果你的客戶端寫入了某些東西，主服務器節點 B 確認寫入，就在將寫入發送給它的從服務器節點存儲之前系統崩潰了，其中一個從站（沒有收到寫入）可以提升為主站，永遠丟失寫入。

這與大多數配置為每秒將數據刷新到磁盤的數據庫所發生的情況非常相似，因為過去的經驗與傳統數據庫系統有關，不會涉及分布式系統，因此您已經能夠推斷這種情況。同樣，通過強制數據庫在回復客戶端之前刷新磁盤上的數據，這樣可以提高一致性，但這通常會導致性能極低。這與 Redis Cluster 中的同步復制相當。

基本上，性能和一致性之間需要權衡。

Redis 集群在絕對需要時也支持同步寫入，通過 WAIT 命令實現，這使得丟失寫入的可能性大大降低，但請注意，即使使用同步復制，Redis 集群也不可能實現完全的一致性：總是有可能會發生故常，在無法接受寫入的從設備被選為主設備的時候。

還有另一個值得注意的情況，Redis 集群也將丟失數據的寫入，這種情況發生在網絡分區的時候，客戶端與包含至少一個主服務器的少數實例隔離。

以 A，B，C，A1，B1，C1 三個主站和三個從站組成的 6 個節點集群為例。還有一個客戶，我們會調用 Z1。

分區發生后，可能在分區的一側有 A，C，A1，B1，C1，另一側有 B 和 Z1。

Z1 仍然能夠寫入 B，它也會接受 Z1 的寫入。如果分區在很短的時間內恢復，則群集將正常繼續。但是，如果分區使用比較長的時間將 B1 提升為多數側分區的主設備，則 Z1 發送給 B 的寫入操作將丟失。

請注意，Z1 能夠發送給 B 的寫入量有一個最大窗口（maximum window）：如果分區多數側有足夠的時間選擇一個從設備作為主設備，那么少數側的每個主節點將停止接受寫操作。

這個時間值是 Redis 集群非常重要的配置指令，稱為 node timeout (節點超時)。

在節點超時過后，主節點被認為是失效的，并且可以被其副本之一替換。類似地，節點超時過后，主節點無法感知大多數其他主節點，它進入錯誤狀態并停止接受寫入。

8.redis 容錯機制

每個 redis 提供了節點之間相互發送 ping 命令，用于測試每個節點的健康狀態，集群中連接正常的節點收到其他接節點發送的 ping 命令時，會返回一個 pong 字符串

Redis 投票機制：如果一個節點 A 給 B 發送 ping 沒有得到 pong 返回，那么 A 就會通知其他節點再次給 B 發送 ping，如果集群中超過一半的節點給 B 發送 ping 都沒有得到返回，那么 B 就被坐實 game over 了，所以為了避免單點故障，一般都會為 redis 的每個節點提供了備份節點，B 節點掛掉之后立馬啟動 B 的節點服務器。

以上是“Redis 中 cluster 集群的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注丸趣 TV 行業資訊頻道！