當前位置：首頁 > 运维知识 > 数据库 >内容正文

数据库

redis开启redis_Redis聚类

發布時間：2023/12/3 数据库 36 豆豆

生活随笔收集整理的這篇文章主要介紹了 redis开启redis_Redis聚类小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

redis開啟redis

本文是我們學院課程的一部分，標題為Redis NoSQL鍵值存儲。

這是Redis的速成課程。您將學習如何安裝Redis和啟動服務器。此外，您還會在Redis命令行上亂七八糟。接下來是更高級的主題，例如復制，分片和集群，同時還介紹了Redis與Spring Data的集成。在這里查看！

1.簡介

本教程的最后部分專門介紹Redis的最新和最酷但仍處于試驗階段（尚未投入生產）的功能-群集。本部分的內容主要基于Redis文檔部分http://redis.io/topics/cluster-tutorial和http://redis.io/topics/cluster-spec 。 Redis集群（或簡稱Redis集群）是一種分布式Redis部署，旨在解決以下主要目標：

自動在多個節點之間分割數據集的能力
提供高性能和線性可擴展性的能力
保留來自與大多數節點連接的客戶端的所有寫入的能力（ 寫入安全性 / 一致性 ）
能夠在大多數主節點可訪問且每個不再可用的主節點上至少有一個可訪問的從節點的網絡分區中生存的能力（ 可用性 ）

Redis Cluster是數據分片（分區）的替代（但更高級）解決方案，我們已經在本教程的第4部分“ Redis Sharding”中看到過（但不是使用第三方工具，所有功能都由Redis本身提供）附加配置）。為了實現高可用性，Redis Cluster還高度依賴于主從復制，這在本教程的第3部分“ Redis復制”中已經看到。

2. Redis集群限制

首先，與Redis Cluster相關的所有功能都處于實驗模式，尚未準備好用于生產。

構建任何高度可用的分布式系統都很困難，但是Redis試圖使其成為可能。有一些局限性需要注意和權衡，我們已經提到了其中一些，但在這里也有必要重復一下。

首先，處理多個按鍵的命令不被Redis的集群支持（ SINTER ， SUNION ，...）。這種功能需要在Redis節點之間移動數據，這將使Redis Cluster無法在負載下提供可接受的性能和可預測的行為。通常，在Redis節點中處理命令的鍵不可用的所有操作都不會實現。

其次，Redis Cluster不支持像獨立版本的Redis一樣的多個數據庫。只有一個數據庫0，并且不允許SELECT 。

第三，Redis集群中的節點不將命令代理到存儲給定密鑰的正確節點，而是將客戶端重定向到服務給定范圍的密鑰空間的正確節點（所謂的query routing的混合形式）。最終，客戶端獲得群集拓撲的最新表示，并且知道哪個節點提供密鑰的哪個子集，可以直接聯系正確的節點以發送給定命令（有效地回退到client side partitioning ）。

3.分片（分區）方案

正如我們從第4部分 Redis Sharding中已經知道的那樣，有兩種數據分片（分區）方案用于拆分數據，而一致性哈希是最先進和廣泛使用的方案。 Redis Cluster不使用一致的哈希，而是使用不同形式的數據拆分，每個鍵都是所謂的hash slot 。

Redis群集中有16384個hash slots ，并計算給定密鑰的hash slot ，該密鑰的CRC16函數（ http://en.wikipedia.org/wiki/Cyclic_redundancy_check ）被計算，然后取模將16384的結果應用于其結果。

Redis群集中的每個節點都負責hash slots的子集。例如，讓我們考慮一個具有四個Redis節點＃ 1 ，＃ 2 ，＃ 3和＃ 4的集群。這可能會給我們以下hash slots分布：

Redis節點1包含從0到4096的 hash slots
Redis節點2包含從4097到8192的 hash slots
Redis節點3包含從8193到12288的 hash slots
Redis節點4包含從12289到16383的 hash slots

這種分片（分區）方案可以輕松更改群集的拓撲（添加和刪除節點）。例如，如果需要添加新節點＃5，則應將來自節點＃ 1 ，＃ 2 ，＃ 3和＃ 4的一些hash slots移至節點＃ 5 。同樣，如果需要從群集中刪除節點＃ 3 ，則應將節點＃ 3服務的hash slots移至節點＃ 1和＃ 2 。當節點＃3變空時，可以將其從群集中永久刪除。

現在最好的部分是：因為將hash slots從一個節點移動到另一個節點不需要停止正在進行的操作，所以添加和刪除節點（或更改節點持有的hash slots的百分比）不需要停機。

在本教程的后面，我們將回到本示例，并使用三個Redis主節點（每個節點由一個從屬節點支持）構建實際的集群。在Redis Cluster運行期間，我們將添加和刪除一些節點，以了解如何實時hash slots 。

3.1鍵哈希標簽

Redis分片（分區）方案支持的非常有趣的功能就是所謂的密鑰hash tags 。 Hash tags是一種確保在同一hash slot分配兩個（或多個）密鑰的技術。

為了支持hash tags ， hash slot以不同的方式計算。如果鍵包含“ {…} ”模式，則僅對“ { ”和“ } ”之間的子字符串進行哈希處理以獲得hash slot （如果多次出現“ { ”或“ } ”）鍵名，一些規則已經制定，并在http://redis.io/topics/cluster-spec中進行了描述。

我們在第4部分的 Redis Sharding中玩過的Twemproxy （ nutcracker ）還允許遵循相同的規則集來配置用于hash tags 。

4.簡而言之，Redis集群

在Redis群集中，所有節點都持有全局密鑰集的某些部分（碎片或分區）。此外，每個節點都保持群集的狀態（包括hash slots映射），以便將客戶端重定向到給定密鑰的正確節點。 Redis集群中的所有節點還能夠自動發現其他節點，檢測不可達或無法按預期工作的節點，并在需要時執行從屬節點以進行主選舉。

至于在http://redis.io/topics/cluster-spec上描述的實現細節，則集群中的所有節點都使用帶有二進制協議的TCP（ cluster bus ）進行連接，以便每個節點都連接到該節點中的每個其他節點。使用cluster bus的cluster bus （這意味著在N個節點的Redis群集中，每個節點都具有N – 1個傳出TCP連接和N – 1個傳入TCP連接）。這些TCP連接始終保持活動狀態。節點使用八卦協議（ http://en.wikipedia.org/wiki/Gossip_protocol ）來傳播群集狀態，發現新節點，確保所有節點都正常工作以及在群集中傳播發布/訂閱消息。。

Redis群集中的每個節點都有唯一的ID（名稱）。節點ID（名稱）是160位隨機數的十六進制表示，是在節點第一次啟動時獲得的。節點會將其ID（名稱）保存在節點配置文件（默認為nodes.conf ）中，并將永久使用相同的ID（名稱）（或至少在不刪除節點配置文件的情況下）。

節點ID（名稱）用于標識整個Redis群集中的每個節點。給定節點可以更改其IP地址，而無需也更改其ID（名稱）。群集還能夠檢測IP或/和端口的更改，并使用在cluster bus運行的八卦協議廣播此信息。此外，每個節點還具有與之相關的其他信息，Redis群集中的所有其他節點都應知道以下信息：

節點所在的IP地址和TCP端口
一組標志（主，從，…）
節點服務的一組hash slots （請參閱分片（分區）方案）
上次使用群集總線發送ping數據包
上次收到pong數據包的答復
節點被標記為失敗的時間
該節點的從站數量
主節點ID（名稱）（如果此節點是從節點）（如果為主節點，則為零）

使用CLUSTER NODES命令可以使用某些信息（請參閱Redis Cluster Commands部分）。

5.一致性，可用性和可伸縮性

Redis Cluster是一個分布式系統。好的分布式系統具有可伸縮性，能夠大規模提供更好的性能。但是，在任何分布式系統中，任何組件都可能隨時發生故障，并且系統應提供某些保證以防萬一發生此類故障（尤其是如果它是數據存儲）。在本節中，我們將簡要介紹Redis在一致性，可用性和可伸縮性方面進行的一些高級權衡。可以在http://redis.io/topics/cluster-spec和http://redis.io/topics/cluster-tutorial中找到更深入的見解和詳細信息。請注意，Redis Cluster的發展非常Swift，本節中討論的某些保證可能不再成立。

5.1一致性

Redis Cluster無法保證強大的一致性，但會努力保留客戶端執行的所有寫入操作。不幸的是，這并不總是可能的。由于Redis Cluster在主節點和從節點之間使用異步復制，因此在網絡分區期間可能丟失寫操作時，總是會有時間窗口。如果主節點在沒有到達從節點的寫入的情況下死亡，則寫入將永遠丟失（以防主節點長時間無法訪問并且其從節點之一被提升為主節點）。

5.2可用性

Redis群集在網絡分區的少數部分不可用。在網絡分區的多數端（假設至少有多數主機和一個從屬設備用于每個無法訪問的主機），Redis群集仍然可用。這意味著Redis群集可以承受群集中幾個節點的故障，但不能承受大型網絡分區。對于示例，讓我們考慮具有N個主節點（ M1 ， M2 ， M3 ）和N個從屬節點（ S1 ， S2 ， S3 ，每個主節點都有一個從屬節點）的Redis集群。如果由于網絡分區而導致任何單個主節點無法訪問（假設我們為M2 ），則群集的大部分仍將保持可用狀態（并且S2將被提升為主節點）。稍后，如果其他任何主節點或從節點變得不可訪問（ S2除外），則群集仍將可用。但是請注意，如果節點S2由于某種原因發生故障，Redis Cluster將無法繼續運行（因為主M2和從屬S2都不可用）。

5.3可擴展性

從分片（分區）方案部分我們已經知道，Redis群集節點不會將命令轉發給給定密鑰的正確節點，而是重定向客戶端。客戶端最終獲得完整的映射，其中哪些節點為密鑰的哪個子集服務，并且可以直接與正確的節點聯系。因此，Redis Cluster能夠線性擴展（添加更多節點可帶來更好的性能），因為所有受支持的操作的處理方式與單個Redis實例完全相同，而沒有任何額外開銷。

6.安裝具有群集支持的Redis

Redis Cluster當前僅在不穩定版本中可用。撰寫本文時，最新的不穩定版本是3.0.0-beta1 ，可以從http://redis.io/download下載。請注意，僅提供Linux發行版，Windows端口尚不可用。

使用集群安裝Redis發行版與本教程的第1部分“ Redis安裝”中描述的常規Redis安裝沒有什么不同，并且遵循相同的步驟：

wget https://github.com/antirez/redis/archive/3.0.0-beta1.tar.gz tar xf 3.0.0-beta1.tar.gz cd redis-3.0.0-beta1/ make make test sudo make install

最后一步之后，通常的Redis可執行文件將安裝在/usr/local/bin文件夾中。

7.配置Redis集群

無法使用常規Redis實例和常規配置創建Redis群集。相反，應該在特殊的群集模式下運行幾個空的Redis實例。為此，應使用特定于集群的配置來運行實例（應在配置文件中將cluster-enabled指令設置為“ yes ”），以便啟用特定于集群的功能和命令。

運行某些具有群集模式支持的Redis實例所需的最少設置包括以下設置。

cluster-enabled 是（默認：否）
為該實例啟用Redis集群模式
cluster-config-file nodes.conf （默認值： nodes.conf ）
存儲此實例的配置的文件的路徑。該文件絕不應該被觸碰，它只是由Redis Cluster實例在啟動時生成，并在每次需要時進行更新（請參閱Nutshell中的Redis Clustering部分）
cluster-node-timeout 5000
故障檢測算法將超時（以毫秒為單位）之后無響應的實例視為發生故障。正如我們在分片（分區）方案部分中提到的那樣，我們將配置和運行一個具有三個Redis主節點（ master1 ， master2 ， master3 ）的實時Redis集群，每個節點由Redis從節點（ slave1 ， slave2 ， slave3 ）支持，如圖所示。下圖。

圖1. Redis集群拓撲

在此過程中，我們將探索大多數Redis集群功能，但在此之前，讓我們從主服務器和從服務器的配置開始。為了使配置足夠簡單，我們將從群集正常運行所需的最低限度的設置開始。

7.1配置Redis Cluster主節點

Redis主節點的最小配置如下所示：

Redis節點master1 （ redis-master1.conf ） port 6379cluster-enabled yescluster-config-file nodes.confcluster-node-timeout 5000appendonly yes
Redis節點master2 （ redis-master2.conf ） port 6380cluster-enabled yescluster-config-file nodes.confcluster-node-timeout 5000appendonly yes
Redis節點master3 （ redis-master3.conf ） port 6381cluster-enabled yescluster-config-file nodes.confcluster-node-timeout 5000appendonly yes

準備好配置文件后，我們可以將配置作為命令行參數，一一啟動Redis主節點。

redis服務器redis-master1.conf
圖2. Redis master1節點以集群模式運行
redis服務器redis-master2.conf
圖3. Redis master2節點以集群模式運行
redis服務器redis-master3.conf
圖4. Redis master3節點以集群模式運行

與獨立Redis實例的控制臺輸出相比，有兩個值得注意的區別：

啟動時，每個節點都會生成其unique ID （名稱），如我們在《 Nutshell中的Redis群集》中所討論的那樣，請注意，此值僅在第一次運行時生成，然后再使用
每個實例都以cluster mode運行
此外，對于每個正在運行的實例，都有一個使用當前node ID （ name ）和一些其他信息創建的nodes.conf文件。

目前，我們有三個Redis主節點以集群模式運行，但實際上尚未形成集群（每個Redis主節點僅看到自身，而其他節點則看不到）。為了驗證這一點，我們可以在每個實例上單獨運行CLUSTER NODES命令（請參閱Redis Cluster Commands部分），并觀察確實如此。

圖5.每個Redis主節點僅看到自己，而看不到其他

為了形成集群，應使用CLUSTER MEET命令將Redis節點（以集群模式運行）連接在一起（請參閱Redis集群命令部分）。不幸的是，該命令僅接受IP地址，但不接受主機名。在我們的拓撲master1具有IP地址192.168.1.105， master2擁有192.168.2.105和master3具有192.168.3.105。 具有IP地址，讓我們對master1節點發出命令。

圖6.發出CLUSTER MEET命令形成Redis集群

現在，如果我們重新運行CLUSTER NODES命令，結果應該會完全不同。

圖7a。在每個Redis主節點上重新運行CLUSTER NODES ，確認每個節點都可以看到所有其他節點（有效地形成了一個集群）。

圖7b。在每個Redis主節點上重新運行CLUSTER NODES ，確認每個節點都可以看到所有其他節點（有效地形成了一個集群）。

圖7c。在每個Redis主節點上重新運行CLUSTER NODES ，確認每個節點都可以看到所有其他節點（有效地形成了一個集群）。

CLUSTER NODES命令的輸出看起來有點晦澀難懂，需要一些解釋，每一列表示什么。

第1欄	Node ID （名稱）
第2欄	IP:port節點的IP:port
第三欄	標志：主人，奴隸，我自己，失敗 …
第4欄	如果是從站，則為主站的Node ID （名稱）
第5欄	上一個未決PING的時間仍在等待回復
第6欄	最后收到的PONG 時間
第7欄	此節點的配置時代（請參閱http://redis.io/topics/cluster-spec ）
第8欄	到該節點的鏈接狀態
第9欄	Hash slots

表格1

在輸出中未設置最后一列Hash Slots ，這是有原因的：我們尚未將hash slot分配給主節點，這就是我們現在要做的。可以通過在特定群集節點上使用CLUSTER ADDSLOTS （請參閱Redis Cluster Commands ）命令將Hash slots分配給節點（分別使用CLUSTER DELSLOTS分配）。不幸的是，不可能分配hash slot范圍（如0-5400），而應單獨分配每個hash slot （總數16384中 ）。克服此限制的最簡單方法之一是使用一些Shell腳本。由于集群中只有三個Redis主節點，因此可以這樣劃分16384個hash slots的范圍：

Redis節點master1包含hash slots 0 – 5400 for slot in {0..5400}; do redis-cli -h master1 -p 6379 CLUSTER ADDSLOTS $slot; done;
Redis節點master2包含hash slots 5401 – 10800 for slot in {5400..10800}; do redis-cli -h master2 -p 6380 CLUSTER ADDSLOTS $slot; done;
Redis節點master3包含hash slots 10801 – 16383 for slot in {10801..16383}; do redis-cli -h master3 -p 6381 CLUSTER ADDSLOTS $slot; done;

如果再次運行CLUSTER NODES命令，則最后一列將填充每個主節點服務的適當hash slots （與我們之前分配給節點的hash slot范圍完全匹配）。

圖8. CLUSTER NODES顯示每個主節點服務的hash slots

7.2配置Redis Cluster從節點和復制

為了使我們的Redis集群完整，我們需要向每個正在運行的Redis主節點添加恰好一個從節點。盡管本教程的第3部分“ Redis復制”足夠好地介紹了復制配置，但是Redis集群的做法有所不同。從一開始，運行和配置從站的過程與主站沒有什么不同（唯一的區別是端口號）。

Redis節點slave1 （ redis- slave1.conf ） port 7379cluster-enabled yescluster-config-file nodes.confcluster-node-timeout 5000appendonly yes
Redis節點slave2 （ redis-slave2.conf ） port 7380cluster-enabled yescluster-config-file nodes.confcluster-node-timeout 5000appendonly yes
Redis節點slave3 （ redis-slave3.conf ） port 7381cluster-enabled yescluster-config-file nodes.confcluster-node-timeout 5000appendonly yes

讓我們先啟動所有三個從屬實例，然后再啟動CLUSTER MEET命令，以便每個節點都將加入我們正在運行的Redis集群。

redis-server redis-slave1.conf redis-server redis-slave2.conf redis-server redis-slave3.conf

作為CLUSTER MEET需要IP地址，我們slave1具有IP地址192.168.4.105， slave2擁有192.168.5.105和slave3有192.168.6.105。

redis-cli -h master1 -p 6379 CLUSTER MEET 192.168.4.105 7379 redis-cli -h master1 -p 6379 CLUSTER MEET 192.168.5.105 7380 redis-cli -h master1 -p 6379 CLUSTER MEET 192.168.6.105 7381

和往常一樣，使用CLUSTER NODES命令，我們可以看到Redis集群中的當前節點（共有六個）。輸出顯示所有節點均為主節點。

圖9. CLUSTER NODES所有六個節點顯示為主節點

要配置復制，應通過提供主Node ID （名稱）在每個Redis從屬服務器上執行新的CLUSTER REPLICATE命令。下表總結了所有一起復制所需的部分（通過查詢CLUSTER NODES命令輸出的結果）。

主主持人	master1
主節點ID	3508ffe11ba5fbfbb93db5b21a413799272f5d0f
從節點	slave1
redis-cli -h slave1 -p 7379集群副本3508ffe11ba5fbfbb93db5b21a413799272f5d0f

表2

主主持人	master2
主節點ID	610976e1ca5382b96718cd7e261d3543e6a99af4
從節點	slave2
redis-cli -h slave2 -p 7380集群副本610976e1ca5382b96718cd7e261d3543e6a99af4

表3

主主持人	master3
主節點ID	d8a2ae6221624212b76d9cf6c1483452e3c26117
從節點	slave3
redis-cli -h slave3 -p 7381集群副本d8a2ae6221624212b76d9cf6c1483452e3c26117

表5

至此，我們的Redis集群已正確配置，并具有我們要創建的拓撲。 CLUSTER NODES命令顯示所有連接到主站的從站。

圖10. CLUSTER NODES顯示連接在一起的主節點和從節點

如我們所見，所有節點都是健康的，相互連接的，并且分配了正確的角色（主節點和從節點）。

7.3驗證Redis集群工作正常

與Redis一樣，確保Redis集群按預期工作的最佳方法是使用redis-cli發出一些命令。請注意，因為集群中的節點不代理命令，而是重定向客戶端（請參閱分片（分區）方案），所以客戶端必須支持這樣的協議，這就是為什么redis-cli應該與-c命令行選項一起運行（有集群支持）：

redis-cli -h master1 -p 6379 -c

讓我們嘗試設置存儲的鍵（使用SET命令），然后再查詢它們（使用GET命令）。因為我們在三個節點之間分配了hash slots ，所以密鑰也將分布在所有這些節點上。名稱為some-key的第一個密鑰存儲在我們連接到的master1節點本身上。

圖11.設置密鑰some-key將存儲在master1

但是，如果我們嘗試存儲名稱為some-another-key ，將會發生有趣的事情： redis-cli告訴我們該值將存儲在IP地址為192.168.3.105 （ master3 ）的節點上保留此鍵所屬的hash slot 。

圖12.設置一個鍵，另一個鍵將存儲在master3

請注意，命令執行后， redis-cli將自動重定向到節點192.168.3.105 （ master3 ）。一旦我們在群集節點192.168.3.105 （ master3 ）上，我們可以通過發出CLUSTER GETKEYSINSLOT命令來驗證hash slot確實包含密鑰some-another-key。

圖13.驗證hash slot 15929是否包含密鑰some-another-key

我們也可以驗證的Redis從節點slave3已復制的關鍵some-another-key從主（ master3 ），并返回其值。

圖14. Redis從屬服務器（ slave3 ）復制了主服務器（ master3 ）的密鑰

7.4在正在運行的Redis集群中添加和刪除節點

我們在分片（分區）方案部分中已經提到，Redis集群可以在不停機的情況下進行重新配置，并且通常涉及hash slots遷移。讓我們向集群添加另一個主節點master4 （IP地址為192.168.7.105 ）并將插槽15929從節點master3到master4 （這是包含密鑰some-another-key的hash slot ）。她是Redis節點master4 （ redis- master4.conf ）配置：

port 6384cluster-enabled yescluster-config-file nodes.confcluster-node-timeout 5000appendonly yesredis-server redis-master4.confredis-cli -h master1 -p 6379 CLUSTER MEET 192.168.7.105 6384

圖15. Redis master4已加入集群

遷移hash slots過程包括以下階段：

在擁有特定hash slot （ master3 ）的群集節點上，應執行命令CLUSTER SETSLOT slot MIGRATING ，其中是新節點master4的Node ID （即d8095be33a2b9d06affcb5583f7150b1341f4c96）。 redis-cli -h master3 -p 6381 CLUSTER SETSLOT 15929 MIGRATINGd8095be33a2b9d06affcb5583f7150b1341f4c96
當某個插槽標記為MIGRATING ，該節點將接受所有有關此hash slot查詢請求，但前提是給定鍵存在，否則該查詢將轉發到作為遷移目標的節點。
在應成為特定hash slot （ master4 ）的新所有者的群集節點上，命令CLUSTER SETSLOT slot IMPORTING ，其中是當前所有者master3的Node ID （即d8a2ae6221624212b76d9cf6c1483452e3c26117）。 redis-cli -h master4 -p 6384 CLUSTER SETSLOT 15929 IMPORTINGd8a2ae6221624212b76d9cf6c1483452e3c26117
此時，應使用MIGRATE命令（請參閱http://redis.io/commands/migrate ）將hash slot所有密鑰從當前所有者master3到新所有者master4 。因為只有一把鑰匙，所以很容易。 redis-cli -h master3 -p 6381 MIGRATE master4 6384 some-another-key 0 0
最后，當hash slot變為空時（可以通過發出CLUSTER GETKEYSINSLOT命令進行驗證），可以將其分配給新節點（ master4 ）。 redis-cli -h master3 -p 6381 CLUSTER SETSLOT 15929 NODEd8095be33a2b9d06affcb5583f7150b1341f4c96

盡管了解詳細情況非常有用，但是手動執行這樣的過程非常困難且容易出錯。但是Redis Cluster軟件包提供了一個方便的實用程序，稱為redis-trib ，位于Redis發行版的src文件夾中。它是用Ruby編寫的，通過簡化Redis集群的管理可能會很有幫助（有關更多詳細信息，請參見http://redis.io/topics/cluster-tutorial ）。

8. Redis集群命令

Redis Cluster添加了另外一組專用于集群管理，監視和配置的命令。在本教程的第2部分“ Redis命令”中沒有涉及這些命令，因為它們在穩定版本中尚不可用。另外，Redis網站上沒有足夠的文檔，但是至少我們可以簡要描述每個命令（您已經在實際操作中看到了許多命令）。

命令	CLUSTER SETSLOT插槽NODE <node-id>
描述	將hash slot分配給節點。該命令應在擁有此hash slot的節點上發出，并且hash slot不應包含任何鍵（應為空）。

表6

命令	集群SETSLOT插槽IMPORTING <node-id>
描述	將hash slot標記為從<node-id>導入。 <node-id>應該是此hash slot的所有者。

表7

命令	集群SETSLOT插槽MIGRATING <node-id>
描述	將hash slots標記為正在遷移到<node-id>。該命令應在擁有此hash slot的節點上發出。

表8

命令	集群節點
描述	顯示Redis集群中的當前節點集。

表9

命令	集群ADDSLOTS slot1 [slot2]…[slotN]
描述	將hash slots分配給Redis節點。

表10

命令	集群DELSLOTS slot1 [slot2]…[slotN]
描述	從Redis節點刪除hash slots分配。

表11

命令	群集會議IP端口
描述	將節點添加到Redis集群。

表12

命令	集群獲取<node-id>
描述	從Redis集群中刪除節點。

表13

命令	集群復制<master-node-id>
描述	使該節點成為主節點<master-node-id>的副本。

表14

命令	集群GETKEYSINSLOT插槽數
描述	從任何特定的鍵返回名稱hash slot限制輸出來計算密鑰數量。如果執行此命令的節點不是slot的所有者，則該命令不返回任何結果。

表15

9. Redis前哨

Redis的另一個偉大但仍具有實驗性的功能是Redis Sentinel 。該系統旨在幫助管理實時Redis實例，并牢記以下目標：

監視：Sentinel不斷檢查您的主實例和從實例是否按預期工作
通知：Sentinel能夠通知受監視的Redis實例之一是否有問題
自動故障轉移 ：如果某些主節點未按預期工作，則Sentinel可以啟動故障轉移過程，將其中一個從屬節點升級為主節點

Redis Sentinel是一個非常有前途的功能，但目前正在Redis源代碼的不穩定分支中進行開發。它不是Redis發行版的一部分。

有關更多詳細信息，請參見http://redis.io/topics/sentinel 。

10.下一步是什么

在本節中，我們介紹了Redis群集的一個非常吸引人且要求很高的功能。即使仍在開發中，該功能也足夠穩定，可以開始使用它。在本教程的下一部分中，我們將介紹用于在不同部署方案中訪問Redis的編程Java API。

翻譯自: https://www.javacodegeeks.com/2015/09/redis-clustering.html