溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》
您好，登錄后才能下訂單哦！
今天就跟大家聊聊有關(guān)怎么在Docker中部署一個Redis 6.x集群，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。
Redis 版本：6.0.8
Docker 版本：19.03.12
系統(tǒng)版本：CoreOS 7.8
內(nèi)核版本：5.8.5-1.el7.elrepo.x86_64
在 Redis 3.0 版本后正式推出 Redis 集群模式，該模式是 Redis 的分布式的解決方案，是一個提供在多個 Redis 節(jié)點間共享數(shù)據(jù)的程序集，且 Redis 集群是去中心化的，它的每個 Master 節(jié)點都可以進行讀寫數(shù)據(jù)，每個節(jié)點都擁有平等的關(guān)系，每個節(jié)點都保持各自的數(shù)據(jù)和整個集群的狀態(tài)。
Redis 集群設(shè)計的主要目的是讓 Redis 數(shù)據(jù)存儲能夠線性擴展，通過分區(qū)來提供一定程度的可用性，在實際環(huán)境中當(dāng)某個節(jié)點宕機或者不可達的情況下其可以繼續(xù)處理命令。但是，如果發(fā)生較大故障（例如，大多數(shù)主站不可用時）時集群會停止運行，即 redis 集群不能保證數(shù)據(jù)的強一致性。
高可用性： Redis 在集群模式下每個 Master 都是主從復(fù)制模式，其 Master 節(jié)點上的數(shù)據(jù)會實時同步到 Slave 節(jié)點上，當(dāng) Master 節(jié)點不可用時，其對應(yīng)的 Slave 節(jié)點身份會更改為 Master 節(jié)點，保證集群的可用性。
數(shù)據(jù)橫向擴展： Redis 是一個內(nèi)存數(shù)據(jù)庫，所有數(shù)據(jù)都存在內(nèi)存中，在單節(jié)點中所在服務(wù)器能給與的內(nèi)存是有一定限制。當(dāng)數(shù)據(jù)量達到一定程度后，內(nèi)存將不足以支撐這么多的數(shù)據(jù)存儲，這時候需要將數(shù)據(jù)進行分片存儲，而 Redis 集群模式就是將數(shù)據(jù)分片存儲，非常方便橫向擴展。
Redis 集群沒有使用一致性 Hash, 而是引入了”哈希槽”的概念。Redis 集群有 16384 個哈希槽，每個 key 通過 CRC16 校驗后對 16384 取模來決定放置哪個槽，集群的每個節(jié)點負責(zé)一部分 hash 槽。
舉個例子，比如當(dāng)前集群有3個節(jié)點，那么:
節(jié)點 A 包含 0 到 5460 號哈希槽；
節(jié)點 B 包含 5461 到 10922 號哈希槽；
節(jié)點 C 包含 10923 到 16383 號哈希槽；
這種結(jié)構(gòu)很容易”添加”或者”刪除”節(jié)點. 比如如果我想新添加個節(jié)點 D，我需要從節(jié)點 A, B, C 中得部分槽轉(zhuǎn)移到節(jié)點 D 上， 如果我想移除節(jié)點 A，則需要將 A 中的槽移到 B 和 C 節(jié)點上，然后將沒有任何槽的 A 節(jié)點從集群中移除即可。由于從一個節(jié)點將哈希槽移動到另一個節(jié)點并不會停止服務(wù)，所以無論添加刪除或者改變某個節(jié)點的哈希槽的數(shù)量都不會造成集群不可用的狀態(tài)。
Redis 支持多個 key 操作，只要這些 key 在一個單個命令中執(zhí)行（或者一個事務(wù)，或者 Lua 腳本執(zhí)行），那么它們就屬于相同的 Hash 槽。你也可以用 hash tags 命令強制多個 key 都在相同的 hash 槽中。
集群中的主從模型
在 Redis 集群模式下，為了防止集群部分節(jié)點因宕機等情況造成不可用，故而 Redis 集群使用了主從復(fù)制模式。在該模式下要求 Redis 集群至少要存在六個節(jié)點，其中三個節(jié)點為主節(jié)點，能夠?qū)ν馓峁┳x寫。還有三個節(jié)點為從節(jié)點，會同步其對應(yīng)的主節(jié)點的數(shù)據(jù)。當(dāng)某個主節(jié)點出現(xiàn)問題不可用時，Redis 將通過選舉算法從主節(jié)點對應(yīng)的從節(jié)點中選擇一個節(jié)點（主節(jié)點存在多個從節(jié)點的情況下），將其更改為一個新的主節(jié)點，且能夠?qū)ν馓峁┓?wù)。
例如，在存在 A，B，C 三個主節(jié)點和其對應(yīng)的 （A1、A2），（B1、B2），（C1、C2） 六個從節(jié)點，共九個節(jié)點中，如果節(jié)點 A 節(jié)點掛掉，那么其對應(yīng)的從節(jié)點 A1、A2 節(jié)點將通過選舉算法，選擇其中一個節(jié)點提升為主節(jié)點，以確保集群能夠正常服務(wù)。不過當(dāng) A1、A2 兩個從節(jié)點或者或者半數(shù)以上主節(jié)點不可用時，那么集群也是不可用的。
在部署 Redis 集群模式時，至少需要六個節(jié)點組成集群才能保證集群的可用性。
(1)、全量復(fù)制與增量復(fù)制
在 Redis 主從復(fù)制中，分為”全量復(fù)制”和”增量復(fù)制”兩種數(shù)據(jù)同步方式：
全量復(fù)制： 用于初次復(fù)制或其它無法進行部分復(fù)制的情況，將主節(jié)點中的所有數(shù)據(jù)都發(fā)送給從節(jié)點。當(dāng)數(shù)據(jù)量過大的時候，會造成很大的網(wǎng)絡(luò)開銷。
增量復(fù)制： 用于處理在主從復(fù)制中因網(wǎng)絡(luò)閃退等原因造成數(shù)據(jù)丟失場景，當(dāng)從節(jié)點再次連上主節(jié)點，如果條件允許，主節(jié)點會補發(fā)丟失數(shù)據(jù)給從節(jié)點，因為補發(fā)的數(shù)據(jù)遠遠小于全量數(shù)據(jù)，可以有效避免全量復(fù)制的過高開銷。但需要注意，如果網(wǎng)絡(luò)中斷時間過長，造成主節(jié)點沒有能夠完整地保存中斷期間執(zhí)行的寫命令，則無法進行部分復(fù)制，仍使用全量復(fù)制。
(2)、記錄復(fù)制位置的偏移量
參與復(fù)制的主從節(jié)點都會維護自身復(fù)制偏移量，主節(jié)點在處理完寫入命令操作后，會把命令的字節(jié)長度做累加記錄，可以使用 info replication 命令查詢 master_repl_offset 偏移量信息。
從節(jié)點每秒鐘上報自身的復(fù)制偏移量給主節(jié)點，因此主節(jié)點也會保存從節(jié)點的復(fù)制偏移量。
從節(jié)點在接收到主節(jié)點發(fā)送的命令后，也會累加記錄自身的偏移量，可以使用 info replication 命令查詢 slave_repl_offset 偏移量信息。
(3)、復(fù)制積壓緩沖區(qū)
復(fù)制積壓緩沖區(qū)（backlog）是保存在主節(jié)點上的一個固定長度的隊列，默認大小為 1MB，當(dāng)主節(jié)點有連接的從節(jié)點時被創(chuàng)建，這時主節(jié)點響應(yīng)寫命令時，不但會把命令發(fā)給從節(jié)點，還會寫入復(fù)制積壓緩沖區(qū)，作為寫命令的備份。
除了存儲寫命令，復(fù)制積壓緩沖區(qū)中還存儲了其中的每個字節(jié)對應(yīng)的復(fù)制偏移量（offset） 。由于復(fù)制積壓緩沖區(qū)定長且先進先出，所以它保存的是主節(jié)點最近執(zhí)行的寫命令，時間較早的寫命令會被擠出緩沖區(qū)。
(4)、節(jié)點運行的 ID
每個 Redis 節(jié)點啟動后都會動態(tài)分配一個 40 位的十六進制字符串為運行 ID。運行 ID 的主要作用是來唯一識別 Redis 節(jié)點，比如，從節(jié)點保存主節(jié)點的運行 ID 識別自已正在復(fù)制是哪個主節(jié)點。如果只使用 IP + Port 的方式識別主節(jié)點，那么主節(jié)點重啟變更了整體數(shù)據(jù)集（如替換 RDB/AOF 文件），從節(jié)點再基于偏移量復(fù)制數(shù)據(jù)將是不安全的，因此當(dāng)運行 ID 變化后從節(jié)點將做全量復(fù)制?？梢栽?info server 命令查看當(dāng)前節(jié)點的運行 ID。
需要注意的是 Redis 關(guān)閉再啟動，運行的 ID 會隨之變化。
(1)、psync 命令
從節(jié)點使用 psync 從主節(jié)點獲取 runid 與 offset。
主節(jié)點會根據(jù)自身情況返回響應(yīng)信息，可能是 FULLRESYNC runid offset 觸發(fā)全量復(fù)制，可能是 CONTINUE 觸發(fā)增量復(fù)制。
(2)、psync 觸發(fā)全量復(fù)制
從節(jié)點使用 psync 命令完成部分復(fù)制和全量復(fù)制功能：
當(dāng)從節(jié)點第一次連接主節(jié)點時候，執(zhí)行全量復(fù)制：
① Slave 節(jié)點發(fā)送 psync? - 1 命令，表示要求 Master 執(zhí)行數(shù)據(jù)同步；
② Master 檢測到?jīng)]有 offset ，是第一次執(zhí)行復(fù)制，執(zhí)行全量復(fù)制，就發(fā)送 FULLRESYNC {runid} {offset} 命令，將 runid 和 offset 發(fā)送到 slave 節(jié)點。
③ Slave 節(jié)點保存 Master 節(jié)點傳遞的 runid 與 offset 信息。
④ Master 節(jié)點執(zhí)行 bgsave 生成 RBD 快照文件，并使用緩沖區(qū)記錄從現(xiàn)在開始執(zhí)行的全部命令。
⑤ Master 節(jié)點發(fā)送 RBD 文件到 Slave 節(jié)點。
⑥ Master 節(jié)點發(fā)送 BUFFER 緩存區(qū)記錄的寫命令到 Slave 節(jié)點。
⑦ Slave 節(jié)點清空舊數(shù)據(jù)。
⑧ Slave 節(jié)點載入 Master 節(jié)點傳入的 RBD 文件。
(2)、psync 觸發(fā)增量復(fù)制
當(dāng)從節(jié)點與主節(jié)點發(fā)送中斷后，從節(jié)點會重新連接主節(jié)點，這時會觸發(fā)增量復(fù)制，過程如下：
① Slave 節(jié)點使用 psync 發(fā)送 runid 和 offset 值。
② Master 節(jié)點驗證 Slave 節(jié)點發(fā)送的 runid 是否和自己相同：
不相同： 不相同則執(zhí)行全量復(fù)制；
相同： 則還需要驗證緩存區(qū)中是否存在對應(yīng)的 offset，如果不存在就執(zhí)行全量復(fù)制，否則執(zhí)行增量復(fù)制；
③ 滿足存在對應(yīng) offset 這個條件后，則驗證緩存區(qū)中的 offset 值是否和 Slave 節(jié)點發(fā)送的 offset 相同：
相同： 返回 offset 值相同，不進行復(fù)制操作；
不相同： 發(fā)送 CONTINUE offset 命令（注意：這里的 offset 是 Master 節(jié)點緩存區(qū)記錄的 offset 值，不是 Slave 節(jié)點傳遞的 offset 值）；
④ Master 節(jié)點從復(fù)制緩存區(qū)拷貝數(shù)據(jù)，從 Slave 節(jié)點發(fā)送的 offset 開始，到 Master 節(jié)點緩存區(qū)記錄的 offset 結(jié)束，將這個范圍內(nèi)的數(shù)據(jù)給 Slave 節(jié)點。
Redis 在官方文檔中提及，其并不能保證數(shù)據(jù)的強一致性，即 Redis 集群在特定的條件下寫入的數(shù)據(jù)可能會丟失，主要原因是因為 Redis 集群使用了異步復(fù)制模式，其寫入的操作過程如下：
執(zhí)行順序如下：
① 客戶端向任意一臺主節(jié)點寫入一條命令；
② 主節(jié)點對向客戶端回復(fù)命令執(zhí)行的狀態(tài)；
③ 主節(jié)點將寫操作命令傳遞給他的從節(jié)點；
Redis 集群對性能和一致性之間做出權(quán)衡，設(shè)置主節(jié)點在接收到客戶端寫命令后再將執(zhí)行的命令發(fā)送到各個從節(jié)點進行同步，這個過程是異步操作，且主節(jié)點不會等待從節(jié)點回復(fù)信息就立即回復(fù)客戶端命令的執(zhí)行狀態(tài)。這樣減少同步操作，可以很大提高系統(tǒng)的執(zhí)行速度，避免等待從節(jié)點回復(fù)消息這個過程成為系統(tǒng)性能的瓶頸。
然而，因為主節(jié)點不等待從節(jié)點收到信息后進行回復(fù)，就將命令的執(zhí)行狀態(tài)回復(fù)給了客戶端，那么在節(jié)點出現(xiàn)問題時很可能導(dǎo)致出現(xiàn)數(shù)據(jù)丟失問題，比如客戶端向主節(jié)點發(fā)送一條命令，然后主節(jié)點將該命令異步發(fā)送到它的從節(jié)點進行數(shù)據(jù)備份，然后立即回復(fù)客戶端命令的執(zhí)行狀態(tài)。如果在這個過程中，主節(jié)點出現(xiàn)問導(dǎo)致宕機，且從節(jié)點在處理主節(jié)點發(fā)送過來的同步數(shù)據(jù)時，也發(fā)生錯誤。這時正好趕上主節(jié)點宕機等不可用情況，那么從節(jié)點將轉(zhuǎn)換為新的主節(jié)點，在之前主節(jié)點執(zhí)行的命令將丟失。
在 Redis 集群中，數(shù)據(jù)節(jié)點提供兩個 TCP 端口，在配置防火墻時需要同時開啟下面兩類端口：
普通端口： 即客戶端訪問端口，如默認的 6379；
集群端口： 普通端口號加 10000，如 6379 的集群端口為 16379，用于集群節(jié)點之間的通訊；
集群的節(jié)點之間通訊采用 Gossip 協(xié)議，節(jié)點根據(jù)固定頻率(每秒10次)定時任務(wù)進行判斷，當(dāng)集群狀態(tài)發(fā)生變化，如增刪節(jié)點、槽狀態(tài)變更時，會通過節(jié)點間通訊同步集群狀態(tài)，使集群收斂。集群間發(fā)送的 Gossip 消息有下面五種消息類型：
MEET： 在節(jié)點握手階段，對新加入的節(jié)點發(fā)送 meet 消息，請求新節(jié)點加入當(dāng)前集群，新節(jié)點收到消息會回復(fù) pong 消息；
PING： 節(jié)點之間互相發(fā)送 ping 消息，收到消息的會回復(fù) pong 消息。ping 消息內(nèi)容包含本節(jié)點和其他節(jié)點的狀態(tài)信息，以此達到狀態(tài)同步；
PONG： pong 消息包含自身的狀態(tài)數(shù)據(jù)，在接收到 ping 或 meet 消息時會回復(fù) pong 消息，也會主動向集群廣播 pong 消息；
FAIL： 當(dāng)一個主節(jié)點判斷另一個主節(jié)點進入 fail 狀態(tài)時，會向集群廣播這個消息，接收到的節(jié)點會保存該消息并對該 fail 節(jié)點做狀態(tài)判斷；
PUBLISH： 當(dāng)節(jié)點收到 publish 命令時，會先執(zhí)行命令，然后向集群廣播 publish 消息，接收到消息的節(jié)點也會執(zhí)行 publish 命令；
在 Redis 集群模式下也不可能百分百保證集群可用性，當(dāng)發(fā)生不可預(yù)知的事件導(dǎo)致 Redis 集群將進入失敗狀態(tài)，在這種狀態(tài)下 Redis 集群將不能正常提供服務(wù)。其中進入失敗狀態(tài)的條件主要為：
① 全部節(jié)點都宕機，集群將進入 fail 狀態(tài)；
② 半數(shù)以上主節(jié)點不可用，集群將進入 fail 狀態(tài)；
③ 任意主節(jié)點掛掉，且該主節(jié)點沒有對應(yīng)的從節(jié)點或者從節(jié)點也全部掛掉，集群將進入 fail 狀態(tài)；
Redis 集群重新分片（新增/移除節(jié)點）機制：
新增節(jié)點：別的節(jié)點上的槽分一些出來給新的節(jié)點
刪除節(jié)點：刪除節(jié)點的槽分給別的節(jié)點
但這些操作是需要手動完成的，可以在不停止服務(wù)器的情況下執(zhí)行。
復(fù)制結(jié)構(gòu)只支持單層結(jié)構(gòu)，不支持樹型結(jié)構(gòu)。
不支持多數(shù)據(jù)庫，只能使用 0 數(shù)據(jù)庫，執(zhí)行 select 0 命令；
鍵是數(shù)據(jù)分區(qū)的最小粒度，不能將一個很大的鍵值對映射到不同的節(jié)點；
鍵事務(wù)支持有限，當(dāng)多個鍵分布在不同節(jié)點時無法使用事務(wù)，同一節(jié)點才能支持事務(wù)；
鍵的批量操作支持有限，比如 mset, mget 命令，如果多個鍵映射在不同的槽中，就不能正常使用這些命令了；
我們即將創(chuàng)建一個示例集群部署。在繼續(xù)之前，讓我們介紹Redis Cluster在redis.conf文件中引入的配置參數(shù)。
cluster-config-file： 設(shè)置 Redis 集群配置信息及狀態(tài)的存儲位置，該文件由 Redis 集群生成，我們只能指定其存儲的位置。
cluster-node-timeout： 設(shè)置 Redis 群集節(jié)點的通信的超時時間；
cluster-migration-barrier： 主節(jié)點需要的最小從節(jié)點數(shù)，只有達到這個數(shù)，主節(jié)點失敗時，它從節(jié)點才會進行遷移。
cluster-enabled： 是否開啟 Redis 集群模式。
yes：啟用 Redis 群集；
no：不啟用集群模式；
cluster-require-full-coverage： 設(shè)置集群可用性。
yes：表示當(dāng)負責(zé)一個插槽的主庫下線，且沒有相應(yīng)的從庫進行故障恢復(fù)時，集群不可用，下面論證該情況。
no：表示當(dāng)負責(zé)一個插槽的主庫下線且沒有相應(yīng)的從庫進行故障恢復(fù)時，集群仍然可用，下面論證該情況。
cluster-slave-validity-factor：
0：則無論從節(jié)點與主節(jié)點失聯(lián)多久，從節(jié)點都會嘗試升級成主節(jié)點。
正數(shù)：則 cluster-node-timeout * cluster-slave-validity-factor 得到的時間，是從節(jié)點與主節(jié)點失聯(lián)后，此從節(jié)點數(shù)據(jù)有效的最長時間，超過這個時間，從節(jié)點不會啟動故障遷移。假設(shè) cluster-node-timeout=5，cluster-slave-validity-factor=10，則如果從節(jié)點跟主節(jié)點失聯(lián)超過50秒，此從節(jié)點不能成為主節(jié)點。
這里對待部署的 Redis 集群的節(jié)點進行分配，將其部署到不同的機器上，安排如下：
提前創(chuàng)建好用于存儲 Redis 的配置文件和持久化數(shù)據(jù)的目錄：
第一臺服務(wù)器 192.168.2.11 中執(zhí)行創(chuàng)建存儲目錄命令：
$ mkdir -p /var/lib/redis/7000 & mkdir -p /var/lib/redis/7003
第二臺服務(wù)器 192.168.2.12 中執(zhí)行創(chuàng)建存儲目錄命令：
$ mkdir -p /var/lib/redis/7001 & mkdir -p /var/lib/redis/7004
第三臺服務(wù)器 192.168.2.13 中執(zhí)行創(chuàng)建存儲目錄命令：
$ mkdir -p /var/lib/redis/7002 & mkdir -p /var/lib/redis/7005
第一臺服務(wù)器 192.168.2.11 配置文件：
## 7000 端口配置文件 $ cat > /var/lib/redis/7000/redis.conf << EOF port 7000 cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 5000 appendonly yes daemonize no protected-mode no pidfile /data/redis.pid EOF ## 7003 端口配置文件 $ cat > /var/lib/redis/7003/redis.conf << EOF port 7003 cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 5000 appendonly yes daemonize no protected-mode no pidfile /data/redis.pid EOF
第二臺服務(wù)器 192.168.2.12 配置文件
## 7001 端口配置：redis.conf $ cat > /var/lib/redis/7001/redis.conf << EOF port 7001 cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 5000 appendonly yes daemonize no protected-mode no pidfile /data/redis.pid EOF ## 7004 端口配置：redis-7004.conf $ cat > /var/lib/redis/7004/redis.conf << EOF port 7004 cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 5000 appendonly yes daemonize no protected-mode no pidfile /data/redis.pid EOF
第三臺服務(wù)器 192.168.2.13 配置文件
## 7002 端口配置：redis-7002.conf $ cat > /var/lib/redis/7002/redis.conf << EOF port 7002 cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 5000 appendonly yes daemonize no protected-mode no pidfile /data/redis.pid EOF ## 7005 端口配置：redis-7005.conf $ cat > /var/lib/redis/7005/redis.conf << EOF port 7005 cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 5000 appendonly yes daemonize no protected-mode no pidfile /data/redis.pid EOF
三臺服務(wù)器中提前拉取 Redis 鏡像，避免在執(zhí)行運行時候還得拉取鏡像，導(dǎo)致運行慢。
$ docker pull redis:6.0.8
三臺服務(wù)器分別執(zhí)行 Docker 運行命令來啟動 Redis 鏡像。這里需要注意的是，不同服務(wù)器間的 Docker 是不能相互通信的，所有這里我們設(shè)置啟動的容器網(wǎng)絡(luò)模式為 host 模式，這樣容器不會創(chuàng)建虛擬網(wǎng)卡，而是使用宿主機的網(wǎng)絡(luò)。
-d：設(shè)置容器后臺運行；
-v：指定掛載的宿主機存儲目錄；
--name：指定運行后的容器名稱；
--cpus：指定容器使用 CPU 數(shù)量；
--memory：限制容器使用內(nèi)存數(shù)量；
--memory-swap：指定交換內(nèi)存大小，這里設(shè)置為 0，即不用交換內(nèi)存；
--net：指定 Docker 使用的網(wǎng)絡(luò)模式；
--restart：指定 Docker 重啟時容器的重啟策略；
--privileged：設(shè)置容器擁有特權(quán)，能夠獲取宿主機 Root 權(quán)限；
第一臺服務(wù)器 192.168.2.11 執(zhí)行如下命令
## 運行 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
第二臺服務(wù)器 192.168.2.12 執(zhí)行如下命令
## 運行 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
第三臺服務(wù)器 192.168.2.13 執(zhí)行如下命令：
## 運行 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.conf
隨意進入一臺服務(wù)器，使用 Redis 鏡像的 redis-cli 工具執(zhí)行創(chuàng)建集群命令使各個 Redis 組成集群，這里本人進入第一臺服務(wù)器 192.168.2.11 中，使用端口為 7000 的 Redis 端鏡像，可以執(zhí)行下面命令：
-p：指定連接 Redis 的端口；
create：創(chuàng)建 Redis 集群；
--cluster：使用 Redis 集群模式命令；
--cluster-replicas：指定副本數(shù)（slave 數(shù)量）；
$ 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 - 5460 Master[1] -> Slots 5461 - 10922 Master[2] -> Slots 10923 - 16383 Adding replica 192.168.2.12:7004 to 192.168.2.11:7000 Adding replica 192.168.2.13:7005 to 192.168.2.12:7001 Adding replica 192.168.2.11:7003 to 192.168.2.13:7002 M: 5e50824c55d4df42db4d2987796f0c0b468c273f 192.168.2.11:7000 slots:[0-5460] (5461 slots) master M: 36565e0273fd62921aa1f2d85c5f7ac98a5b9466 192.168.2.12:7001 slots:[5461-10922] (5462 slots) master M: 0cc1aaf960defae7332e9256dd25ee5e5c99e65f 192.168.2.13:7002 slots:[10923-16383] (5461 slots) master S: 42d6e3979395ba93cd1352b6d17044f6b25d9379 192.168.2.11:7003 replicates 0cc1aaf960defae7332e9256dd25ee5e5c99e65f S: ac5d34b57a8f73dabc60d3a56469055ec64fcde7 192.168.2.12:7004 replicates 5e50824c55d4df42db4d2987796f0c0b468c273f S: 470b7ff823f10a309fb07311097456210506f6d8 192.168.2.13:7005 replicates 36565e0273fd62921aa1f2d85c5f7ac98a5b9466 Can 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 cluster Waiting 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 36565e0273fd62921aa1f2d85c5f7ac98a5b9466 S: 42d6e3979395ba93cd1352b6d17044f6b25d9379 192.168.2.11:7003 slots: (0 slots) slave replicates 0cc1aaf960defae7332e9256dd25ee5e5c99e65f S: ac5d34b57a8f73dabc60d3a56469055ec64fcde7 192.168.2.12:7004 slots: (0 slots) slave replicates 5e50824c55d4df42db4d2987796f0c0b468c273f M: 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.
進入 Redis 鏡像內(nèi)部并折傭 redis-cli 命令：
-p：指定連接 Redis 的端點；
-c：使用集群模式；
$ docker exec -it redis-7000 redis-cli -p 7000 -c
查看集群信息：
> 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:1 cluster_stats_messages_ping_sent:866 cluster_stats_messages_pong_sent:854 cluster_stats_messages_sent:1720 cluster_stats_messages_ping_received:849 cluster_stats_messages_pong_received:866 cluster_stats_messages_meet_received:5 cluster_stats_messages_received:1720
查看集群節(jié)點信息：
> cluster nodes 470b7ff823f10a309fb07311097456210506f6d8 192.168.2.13:7005@17005 slave 36565e0273fd62921aa1f2d85c5f7ac98a5b9466 0 1600267217000 2 connected 42d6e3979395ba93cd1352b6d17044f6b25d9379 192.168.2.11:7003@17003 slave 0cc1aaf960defae7332e9256dd25ee5e5c99e65f 0 1600267218171 3 connected ac5d34b57a8f73dabc60d3a56469055ec64fcde7 192.168.2.12:7004@17004 slave 5e50824c55d4df42db4d2987796f0c0b468c273f 0 1600267216161 1 connected 0cc1aaf960defae7332e9256dd25ee5e5c99e65f 192.168.2.13:7002@17002 master - 0 1600267218070 3 connected 10923-16383 36565e0273fd62921aa1f2d85c5f7ac98a5b9466 192.168.2.12:7001@17001 master - 0 1600267217163 2 connected 5461-10922 5e50824c55d4df42db4d2987796f0c0b468c273f 192.168.2.11:7000@17000 myself,master - 0 1600267217000 1 connected 0-5460
看完上述內(nèi)容，你們對怎么在Docker中部署一個Redis 6.x集群有進一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。
免責(zé)聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點不代表本網(wǎng)站立場，如果涉及侵權(quán)請聯(lián)系站長郵箱：is@yisu.com進行舉報，并提供相關(guān)證據(jù)，一經(jīng)查實，將立刻刪除涉嫌侵權(quán)內(nèi)容。
億速云公眾號
手機網(wǎng)站二維碼
