CentOS7下安装Redis伪集群（基于Redis官方Cluster集群模式版本redis-5.0.10）
文章目錄
- Redis簡介
- 什么是redis
- redis的優(yōu)點(diǎn)
- Redis集群都有哪些模式
- 主從復(fù)制（Master-Slave Replication）
- 哨兵模式（Sentinel）
- Redis官方 Cluster集群模式（本文使用）
- Jedis sharding集群(客戶端sharding)
- 利用中間件代理
- Redis集群安裝（偽集群）
- 偽集群說明
- 去中心化
- 內(nèi)部中也需要配置主從
- 部署節(jié)點(diǎn)要求
- 偽集群搭建
- 創(chuàng)建目錄并下載Redis安裝包
- 修改redis.conf
- 啟動(dòng)所有節(jié)點(diǎn)
- 創(chuàng)建集群
- 測(cè)試
- 驗(yàn)證故障轉(zhuǎn)移
Redis簡介
什么是redis
REmote DIctionary Server(Redis) 是一個(gè)由Salvatore Sanfilippo寫的key-value存儲(chǔ)系統(tǒng)。
Redis是一個(gè)開源的使用ANSI C語言編寫、遵守BSD協(xié)議、支持網(wǎng)絡(luò)、可基于內(nèi)存亦可持久化的日志型、Key-Value數(shù)據(jù)庫，并提供多種語言的API。
它通常被稱為數(shù)據(jù)結(jié)構(gòu)服務(wù)器，因?yàn)橹?#xff08;value）可以是 字符串(String), 哈希(Map), 列表(list), 集合(sets) 和 有序集合(sorted sets)等類型。
reids的優(yōu)點(diǎn)
redis的優(yōu)點(diǎn)
以下是Redis的一些優(yōu)點(diǎn)。
異常快 - Redis非常快，每秒可執(zhí)行大約110000次的設(shè)置(SET)操作，每秒大約可執(zhí)行81000次的讀取/獲取(GET)操作。
支持豐富的數(shù)據(jù)類型 - Redis支持開發(fā)人員常用的大多數(shù)數(shù)據(jù)類型，例如列表，集合，排序集和散列等等。這使得Redis很容易被用來解決各種問題，因?yàn)槲覀冎滥男﹩栴}可以更好使用地哪些數(shù)據(jù)類型來處理解決。
操作具有原子性 - 所有Redis操作都是原子操作，這確保如果兩個(gè)客戶端并發(fā)訪問，Redis服務(wù)器能接收更新的值。
多實(shí)用工具 - Redis是一個(gè)多實(shí)用工具，可用于多種用例，如：緩存，消息隊(duì)列(Redis本地支持發(fā)布/訂閱)，應(yīng)用程序中的任何短期數(shù)據(jù)，例如，web應(yīng)用程序中的會(huì)話，網(wǎng)頁命中計(jì)數(shù)等。
Redis集群都有哪些模式
Redis主流的模式有以下幾種：
1、主從復(fù)制
2、哨兵模式
3、Redis官方提供的Cluster集群模式(服務(wù)端)
4、Jedis sharding集群(客戶端sharding)
5、利用中間件代理，比如codis等
主從復(fù)制（Master-Slave Replication）
主從復(fù)制（Master-Slave Replication）的工作原理：Slave從節(jié)點(diǎn)服務(wù)啟動(dòng)并連接到Master之后，它將主動(dòng)發(fā)送一個(gè)SYNC命令。Master服務(wù)主節(jié)點(diǎn)收到同步命令后將啟動(dòng)后臺(tái)存盤進(jìn)程，同時(shí)收集所有接收到的用于修改數(shù)據(jù)集的命令，在后臺(tái)進(jìn)程執(zhí)行完畢后，Master將傳送整個(gè)數(shù)據(jù)庫文件到Slave，以完成一次完全同步。而Slave從節(jié)點(diǎn)服務(wù)在接收到數(shù)據(jù)庫文件數(shù)據(jù)之后將其存盤并加載到內(nèi)存中。此后，Master主節(jié)點(diǎn)繼續(xù)將所有已經(jīng)收集到的修改命令，和新的修改命令依次傳送給Slaves，Slave將在本次執(zhí)行這些數(shù)據(jù)修改命令，從而達(dá)到最終的數(shù)據(jù)同步。
如果Master和Slave之間的鏈接出現(xiàn)斷連現(xiàn)象，Slave可以自動(dòng)重連Master，但是在連接成功之后，一次完全同步將被自動(dòng)執(zhí)行。
主從模式的優(yōu)缺點(diǎn)
優(yōu)點(diǎn)：
- 同一個(gè)Master可以同步多個(gè)Slaves。
- Slave同樣可以接受其它Slaves的連接和同步請(qǐng)求，這樣可以有效的分載Master的同步壓力。因此我們可以將Redis的Replication架構(gòu)視為圖結(jié)構(gòu)。
- Master Server是以非阻塞的方式為Slaves提供服務(wù)。所以在Master-Slave同步期間，客戶端仍然可以提交查詢或修改請(qǐng)求。
- Slave Server同樣是以非阻塞的方式完成數(shù)據(jù)同步。在同步期間，如果有客戶端提交查詢請(qǐng)求，Redis則返回同步之前的數(shù)據(jù)
- 為了分載Master的讀操作壓力，Slave服務(wù)器可以為客戶端提供只讀操作的服務(wù)，寫服務(wù)仍然必須由Master來完成。即便如此，系統(tǒng)的伸縮性還是得到了很大的提高。
- Master可以將數(shù)據(jù)保存操作交給Slaves完成，從而避免了在Master中要有獨(dú)立的進(jìn)程來完成此操作。
- 支持主從復(fù)制，主機(jī)會(huì)自動(dòng)將數(shù)據(jù)同步到從機(jī)，可以進(jìn)行讀寫分離。
缺點(diǎn)：
- Redis不具備自動(dòng)容錯(cuò)和恢復(fù)功能，主機(jī)從機(jī)的宕機(jī)都會(huì)導(dǎo)致前端部分讀寫請(qǐng)求失敗，需要等待機(jī)器重啟或者手動(dòng)切換前端的IP才能恢復(fù)。
- 主機(jī)宕機(jī)，宕機(jī)前有部分?jǐn)?shù)據(jù)未能及時(shí)同步到從機(jī)，切換IP后還會(huì)引入數(shù)據(jù)不一致的問題，降低了系統(tǒng)的可用性。
- Redis的主從復(fù)制采用全量復(fù)制，復(fù)制過程中主機(jī)會(huì)fork出一個(gè)子進(jìn)程對(duì)內(nèi)存做一份快照，并將子進(jìn)程的內(nèi)存快照保存為文件發(fā)送給從機(jī)，這一過程需要確保主機(jī)有足夠多的空余內(nèi)存。若快照文件較大，對(duì)集群的服務(wù)能力會(huì)產(chǎn)生較大的影響，而且復(fù)制過程是在從機(jī)新加入集群或者從機(jī)和主機(jī)網(wǎng)絡(luò)斷開重連時(shí)都會(huì)進(jìn)行，也就是網(wǎng)絡(luò)波動(dòng)都會(huì)造成主機(jī)和從機(jī)間的一次全量的數(shù)據(jù)復(fù)制，這對(duì)實(shí)際的系統(tǒng)運(yùn)營造成了不小的麻煩。
- Redis較難支持在線擴(kuò)容，在集群容量達(dá)到上限時(shí)在線擴(kuò)容會(huì)變得很復(fù)雜。為避免這一問題，運(yùn)維人員在系統(tǒng)上線時(shí)必須確保有足夠的空間，這對(duì)資源造成了很大的浪費(fèi)。
其實(shí)redis的主從模式很簡單，在實(shí)際的生產(chǎn)環(huán)境中是很少使用的，我也不建議在實(shí)際的生產(chǎn)環(huán)境中使用主從模式來提供系統(tǒng)的高可用性，之所以不建議使用都是由它的缺點(diǎn)造成的，在數(shù)據(jù)量非常大的情況，或者對(duì)系統(tǒng)的高可用性要求很高的情況下，主從模式也是不穩(wěn)定的。
哨兵模式（Sentinel）
哨兵模式是從Redis的2.6版本開始提供的，但是當(dāng)時(shí)這個(gè)版本的模式是不穩(wěn)定的，直到Redis的2.8版本以后，這個(gè)哨兵模式才穩(wěn)定下來，無論是主從模式，還是哨兵模式，這兩個(gè)模式都有一個(gè)問題，不能水平擴(kuò)容，并且這兩個(gè)模式的高可用特性都會(huì)受到Master主節(jié)點(diǎn)內(nèi)存的限制。
Sentinel(哨兵)進(jìn)程是用于監(jiān)控redis集群中Master主服務(wù)器工作的狀態(tài)，在Master主服務(wù)器發(fā)生故障的時(shí)候，可以實(shí)現(xiàn)Master和Slave服務(wù)器的切換，保證系統(tǒng)的高可用。
Sentinel（哨兵）進(jìn)程的作用：
Sentinel（哨兵）進(jìn)程的工作方式
哨兵模式的優(yōu)缺點(diǎn)
優(yōu)點(diǎn)：
- 哨兵集群模式是基于主從模式的，所有主從的優(yōu)點(diǎn)，哨兵模式同樣具有。
- 主從可以切換，故障可以轉(zhuǎn)移，系統(tǒng)可用性更好。
- 哨兵模式是主從模式的升級(jí)，系統(tǒng)更健壯，可用性更高。
缺點(diǎn)：
- Redis較難支持在線擴(kuò)容，在集群容量達(dá)到上限時(shí)在線擴(kuò)容會(huì)變得很復(fù)雜。為避免這一問題，運(yùn)維人員在系統(tǒng)上線時(shí)必須確保有足夠的空間，這對(duì)資源造成了很大的浪費(fèi)。
- 配置復(fù)雜
Redis官方 Cluster集群模式（本文使用）
Redis Cluster是一種服務(wù)器Sharding技術(shù)，3.0版本開始正式提供。
集群通過分片來進(jìn)行數(shù)據(jù)共享，并提供復(fù)制和故障轉(zhuǎn)移功能。一個(gè)Redis集群通常由多個(gè)節(jié)點(diǎn)組成；最初，每個(gè)節(jié)點(diǎn)都是獨(dú)立的，需要將獨(dú)立的節(jié)點(diǎn)連接起來才能形成可工作的集群。
Redis中的集群分為主節(jié)點(diǎn)和從節(jié)點(diǎn)。其中主節(jié)點(diǎn)用于處理槽；而從節(jié)點(diǎn)用于復(fù)制某個(gè)主節(jié)點(diǎn)，并在被復(fù)制的主節(jié)點(diǎn)下線時(shí)，代替下線的主節(jié)點(diǎn)繼續(xù)處理命令請(qǐng)求。
Jedis sharding集群(客戶端sharding)
這是一個(gè)客戶端分區(qū)方案。Redis Sharding可以說是在Redis cluster出來之前業(yè)界普遍的采用方式，客戶端就已經(jīng)決定數(shù)據(jù)會(huì)被 存儲(chǔ)到哪個(gè)redis 節(jié)點(diǎn)或者從哪個(gè) redis 節(jié)點(diǎn) 讀取數(shù)據(jù)。其主要思想是采用哈希算法將 Redis 數(shù)據(jù)的 key 進(jìn)行散列，通過 hash 函數(shù)，特定的 key 會(huì)映射 到特定的 Redis 節(jié)點(diǎn)上。
慶幸的是，Java Redis客戶端驅(qū)動(dòng)Jedis已支持Redis Sharding功能，即ShardedJedis以及結(jié)合緩存池的ShardedJedisPool
優(yōu)點(diǎn)：
- 采用一致性哈希算法，將key和節(jié)點(diǎn)name同時(shí)hashing，然后進(jìn)行映射匹配，采用的算法是MURMUR_HASH。采用一致性哈希而不是采用簡單類似哈希求模映射的主要原因是當(dāng)增加或減少節(jié)點(diǎn)時(shí)，不會(huì)產(chǎn)生由于重新匹配造成的rehashing。一致性哈希只影響相鄰節(jié)點(diǎn)key分配，影響量小。
- 為了避免一致性哈希只影響相鄰節(jié)點(diǎn)造成節(jié)點(diǎn)分配壓力，ShardedJedis會(huì)對(duì)每個(gè)Redis節(jié)點(diǎn)根據(jù)名字(沒有，Jedis會(huì)賦予缺省名字)會(huì)虛擬化出160個(gè)虛擬節(jié)點(diǎn)進(jìn)行散列。根據(jù)權(quán)重weight，也可虛擬化出160倍數(shù)的虛擬節(jié)點(diǎn)。用虛擬節(jié)點(diǎn)做映射匹配，可以在增加或減少Redis節(jié)點(diǎn)時(shí)，key在各Redis節(jié)點(diǎn)移動(dòng)再分配更均勻，而不是只有相鄰節(jié)點(diǎn)受影響。
- ShardedJedis支持keyTagPattern模式，即抽取key的一部分keyTag做sharding，這樣通過合理命名key，可以將一組相關(guān)聯(lián)的key放入同一個(gè)Redis節(jié)點(diǎn)，這在避免跨節(jié)點(diǎn)訪問相關(guān)數(shù)據(jù)時(shí)很重要。
當(dāng)然，Redis Sharding這種輕量靈活方式必然在集群其它能力方面做出妥協(xié)。比如擴(kuò)容，當(dāng)想要增加Redis節(jié)點(diǎn)時(shí)，盡管采用一致性哈希，畢竟還是會(huì)有key匹配不到而丟失，這時(shí)需要鍵值遷移。
缺點(diǎn)：
作為輕量級(jí)客戶端sharding，處理Redis鍵值遷移是不現(xiàn)實(shí)的，這就要求應(yīng)用層面允許Redis中數(shù)據(jù)丟失或從后端數(shù)據(jù)庫重新加載數(shù)據(jù)。但有些時(shí)候，擊穿緩存層，直接訪問數(shù)據(jù)庫層，會(huì)對(duì)系統(tǒng)訪問造成很大壓力。
利用中間件代理
原理：客戶端發(fā)送請(qǐng)求到一個(gè)代理組件，代理解析客戶端的數(shù)據(jù)，并將請(qǐng)求轉(zhuǎn)發(fā)至正確的節(jié)點(diǎn)，最后將結(jié)果回復(fù)給客戶端。
優(yōu)點(diǎn)：簡化 客戶端 的分布式邏輯，客戶端 透明接入，切換成本低，代理的 轉(zhuǎn)發(fā) 和 存儲(chǔ) 分離。
缺點(diǎn)：多了一層 代理層，加重了 架構(gòu)部署復(fù)雜度 和 性能損耗。
代理分區(qū) 主流實(shí)現(xiàn)的有方案有 Twemproxy 和 Codis
Redis集群安裝（偽集群）
偽集群說明
去中心化
采用去中心化的思想： 沒有中心節(jié)點(diǎn)的說法。
減少帶寬占用性能很高： 它使用hash slot方式將16348個(gè)hash slot覆蓋到所有節(jié)點(diǎn)上，對(duì)于存儲(chǔ)的每個(gè)key值，使用CRC16（KEY）&16348=slot得到他對(duì)應(yīng)的hash slot，并在訪問key的時(shí)候就去找他的hash slot在哪一個(gè)節(jié)點(diǎn)上，然后由當(dāng)前訪問節(jié)點(diǎn)從實(shí)際被分配了這個(gè)hash slot的節(jié)點(diǎn)去取數(shù)據(jù)，節(jié)點(diǎn)之間使用輕量協(xié)議通信 減少帶寬占用性能很高。
自動(dòng)實(shí)現(xiàn)負(fù)載均衡與高可用： 自動(dòng)實(shí)現(xiàn)負(fù)載均衡與高可用，自動(dòng)實(shí)現(xiàn)failover并且支持動(dòng)態(tài)擴(kuò)展。
內(nèi)部中也需要配置主從
其內(nèi)部中也需要配置主從，并且內(nèi)部也是采用哨兵模式，如果有半數(shù)節(jié)點(diǎn)發(fā)現(xiàn)某個(gè)異常節(jié)點(diǎn)，共同決定更改異常節(jié)點(diǎn)的狀態(tài)，如果改節(jié)點(diǎn)是主節(jié)點(diǎn)，則對(duì)應(yīng)的從節(jié)點(diǎn)自動(dòng)頂替為主節(jié)點(diǎn)，當(dāng)原先的主節(jié)點(diǎn)上線后，則會(huì)變?yōu)閺墓?jié)點(diǎn)。
如果集群中的master沒有slave節(jié)點(diǎn)，則master掛掉后整個(gè)集群就會(huì)進(jìn)入fail狀態(tài)，因?yàn)榧旱膕lot映射不完整。如果集群超過半數(shù)以上的master掛掉，無論是否有slave，集群都會(huì)進(jìn)入fail狀態(tài)。
部署節(jié)點(diǎn)要求
Redis集群至少要有6臺(tái)服務(wù)器，其中3個(gè)主節(jié)點(diǎn)，3個(gè)從節(jié)點(diǎn)。因?yàn)榧褐袠?biāo)記一個(gè)節(jié)點(diǎn)已失效至少要有超過半數(shù)的節(jié)點(diǎn)認(rèn)為某一節(jié)點(diǎn)失效，所以需要至少3個(gè)節(jié)點(diǎn)。如果其中一個(gè)及節(jié)點(diǎn)失效了，沒有從節(jié)點(diǎn)頂上，那集群就掛了，所以需要3個(gè)從節(jié)點(diǎn)做替補(bǔ)。 本文基于Redis官方Cluster集群模式版本redis-5.0.10。
偽集群搭建
創(chuàng)建目錄并下載Redis安裝包
官方下載地址：https://redis.io/download/
執(zhí)行以下命令：
mkdir -p /usr/local/redis cd /usr/local/redis wget https://download.redis.io/releases/redis-5.0.10.tar.gz將安裝包解壓：
tar -zxvf redis-5.0.10.tar.gz將解壓后的文件名修改為7001：
mv redis-5.0.10 7001 cd 7001 mkdir log mkdir data編譯安裝
make MALLOC=libc make install修改redis.conf
打開redis.conf配置文件：
vim /usr/local/redis/7001/redis.conf修改如下內(nèi)容字段：
################################## NETWORK ##################################### #bind 127.0.0.1 # 綁定監(jiān)聽的網(wǎng)卡IP，注釋掉或配置成0.0.0.0可使任意IP均可訪問 protected-mode no # 關(guān)閉保護(hù)模式，使用密碼訪問 port 7001 # 設(shè)置監(jiān)聽端口，建議生產(chǎn)環(huán)境均使用自定義端口 ################################# GENERAL ##################################### daemonize yes # 在后臺(tái)運(yùn)行 pidfile "/var/run/redis_7001.pid" # pid進(jìn)程文件名 logfile "/usr/local/redis/7001/log/redis.log" # 日志文件的位置 ################################ SNAPSHOTTING ################################ dir "/usr/local/redis/7001/data" ################################ REDIS CLUSTER ############################### cluster-enabled yes cluster-config-file nodes-1001.conf cluster-node-timeout 15000 ################################## SECURITY ################################### masterauth "admin@2021" # 連接主節(jié)點(diǎn)密碼，用于主從通信 requirepass "admin@2021" # 連接集群密碼將7001拷貝成7002，7003，7004，7005，7006，并且修改上述的配置文件中的7001為7002，7003，7004，7005，7006。
cp -a 7001 7002 cp -a 7001 7003 cp -a 7001 7004 cp -a 7001 7005 cp -a 7001 7006以7002配置文件修改為例：
首先使用vim打開文件：
vim /usr/local/redis/7002/redis.conf然后執(zhí)行統(tǒng)一替換命令，將7001替換為7002：
:%s/7001/7002/g其他的以此類推。
啟動(dòng)所有節(jié)點(diǎn)
cd /usr/local/redis/7001/src redis-server /usr/local/redis/7001/redis.conf redis-server /usr/local/redis/7002/redis.conf redis-server /usr/local/redis/7003/redis.conf redis-server /usr/local/redis/7004/redis.conf redis-server /usr/local/redis/7005/redis.conf redis-server /usr/local/redis/7006/redis.conf查看集群啟動(dòng)情況：
創(chuàng)建集群
注意：在redis5.0后 創(chuàng)建集群統(tǒng)一使用redis-cli，之前的版本使用redis-trib.rb，但是需要安裝ruby軟件相對(duì)復(fù)雜,相比之前的版本5.0不需要安裝額外的軟件，方便。具體的可以參照redis官方網(wǎng)站查看 https://redis.io/topics/cluster-tutorial
創(chuàng)建集群命令：其中 cluster-replicas 1 代表 一個(gè)master后有幾個(gè)slave，1代表為1個(gè)slave節(jié)點(diǎn)
redis-cli --cluster create 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 127.0.0.1:7006 --cluster-replicas 1 -a admin@2021創(chuàng)建過程以及結(jié)果如下所示：
[root@hadoop-master 7001]# redis-cli --cluster create 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 127.0.0.1:7006 --cluster-replicas 1 -a admin@2021 Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. >>> Performing hash slots allocation on 6 nodes... Master[0] -> Slots 0 - 5460 Master[1] -> Slots 5461 - 10922 Master[2] -> Slots 10923 - 16383 Adding replica 127.0.0.1:7005 to 127.0.0.1:7001 Adding replica 127.0.0.1:7006 to 127.0.0.1:7002 Adding replica 127.0.0.1:7004 to 127.0.0.1:7003 >>> Trying to optimize slaves allocation for anti-affinity [WARNING] Some slaves are in the same host as their master M: 0b55e3dab127d38a29214298d89e1dcb539e069d 127.0.0.1:7001slots:[0-5460] (5461 slots) master M: ad5990ece8b89245fb218d030cfbeff77b6d9669 127.0.0.1:7002slots:[5461-10922] (5462 slots) master M: a46c4e47929dd64949a53787c6b753f444378db3 127.0.0.1:7003slots:[10923-16383] (5461 slots) master S: 54102bd86b6dd373f6186e97081a81a78146cfab 127.0.0.1:7004replicates ad5990ece8b89245fb218d030cfbeff77b6d9669 S: a4527590baf6ea2004d5203cfddf2106684c499b 127.0.0.1:7005replicates a46c4e47929dd64949a53787c6b753f444378db3 S: 438b30d76370ff6c750e4102333023761d01992e 127.0.0.1:7006replicates 0b55e3dab127d38a29214298d89e1dcb539e069d 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 127.0.0.1:7001) M: 0b55e3dab127d38a29214298d89e1dcb539e069d 127.0.0.1:7001slots:[0-5460] (5461 slots) master1 additional replica(s) M: a46c4e47929dd64949a53787c6b753f444378db3 127.0.0.1:7003slots:[10923-16383] (5461 slots) master1 additional replica(s) M: ad5990ece8b89245fb218d030cfbeff77b6d9669 127.0.0.1:7002slots:[5461-10922] (5462 slots) master1 additional replica(s) S: 54102bd86b6dd373f6186e97081a81a78146cfab 127.0.0.1:7004slots: (0 slots) slavereplicates ad5990ece8b89245fb218d030cfbeff77b6d9669 S: a4527590baf6ea2004d5203cfddf2106684c499b 127.0.0.1:7005slots: (0 slots) slavereplicates a46c4e47929dd64949a53787c6b753f444378db3 S: 438b30d76370ff6c750e4102333023761d01992e 127.0.0.1:7006slots: (0 slots) slavereplicates 0b55e3dab127d38a29214298d89e1dcb539e069d [OK] All nodes agree about slots configuration. >>> Check for open slots... >>> Check slots coverage... [OK] All 16384 slots covered.測(cè)試
1、連接集群
redis-cli -c -p 7001 -a admin@20212、查看集群數(shù)據(jù)分配情況：
127.0.0.1:7006> cluster nodes 458ae71d614b66fe80539604b9691094749c8685 127.0.0.1:7004@17004 slave bbe46d62787b3983bc7ee22f539e28c8c9c00600 0 1609574226846 4 connected bbe46d62787b3983bc7ee22f539e28c8c9c00600 127.0.0.1:7002@17002 master - 0 1609574225000 2 connected 5461-10922 62c47f88860eddb93a001323720114b5e12c1118 127.0.0.1:7001@17001 master - 0 1609574224802 1 connected 0-5460 bdfb945f7fddfb9d0d3756277815e00be57ad114 127.0.0.1:7005@17005 slave 6dc4e3d34be3606fd0a940c7b864a23fc6e19ab7 0 1609574227869 5 connected bd1e3a9e5894199cf43da8bda1ec994184e4d656 127.0.0.1:7006@17006 myself,slave 62c47f88860eddb93a001323720114b5e12c1118 0 1609574226000 6 connected 6dc4e3d34be3606fd0a940c7b864a23fc6e19ab7 127.0.0.1:7003@17003 master - 0 1609574226000 3 connected 10923-163833、存取數(shù)據(jù)
存name
127.0.0.1:7001> set name test2021 -> Redirected to slot [5798] located at 127.0.0.1:7002 OK取name
[root@hadoop-master src]# redis-cli -c -p 7004 -a admin@2021 Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. 127.0.0.1:7004> get name -> Redirected to slot [5798] located at 127.0.0.1:7002 "test2021"驗(yàn)證故障轉(zhuǎn)移
從下面的圖中可以得到7002是主節(jié)點(diǎn)7004是從節(jié)點(diǎn)
查看redis集群的進(jìn)程
殺掉7002節(jié)點(diǎn)，理論上7004節(jié)點(diǎn)將選舉為master節(jié)點(diǎn)
kill -9 15942其他題外話：
筆者一開始并沒有出現(xiàn)預(yù)期的從節(jié)點(diǎn)切換到主節(jié)點(diǎn)情況，而且主節(jié)點(diǎn)宕機(jī)集群就不可用情況，查了從節(jié)點(diǎn)日志，發(fā)現(xiàn)有如下報(bào)錯(cuò)，從網(wǎng)上查資料顯示是由于設(shè)置了密碼主從同步需要密碼導(dǎo)致的。
解決方案如下，配置文件中增加如下配置：
注意，生產(chǎn)環(huán)境中集群創(chuàng)建的地址一定要寫主機(jī)的ip地址，不然使用java程序連接會(huì)報(bào)《連接Redis集群報(bào) Unable to connect to 127.0.0.1:7008 錯(cuò)誤》
redis-cli --cluster create 192.168.223.131:7001 192.168.223.131:7002 192.168.223.131:7003 192.168.223.131:7004 192.168.223.131:7005 192.168.223.131:7006 --cluster-replicas 1 -a admin@2021參考：
https://juejin.cn/post/6844904097116585991
總結(jié)
以上是生活随笔為你收集整理的CentOS7下安装Redis伪集群（基于Redis官方Cluster集群模式版本redis-5.0.10）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 2020年终总结一下吧
- 下一篇： SpringBoot笔记：SpringB