文章目錄

• 概要：redis集群方案
• 主從架構
• • 部署主從示例：
  • Redis主從工作原理
• Sentinel（哨兵）模式
• • 哨兵的Jedis連接代碼：
  • springboot訪問哨兵結點
• Cluster模式
• • Redis集群節點間的通信機制
  • Redis高可用集群搭建
  • Java操作redis集群

---

概要：redis集群方案

Redis支持三種集群方案

• 主從復制模式

• Sentinel（哨兵）模式

• Cluster模式

  【主從模式】
  使用一個Redis實例作為主機，其余的作為備份機。主機和備份機的數據完全一致，主機支持數據的寫入和讀取等各項操作，而從機則只支持與主機數據的同步和讀取。也就是說，客戶端可以將數據寫入到主機，由主機自動將數據的寫入操作同步到從機。主從模式很好的解決了數據備份問題，并且由于主從服務數據幾乎是一致的，因而可以將寫入數據的命令發送給主機執行，而讀取數據的命令發送給不同的從機執行，從而達到讀寫分離的目的。
  　　
  　　

  【sentinel】

  哨兵是redis集群中非常重要的一個組件，主要有以下功能。
  ???集群監控：負責監控redis master和slave進程是否正常工作。
  ???消息通知：如果某個redis實例有故障，那么哨兵負責發送消息作為報警通知給管理員，
  ???故障轉移：如果master node掛掉了，會自動轉移到slave node上。
  ???配置中心：如果故障轉移發生了，通知client客戶端新的master地址。

哨兵用于實現reds集群的高可用，本身也是分布式的，作為一個哨兵集群去運行，互相協同工作，
故障轉移時，判斷一個master node是否宕機了，需要大部分的哨兵都同意才行，涉及到了分布式選舉·即使部分哨兵節點掛掉了，哨兵集群還是能正常工作的,哨兵通常需要③個實例，來保證自己的健壯性
　　
　　哨兵+redis主從的部架構，是不保證數據丟失的，只能保證redis集群的高可用性。
對于哨兵+eds主從這種復雜的部署架構，盡量在測試環境和生產環境，都進行充足的測試式和演練
　　【Redis Cluster】
　　是一種服務端Shardingt技術，3.0版本開始正式提供。采用slot(槽)的概念一共分成16384個槽。將請求發送到任意節點，接收到請求的節點會將查詢請求發送到正確的節點上執行Redis Cluster是一種服務端Sharding技木，3.0版本開始正式提供。采用slot(槽)的概念，一共分成16384個槽。將請求發送到任意節點，接收到請求的節點稱查詢請求發送到正確的節點上執行

優點
　　·無中心架構，支持動態擴容，對業務透明
　　·具備Sentinel的監控和自動Failover(故障轉移)能力客戶端不需要連接集群所有節點，連接集群中任何一個可用節點即可高性能，客戶端直連redis服務，
　　·免去了proxy代理的損耗
缺點
　　·運維也很復雜，數據遷移需要人工干預
　　·只能使用0號數據庫
　　·不支持批量操作(pipeline管道操作)
　　·分布式邏輯和存儲模塊耦合等

主從架構

什么是主從復制？

Redis的持久化保證了即使Redis服務重啟也不會丟失數據，因為Redis服務重啟后會將硬盤上持久化的數據恢復到內存中，但是當Redis服務器的硬盤損壞了可能會導致數據丟失，不過通過Redis的主從復制機制就可以避免這種單點故障

1. 基本原理

主從復制模式中包含一個主數據庫實例（master）與一個或多個從數據庫實例（slave），如下圖

客戶端可對主數據庫進行讀寫操作，對從數據庫進行讀操作，主數據庫寫入的數據會實時自動同步給從數據庫。

主redis中的數據有兩個副本，即從redis1和從redis2，即使一臺Redis服務器宕機其他兩臺Redis服務也可以繼續提供服務
主redis中的數據和從redis中的數據保持實時同步，當主redis寫入數據時通過主從復制機制會復制到兩個從redis服務上
只有一個主redis，可以有多個從redis
master和slave都是一個redis實例（redis服務）
通過主從配置可以實現讀寫分離
主從復制不會阻塞master，在同步數據時，master可以繼續處理客戶端請求
一個Redis可以既是主又是從，即redis1和redis2下面又可以有多個從redis服務器，而它們又是redis的從服務器，如下：

對主從模式必須的理解（結論已經驗證過，可以自行驗證）：

一個Master可以有多個Slaves

默認配置下，master節點可以進行讀和寫，slave節點只能進行讀操作，寫操作被禁止

不要修改配置讓slave節點支持寫操作，沒有意義，原因一，寫入的數據不會被同步到其他節點；原因二，當master節點修改同一條數據后，slave節點的數據會被覆蓋掉

slave節點掛了不影響其他slave節點的讀和master節點的讀和寫，重新啟動后會將數據從master節點同步過來

master節點掛了以后，不影響slave節點的讀，Redis將不再提供寫服務，master節點啟動后Redis將重新對外提供寫服務。

master節點掛了以后，不會slave節點重新選一個master

對有密碼的情況說明一下，當master節點設置密碼時：

• 客戶端訪問master需要密碼
• 啟動slave需要密碼，在配置中進行配置即可
• 客戶端訪問slave不需要密碼

主從模式的缺點其實從上面的描述中可以得出：

• master節點掛了以后，redis就不能對外提供寫服務了，因為剩下的slave不能成為master

這個缺點影響是很大的，尤其是對生產環境來說，是一刻都不能停止服務的，所以一般的生產壞境是不會單單只有主從模式的。所以有了下面的sentinel模式。

具體工作機制為：

• slave啟動后，向master發送SYNC命令，master接收到SYNC命令后通過bgsave保存快照（即上文所介紹的RDB持久化），并使用緩沖區記錄保存快照這段時間內執行的寫命令
• master將保存的快照文件發送給slave，并繼續記錄執行的寫命令
• slave接收到快照文件后，加載快照文件，載入數據
• master快照發送完后開始向slave發送緩沖區的寫命令，slave接收命令并執行，完成復制初始化
• 此后master每次執行一個寫命令都會同步發送給slave，保持master與slave之間數據的一致性

部署主從示例：

1、復制一份redis.conf文件2、將相關配置修改為如下值： port 6380 pidfile /var/run/redis_6380.pid # 把pid進程號寫入pidfile配置的文件 logfile "6380.log" dir /usr/local/redis-5.0.3/data/6380 # 指定數據存放目錄 # 根據需求判斷是否注釋bind bind 0.0.0.0 3、配置主從復制 replicaof 192.168.0.60 6379 # 從本機6379的redis實例復制數據，Redis 5.0之前使用slaveof replica-read-only yes # 配置從節點只讀4、啟動從節點 redis-server redis.conf5、連接從節點 redis-cli -p 63806、測試在6379實例上寫數據，6380實例是否能及時同步新修改數據7、可以自己再配置一個6381的從節點

進入master數據庫，寫入一個數據，再進入一個slave數據庫，立即便可訪問剛才寫入master數據庫的數據。如下所示

[root@dev-server-1 master-slave]# redis-cli 127.0.0.1:6379> auth 123456 OK 127.0.0.1:6379> set site blog.jboost.cn OK 127.0.0.1:6379> get site "blog.jboost.cn" 127.0.0.1:6379> info replication # Replication role:master connected_slaves:2 slave0:ip=127.0.0.1,port=7001,state=online,offset=13364738,lag=1 slave1:ip=127.0.0.1,port=7002,state=online,offset=13364738,lag=0 ... 127.0.0.1:6379> exit[root@dev-server-1 master-slave]# redis-cli -p 7001 127.0.0.1:7001> auth 123456 OK 127.0.0.1:7001> get site "blog.jboost.cn"

執行info replication命令可以查看連接該數據庫的其它庫的信息

Redis主從工作原理

如果你為master配置了一個slave，不管這個slave是否是第一次連接上Master，它都會發送一個PSYNC命令給master請求復制數據。
master收到PSYNC命令后，會在后臺進行數據持久化通過bgsave生成最新的rdb快照文件，持久化期間，master會繼續接收客戶端的請求，它會把這些可能修改數據集的請求緩存在內存中。當持久化進行完畢以后，master會把這份rdb文件數據集發送給slave，slave會把接收到的數據進行持久化生成rdb，然后再加載到內存中。然后，master再將之前緩存在內存中的命令發送給slave。
當master與slave之間的連接由于某些原因而斷開時，slave能夠自動重連Master，如果master收到了多個slave并發連接請求，它只會進行一次持久化，而不是一個連接一次，然后再把這一份持久化的數據發送給多個并發連接的slave。

數據部分復制
當master和slave斷開重連后，一般都會對整份數據進行復制。但從redis2.8版本開始，redis改用可以支持部分數據復制的命令PSYNC去master同步數據，slave與master能夠在網絡連接斷開重連后只進行部分數據復制(斷點續傳)。
master會在其內存中創建一個復制數據用的緩存隊列，緩存最近一段時間的數據，master和它所有的slave都維護了復制的數據下標offset和master的進程id，因此，當網絡連接斷開后，slave會請求master繼續進行未完成的復制，從所記錄的數據下標開始。如果master進程id變化了，或者從節點數據下標offset太舊，已經不在master的緩存隊列里了，那么將會進行一次全量數據的復制。

主從復制的優缺點

優點：

• master能自動將數據同步到slave，可以進行讀寫分離，分擔master的讀壓力
• master、slave之間的同步是以非阻塞的方式進行的，同步期間，客戶端仍然可以提交查詢或更新請求

缺點：

• 不具備自動容錯與恢復功能，master或slave的宕機都可能導致客戶端請求失敗，需要等待機器重啟或手動切換客戶端IP才能恢復
• master宕機，如果宕機前數據沒有同步完，則切換IP后會存在數據不一致的問題
• 難以支持在線擴容，Redis的容量受限于單機配置

Sentinel（哨兵）模式

1. 基本原理

哨兵模式基于主從復制模式，只是引入了哨兵來監控與自動處理故障。

sentinel哨兵是特殊的redis服務，不提供讀寫服務，主要用來監控redis實例節點。
sentinel的中文含義是哨兵、守衛。也就是說既然主從模式中，當master節點掛了以后，slave節點不能主動選舉一個master節點出來，那么我就安排一個或多個sentinel來做這件事，當sentinel發現master節點掛了以后，sentinel就會從slave中重新選舉一個master。

哨兵架構下client端第一次從哨兵找出redis的主節點，后續就直接訪問redis的主節點，不會每次都通過sentinel代理訪問redis的主節點，當redis的主節點發生變化，哨兵會第一時間感知到，并且將新的redis主節點通知給client端(這里面redis的client端一般都實現了訂閱功能，訂閱sentinel發布的節點變動消息)

什么是哨兵

Redis-Sentinel是用于管理Redis集群,該系統執行以下三個任務:1.監控(Monitoring): Sentinel會不斷地檢查你的主服務器和從服務器是否運作正常2.提醒(Notification): 當被監控的某個Redis服務器出現問題時, Sentinel可以通過API向管理員或者其他應用程序發送通知3.自動故障遷移(Automatic failover) :當一個主服務器不能正常工作時,Sentinel 會開始一次自動故障遷移操作, 它會將失效主服務器的其中一個從服務器升級為新的主服務器, 并讓失效主服務器的其他從服務器改為復制新的主服務器; 當客戶端試圖連接失效的主服務器時, 集群也會向客戶端返回新主服務器的地址, 使得集群可以使用新主服務器代替失效服務器

如圖

功能概況即：

• 監控master、slave是否正常運行
• 當master出現故障時，能自動將一個slave轉換為master（大哥掛了，選一個小弟上位）
• 多個哨兵可以監控同一個Redis，哨兵之間也會自動監控
• 哨兵模式的具體工作機制：

在配置文件中通過sentinel monitor <master-name> <ip> <redis-port> <quorum>來定位master的IP、端口，一個哨兵可以監控多個master數據庫，只需要提供多個該配置項即可。哨兵啟動后，會與要監控的master建立兩條連接：

• 一條連接用來訂閱master的sentinel:hello頻道與獲取其他監控該master的哨兵節點信息
• 另一條連接定期向master發送INFO等命令獲取master本身的信息

與master建立連接后，哨兵會執行三個操作：

• 定期（一般10s一次，當master被標記為主觀下線時，改為1s一次）向master和slave發送INFO命令
• 定期向master和slave的sentinel:hello頻道發送自己的信息
• 定期（1s一次）向master、slave和其他哨兵發送PING命令

發送INFO命令可以獲取當前數據庫的相關信息從而實現新節點的自動發現。所以說哨兵只需要配置master數據庫信息就可以自動發現其slave信息。獲取到slave信息后，哨兵也會與slave建立兩條連接執行監控。通過INFO命令，哨兵可以獲取主從數據庫的最新信息，并進行相應的操作，比如角色變更等。

接下來哨兵向主從數據庫的sentinel:hello頻道發送信息與同樣監控這些數據庫的哨兵共享自己的信息，發送內容為哨兵的ip端口、運行id、配置版本、master名字、master的ip端口還有master的配置版本。這些信息有以下用處：

• 其他哨兵可以通過該信息判斷發送者是否是新發現的哨兵，如果是的話會創建一個到該哨兵的連接用于發送PING命令。
• 其他哨兵通過該信息可以判斷master的版本，如果該版本高于直接記錄的版本，將會更新
• 當實現了自動發現slave和其他哨兵節點后，哨兵就可以通過定期發送PING命令定時監控這些數據庫和節點有沒有停止服務。

如果被PING的數據庫或者節點超時（通過 sentinel down-after-milliseconds master-name milliseconds 配置）未回復，哨兵認為其主觀下線（sdown，s就是Subjectively —— 主觀地）。

如果下線的是master，哨兵會向其它哨兵發送命令詢問它們是否也認為該master主觀下線，如果達到一定數目（即配置文件中的quorum）投票，哨兵會認為該master已經客觀下線（odown，o就是Objectively —— 客觀地），并選舉領頭的哨兵節點對主從系統發起故障恢復。

若沒有足夠的sentinel進程同意master下線，master的客觀下線狀態會被移除，若master重新向sentinel進程發送的PING命令返回有效回復，master的主觀下線狀態就會被移除。

哨兵認為master客觀下線后，故障恢復的操作需要由選舉的領頭哨兵來執行，選舉采用Raft算法：

• 發現master下線的哨兵節點（我們稱他為A）向每個哨兵發送命令，要求對方選自己為領頭哨兵
• 如果目標哨兵節點沒有選過其他人，則會同意選舉A為領頭哨兵
• 如果有超過一半的哨兵同意選舉A為領頭，則A當選
• 如果有多個哨兵節點同時參選領頭，此時有可能存在一輪投票無競選者勝出，此時每個參選的節點等待一個隨機時間后再次發起參選請求，進行下一輪投票競選，直至選舉出領頭哨兵

選出領頭哨兵后，領頭者開始對系統進行故障恢復，從出現故障的master的從數據庫中挑選一個來當選新的master,選擇規則如下：

• 所有在線的slave中選擇優先級最高的，優先級可以通過slave-priority配置
• 如果有多個最高優先級的slave，則選取復制偏移量最大（即復制越完整）的當選
• 如果以上條件都一樣，選取id最小的slave

挑選出需要繼任的slave后，領頭哨兵向該數據庫發送命令使其升格為master，然后再向其他slave發送命令接受新的master，最后更新數據。將已經停止的舊的master更新為新的master的從數據庫，使其恢復服務后以slave的身份繼續運行。

redis哨兵架構搭建步驟：

1、復制一份sentinel.conf文件 cp sentinel.conf sentinel-26379.conf2、將相關配置修改為如下值： port 26379 daemonize yes pidfile "/var/run/redis-sentinel-26379.pid" logfile "26379.log" dir "/usr/local/redis-5.0.3/data" # sentinel monitor <master-redis-name> <master-redis-ip> <master-redis-port> <quorum> # quorum是一個數字，指明當有多少個sentinel認為一個master失效時(值一般為：sentinel總數/2 + 1)，master才算真正失效 sentinel monitor mymaster 192.168.0.60 6379 2 # mymaster這個名字隨便取，客戶端訪問時會用到3、啟動sentinel哨兵實例 src/redis-sentinel sentinel-26379.conf4、查看sentinel的info信息 src/redis-cli -p 26379 127.0.0.1:26379>info 可以看到Sentinel的info里已經識別出了redis的主從5、可以自己再配置兩個sentinel，端口26380和26381，注意上述配置文件里的對應數字都要修改

sentinel集群都啟動完畢后，會將哨兵集群的元數據信息寫入所有sentinel的配置文件里去(追加在文件的最下面)，我們查看下如下配置文件sentinel-26379.conf，如下所示：

sentinel known-replica mymaster 192.168.0.60 6380 #代表redis主節點的從節點信息

entinel known-replica mymaster 192.168.0.60 6381 #代表redis主節點的從節點信息

sentinel known-sentinel mymaster 192.168.0.60 26380
52d0a5d70c1f90475b4fc03b6ce7c3c56935760f #代表感知到的其它哨兵節點

sentinel known-sentinel mymaster 192.168.0.60 26381
e9f530d3882f8043f76ebb8e1686438ba8bd5ca6 #代表感知到的其它哨兵節點

哨兵的Jedis連接代碼：

public class JedisSentinelTest {public static void main(String[] args) throws IOException {JedisPoolConfig config = new JedisPoolConfig();config.setMaxTotal(20);config.setMaxIdle(10);config.setMinIdle(5);String masterName = "mymaster";Set<String> sentinels = new HashSet<String>();sentinels.add(new HostAndPort("192.168.0.60",26379).toString());sentinels.add(new HostAndPort("192.168.0.60",26380).toString());sentinels.add(new HostAndPort("192.168.0.60",26381).toString());//JedisSentinelPool其實本質跟JedisPool類似，都是與redis主節點建立的連接池//JedisSentinelPool并不是說與sentinel建立的連接池，而是通過sentinel發現redis主節點并與其建立連接JedisSentinelPool jedisSentinelPool = new JedisSentinelPool(masterName, sentinels, config, 3000, null);Jedis jedis = null;try {jedis = jedisSentinelPool.getResource();System.out.println(jedis.set("sentinel", "zhuge"));System.out.println(jedis.get("sentinel"));} catch (Exception e) {e.printStackTrace();} finally {//注意這里不是關閉連接，在JedisPool模式下，Jedis會被歸還給資源池。if (jedis != null)jedis.close();}} }

springboot訪問哨兵結點

<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-data-redis</artifactId> </dependency><dependency><groupId>org.apache.commons</groupId><artifactId>commons-pool2</artifactId> </dependency>

springboot項目核心配置：

server:port: 8080spring:redis:database: 0timeout: 3000sentinel: #哨兵模式master: mymaster #主服務器所在集群名稱,即conf配置中的sentinel monitor mymaster 192.168.0.60 6379 2 nodes: 192.168.0.60:26379,192.168.0.60:26380,192.168.0.60:26381lettuce:pool:max-idle: 50min-idle: 10max-active: 100max-wait: 1000

訪問代碼：
(下面這段代碼在運行以后自己手動關閉主節點，會發現程序先報錯，之后又可以繼續正常執行opsForValue().set操作，證明已經選舉出來了新的主節點）

@RestController public class IndexController {private static final Logger logger = LoggerFactory.getLogger(IndexController.class);@Autowiredprivate StringRedisTemplate stringRedisTemplate;/*** 測試節點掛了哨兵重新選舉新的master節點，客戶端是否能動態感知到* 新的master選舉出來后，哨兵會把消息發布出去，客戶端實際上是實現了一個消息監聽機制，* 當哨兵把新master的消息發布出去，客戶端會立馬感知到新master的信息，從而動態切換訪問的masterip** @throws InterruptedException*/@RequestMapping("/test_sentinel")public void testSentinel() throws InterruptedException {int i = 1;while (true){try {stringRedisTemplate.opsForValue().set("zhuge"+i, i+"");System.out.println("設置key："+ "zhuge" + i);i++;Thread.sleep(1000);}catch (Exception e){logger.error("錯誤：", e);}}} }

雖然客戶端訪問的是sentinel，但是sentinel會實時監控到所有結點（包括主節點和從結點），且會感知到哪個結點是master結點，因此sentinel會把結點的信息推送給客戶端，客戶端的所有插入新鍵值對的操作會在從節點上進行

Cluster模式

1. 基本原理
在redis3.0以前的版本要實現集群一般是借助哨兵sentinel工具來監控master節點的狀態，如果master節點異
常，則會做主從切換，將某一臺slave作為master，哨兵的配置略微復雜，并且性能和高可用性等各方面表現一般，特別是在主從切換的瞬間存在訪問瞬斷的情況，而且哨兵模式只有一個主節點對外提供服務，沒法支持很高的并發，且單個主節點內存也不宜設置得過大，否則會導致持久化文件過大，影響數據恢復或主從同步的效率

Cluster模式實現了Redis的分布式存儲，即每臺節點存儲不同的內容，來解決在線擴容的問題。如圖

高可用集群模式

redis集群是一個由多個主從節點群組成的分布式服務器群，它具有復制、高可用和分片特性。Redis集群不需要sentinel哨兵?也能完成節點移除和故障轉移的功能。需要將每個節點設置成集群模式，這種集群模式沒有中心節點，可水平擴展，據官方文檔稱可以線性擴展到上萬個節點(官方推薦不超過1000個節點)。redis集群的性能和高可用性均優于之前版本的哨兵模式，且集群配置非常簡單.
Cluster采用無中心結構,它的特點如下：

• 所有的redis節點彼此互聯(PING-PONG機制),內部使用二進制協議優化傳輸速度和帶寬
• 節點的fail是通過集群中超過半數的節點檢測失效時才生效
• 客戶端與redis節點直連,不需要中間代理層.客戶端不需要連接集群所有節點,連接集群中任何一個可用節點即可

【Cluster模式的具體工作機制】：

• 在Redis的每個節點上，都有一個插槽（slot），取值范圍為0-16383
• 當我們存取key的時候，Redis會根據CRC16的算法得出一個結果，然后把結果對16384求余數，這樣每個key都會對應一個編號在0-16383之間的哈希槽，通過這個值，去找到對應的插槽所對應的節點，然后直接自動跳轉到這個對應的節點上進行存取操作
• 為了保證高可用，Cluster模式也引入主從復制模式，一個主節點對應一個或者多個從節點，當主節點宕機的時候，就會啟用從節點
• 當其它主節點ping一個主節點A時，如果半數以上的主節點與A通信超時，那么認為主節點A宕機了。如果主節點A和它的從節點都宕機了，那么該集群就無法再提供服務了

Cluster模式集群節點最小配置6個節點(3主3從，因為需要半數以上)，其中主節點提供讀寫操作，從節點作為備用節點，不提供請求，只作為故障轉移使用。

槽位定位算法
Cluster 默認會對 key 值使用 crc16 算法進行 hash 得到一個整數值，然后用這個整數值對 16384 進行取模來得到具體槽位。
HASH_SLOT = CRC16(key) mod 16384

跳轉重定位
當客戶端向一個錯誤的節點發出了指令，該節點會發現指令的 key 所在的槽位并不歸自己管理，這時它會向客戶端發送一個特殊的跳轉指令攜帶目標操作的節點地址，告訴客戶端去連這個節點去獲取數據。客戶端收到指令后除了跳轉到正確的節點上去操作，還會同步更新糾正本地的槽位映射表緩存，后續所有 key 將使用新的槽位映射表。

Redis集群節點間的通信機制

redis cluster節點間采取gossip協議進行通信
維護集群的元數據(集群節點信息，主從角色，節點數量，各節點共享的數據等)有兩種方式：集中式和gossip
集中式：
優點在于元數據的更新和讀取，時效性非常好，一旦元數據出現變更立即就會更新到集中式的存儲中，其他節點讀取的時候立即就可以立即感知到；不足在于所有的元數據的更新壓力全部集中在一個地方，可能導致元數據的存儲壓力。 很多中間件都會借助zookeeper集中式存儲元數據。
gossip：
gossip協議包含多種消息，包括ping，pong，meet，fail等等。
meet：某個節點發送meet給新加入的節點，讓新節點加入集群中，然后新節點就會開始與其他節點進行通信；
ping：每個節點都會頻繁給其他節點發送ping，其中包含自己的狀態還有自己維護的集群元數據，互相通過ping交換元數據(類似自己感知到的集群節點增加和移除，hash slot信息等)；
pong: 對ping和meet消息的返回，包含自己的狀態和其他信息，也可以用于信息廣播和更新；
fail: 某個節點判斷另一個節點fail之后，就發送fail給其他節點，通知其他節點，指定的節點宕機了。

gossip協議的優點在于元數據的更新比較分散，不是集中在一個地方，更新請求會陸陸續續，打到所有節點上去更新，有一定的延時，降低了壓力；缺點在于元數據更新有延時可能導致集群的一些操作會有一些滯后。

Redis集群為什么至少需要三個master節點，并且推薦節點數為奇數？
因為新master的選舉需要大于半數的集群master節點同意才能選舉成功，如果只有兩個master節點，當其中一個掛了，是達不到選舉新master的條件的。
奇數個master節點可以在滿足選舉該條件的基礎上節省一個節點，比如三個master節點和四個master節點的集群相比，大家如果都掛了一個master節點都能選舉新master節點，如果都掛了兩個master節點都沒法選舉新master節點了，所以奇數的master節點更多的是從節省機器資源角度出發說的。(掛了的結點也算在超過半數的結點里面）
注意是超過半數，不是大于等于

Redis高可用集群搭建

redis集群搭建
redis集群需要至少三個master節點，我們這里搭建三個master節點，并且給每個master再搭建一個slave節點，總共6個redis節點，這里用三臺機器部署6個redis實例，每臺機器一主一從，搭建集群的步驟如下：

首先在redis.conf中

第一步：在第一臺機器的/usr/local下創建文件夾redis-cluster，然后在其下面分別創建2個文件夾如下 （1）mkdir -p /usr/local/redis-cluster （2）mkdir 8001 8004第一步：把之前的redis.conf配置文件copy到8001下，修改如下內容： （1）daemonize yes （2）port 8001（分別對每個機器的端口號進行設置） （3）pidfile /var/run/redis_8001.pid # 把pid進程號寫入pidfile配置的文件 （4）dir /usr/local/redis-cluster/8001/（指定數據文件存放位置，必須要指定不同的目錄位置，不然會丟失數據） （5）cluster-enabled yes（啟動集群模式） （6）cluster-config-file nodes-8001.conf（集群節點信息文件，這里800x最好和port對應上） （7）cluster-node-timeout 10000(8)# bind 127.0.0.1（也可以寫成0.0.0.0，允許公網訪問）(9)protected-mode no （關閉保護模式）(10)appendonly yes 如果要設置密碼需要增加如下配置：(11)requirepass 123456 (設置redis訪問密碼)(12)masterauth 123456 (設置集群節點間訪問密碼，跟上面一致)第三步：把修改后的配置文件，copy到8004，修改第2、3、4、6項里的端口號，可以用批量替換： :%s/源字符串/目的字符串/g 第四步：另外兩臺機器也需要做上面幾步操作，第二臺機器用8002和8005，第三臺機器用8003和8006第五步：分別啟動6個redis實例，然后檢查是否啟動成功 （1）/usr/local/redis-5.0.3/src/redis-server /usr/local/redis-cluster/800*/redis.conf （2）ps -ef | grep redis 查看是否啟動成功第六步：用redis-cli創建整個redis集群(redis5以前的版本集群是依靠ruby腳本redis-trib.rb實現) # 下面命令里的1代表為每個創建的主服務器節點創建一個從服務器節點 # 執行這條命令需要確認三臺機器之間的redis實例要能相互訪問，可以先簡單把所有機器防火墻關掉，如果不關閉防火墻則需要打開redis服務端口和集群節點gossip通信端口16379(默認是在redis端口號上加1W) # 關閉防火墻 # systemctl stop firewalld # 臨時關閉防火墻 # systemctl disable firewalld # 禁止開機啟動 # 注意：下面這條創建集群的命令大家不要直接復制，里面的空格編碼可能有問題導致創建集群不成功 （1）/usr/local/redis-5.0.3/src/redis-cli -a 123456 --cluster create --cluster-replicas 1 192.168.0.61:8001 192.168.0.62:8002 192.168.0.63:8003 192.168.0.61:8004 192.168.0.62:8005 192.168.0.63:8006 第七步：驗證集群： （1）連接任意一個客戶端即可：./redis-cli -c -h -p (-a訪問服務端密碼，-c表示集群模式，指定ip地址和端口號）如：/usr/local/redis-5.0.3/src/redis-cli -a 123456 -c -h 192.168.0.61 -p 800* （2）進行驗證： cluster info（查看集群信息）、cluster nodes（查看節點列表） （3）進行數據操作驗證 （4）關閉集群則需要逐個進行關閉，使用命令： /usr/local/redis-5.0.3/src/redis-cli -a 123456 -c -h 192.168.0.60 -p 800* shutdown

Java操作redis集群

<dependency><groupId>redis.clients</groupId><artifactId>jedis</artifactId><version>2.9.0</version> </dependency> public class JedisClusterTest {public static void main(String[] args) throws IOException {JedisPoolConfig config = new JedisPoolConfig();config.setMaxTotal(20);config.setMaxIdle(10);config.setMinIdle(5);Set<HostAndPort> jedisClusterNode = new HashSet<HostAndPort>();jedisClusterNode.add(new HostAndPort("192.168.0.61", 8001));jedisClusterNode.add(new HostAndPort("192.168.0.62", 8002));jedisClusterNode.add(new HostAndPort("192.168.0.63", 8003));jedisClusterNode.add(new HostAndPort("192.168.0.61", 8004));jedisClusterNode.add(new HostAndPort("192.168.0.62", 8005));jedisClusterNode.add(new HostAndPort("192.168.0.63", 8006));JedisCluster jedisCluster = null;try {//connectionTimeout：指的是連接一個url的連接等待時間//soTimeout：指的是連接上一個url，獲取response的返回等待時間jedisCluster = new JedisCluster(jedisClusterNode, 6000, 5000, 10, "xiaoming", config);System.out.println(jedisCluster.set("cluster", "xiaoming"));System.out.println(jedisCluster.get("cluster"));} catch (Exception e) {e.printStackTrace();} finally {if (jedisCluster != null)jedisCluster.close();}} }

總結

以上是生活随笔為你收集整理的redis三种架构：主从Cluster哨兵+整合Springboot访问redis的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。