讓實習生搭個Redis叢集，差點把我”搭“進去~~~

語言: CN / TW / HK
時間 2022-05-20 16:15:25

theme: fancy

大家好呀，我是狂野君，從今天起，要開啟我的日更模式，只要卷不死，就往死裡卷

誰讓我們踏上了技術這條不歸路呢，簡直停不下來

突然想起了《野子》的一句歌詞，卷啊卷啊，我的驕傲放縱！！！

好了，說點正事兒吧

大家都知道，現在但凡是個系統，都是分散式、微服務這一套東西，動不動就是高併發、高可用、高效能之類的.

如果你還沒不清楚 高併發、高可用、高效能這麼時髦的詞彙，那說明你的真的也該捲一捲了

Redis作為當代系統最著名的三高藝術家，對系統架構做出了卓越的貢獻，必將被Java王國的人名永遠銘記！！ 永遠活在我們心中

所以，今天就給大家嘮嘮 Redis高可用方面的一些實用乾貨，主從複製、哨兵、叢集Cluster、分片等等吧

太多了，說不完了，大家自己往下看吧

哦哦，對了，看完覺得有收穫，記得給狂野君點個贊 收藏啊，這裡先行謝過

江湖再見~~~

效能壓測

Redis 的效能測試工具，目前主流使用的是 redis-benchmark

4.1. redis-benchmark

Redis 官方提供 redis-benchmark 的工具來模擬 N 個客戶端同時發出 M 個請求,可以便捷對伺服器進行讀寫效能壓測

4.2. 語法

redis 效能測試的基本命令如下：

redis-benchmark [option] [option value]

redis 效能測試工具可選引數如下所示：

| 序號 | 選項 | 描述 | 預設值 | | -- | ----------------- | --------------------------------- | --------- | | 1 | -h | 指定伺服器主機名 | 127.0.0.1 | | 2 | -p | 指定伺服器埠 | 6379 | | 3 | -s | 指定伺服器 socket | | | 4 | -c | 指定併發連線數 | 50 | | 5 | -n | 指定請求數 | 10000 | | 6 | -d | 以位元組的形式指定 SET/GET 值的資料大小 | 2 | | 7 | -k | 1=keep alive 0=reconnect | 1 | | 8 | -r | SET/GET/INCR 使用隨機 key, SADD 使用隨機值 | | | 9 | -P | 通過管道傳輸 請求 | 1 | | 10 | -q | 強制退出 redis。僅顯示 query/sec 值 | | | 11 | --csv | 以 CSV 格式輸出 | | | 12 | -l（L 的小寫字母） | 生成迴圈，永久執行測試 | | | 13 | -t | 僅執行以逗號分隔的測試命令列表。 | | | 14 | -I（i 的大寫字母） | Idle 模式。僅開啟 N 個 idle 連線並等待。 | |

4.3. 快速測試

redis-benchmark

在安裝 Redis 的伺服器上，直接執行，不帶任何引數，即可進行測試。測試結果如下：

====== PING_INLINE ======    100000 requests completed in 1.18 seconds    50 parallel clients    3 bytes payload   keep alive: 1  100.00% <= 0 milliseconds  84388.19 requests per second  ====== PING_BULK ======    100000 requests completed in 1.17 seconds    50 parallel clients    3 bytes payload   keep alive: 1  100.00% <= 0 milliseconds  85106.38 requests per second  ====== SET ======    100000 requests completed in 1.18 seconds    50 parallel clients    3 bytes payload   keep alive: 1  99.95% <= 1 milliseconds  99.95% <= 2 milliseconds  99.95% <= 3 milliseconds  100.00% <= 3 milliseconds  85034.02 requests per second  ====== GET ======    100000 requests completed in 1.17 seconds    50 parallel clients    3 bytes payload   keep alive: 1  99.95% <= 1 milliseconds  99.99% <= 2 milliseconds  100.00% <= 2 milliseconds  85106.38 requests per second  ====== INCR ======    100000 requests completed in 1.19 seconds    50 parallel clients    3 bytes payload   keep alive: 1  99.95% <= 2 milliseconds  99.96% <= 3 milliseconds  100.00% <= 3 milliseconds  84317.03 requests per second  ====== LPUSH ======    100000 requests completed in 1.17 seconds    50 parallel clients    3 bytes payload   keep alive: 1  100.00% <= 0 milliseconds  85763.29 requests per second  ====== RPUSH ======    100000 requests completed in 1.15 seconds    50 parallel clients    3 bytes payload   keep alive: 1  100.00% <= 0 milliseconds  87260.03 requests per second  ====== LPOP ======    100000 requests completed in 1.17 seconds    50 parallel clients    3 bytes payload   keep alive: 1  100.00% <= 0 milliseconds  85689.80 requests per second  ====== RPOP ======    100000 requests completed in 1.16 seconds    50 parallel clients    3 bytes payload   keep alive: 1  100.00% <= 0 milliseconds  86281.27 requests per second  ====== SADD ======    100000 requests completed in 1.17 seconds    50 parallel clients    3 bytes payload   keep alive: 1  99.95% <= 2 milliseconds  99.96% <= 3 milliseconds  100.00% <= 3 milliseconds  85106.38 requests per second  ====== HSET ======    100000 requests completed in 1.14 seconds    50 parallel clients    3 bytes payload   keep alive: 1  100.00% <= 0 milliseconds  87719.30 requests per second  ====== SPOP ======    100000 requests completed in 1.16 seconds    50 parallel clients    3 bytes payload   keep alive: 1  100.00% <= 0 milliseconds  85836.91 requests per second  ====== LPUSH (needed to benchmark LRANGE) ======    100000 requests completed in 1.15 seconds    50 parallel clients    3 bytes payload   keep alive: 1  99.92% <= 1 milliseconds  100.00% <= 1 milliseconds  86805.56 requests per second  ====== LRANGE_100 (first 100 elements) ======    100000 requests completed in 2.03 seconds    50 parallel clients    3 bytes payload   keep alive: 1  99.95% <= 1 milliseconds  99.95% <= 2 milliseconds  99.96% <= 3 milliseconds  99.99% <= 4 milliseconds  100.00% <= 4 milliseconds  49261.09 requests per second  ====== LRANGE_300 (first 300 elements) ======    100000 requests completed in 4.58 seconds    50 parallel clients    3 bytes payload   keep alive: 1  6.06% <= 1 milliseconds  99.78% <= 2 milliseconds  99.94% <= 3 milliseconds  99.98% <= 4 milliseconds  100.00% <= 5 milliseconds  100.00% <= 5 milliseconds  21815.01 requests per second  ====== LRANGE_500 (first 450 elements) ======    100000 requests completed in 6.51 seconds    50 parallel clients    3 bytes payload   keep alive: 1  0.04% <= 1 milliseconds  83.91% <= 2 milliseconds  99.93% <= 3 milliseconds  99.97% <= 4 milliseconds  99.98% <= 5 milliseconds  99.99% <= 6 milliseconds  100.00% <= 7 milliseconds  100.00% <= 7 milliseconds  15372.79 requests per second  ====== LRANGE_600 (first 600 elements) ======    100000 requests completed in 8.66 seconds    50 parallel clients    3 bytes payload   keep alive: 1  0.03% <= 1 milliseconds  62.47% <= 2 milliseconds  98.11% <= 3 milliseconds  99.86% <= 4 milliseconds  99.94% <= 5 milliseconds  99.97% <= 6 milliseconds  99.98% <= 7 milliseconds  100.00% <= 8 milliseconds  100.00% <= 8 milliseconds  11551.35 requests per second  ====== MSET (10 keys) ======    100000 requests completed in 1.11 seconds    50 parallel clients    3 bytes payload   keep alive: 1  99.95% <= 2 milliseconds  99.96% <= 3 milliseconds  100.00% <= 3 milliseconds  90009.01 requests per second

基本可以看到，常用的 GET/SET/INCR 等命令，都在 8W+ QPS 以上

4.4. 精簡測試

redis-benchmark -t set,get,incr -n 1000000 -q

  • 通過 -t 引數，設定僅僅測試 SET/GET/INCR 命令
  • 通過 -n 引數，設定每個測試執行 1000000 次操作。
  • 通過 -q 引數，設定精簡輸出結果。

執行結果如下：

[[email protected] ~]# redis-benchmark -t set,get,incr -n 100000 -q  SET: 85888.52 requests per second  GET: 85881.14 requests per second  INCR: 86722.75 requests per second  ​  #測試指令碼效能  redis-benchmark -q script load "redis.call('set','foo','bar')"

4.5 實戰演練

看一個實際的案例，壓測開啟、關閉 aof下，redis的效能剖析

1）關掉auth認證，開啟aof，策略為always，配置檔案如下

#redis.conf  appendonly yes  appendfsync always  #requirepass abc   #關掉auth  ​  #kill舊程序，重啟redis  [[email protected] aof]# pwd  /opt/redis/latest/aof  [[email protected] aof]# ..src/redis-server redis.conf

2）壓測aof下的效能，以get,set為測試案例，將結果記錄下來，留做後面對比

[[email protected] aof]# redis-server /usr/local/redis/redis.conf  SET: 62274.25 requests per second, p50=0.687 msec  GET: 88739.02 requests per second, p50=0.399 msec

3）將配置檔案的appendonly改為no，關掉aof，重啟redis，再來壓測同樣的指令

[[email protected] aof]# ..redis-6.2.4/src/redis-benchmark -t set,get -n 1000000 -q  SET: 91575.09 requests per second, p50=0.391 msec  GET: 90950.43 requests per second, p50=0.391 msec

4）結果分析

  • 對各種讀取操作來說，效能差別不大：get、spop、佇列的range等
  • 對寫操作影響比較大

5）參考價值

  • 如果你的專案裡對資料安全性要求較高，寫少讀多的場景，可以適當使用aof
  • 如果追求極致的效能，只做快取，容忍資料丟失，還是關掉aof

5. Redis高可用

5.1 主從複製

5.1.1 面臨問題

Redis有兩種不同的持久化方式，Redis伺服器通過持久化，把Redis記憶體中持久化到硬碟當中，當Redis宕機時，我們重啟Redis伺服器時，可以由RDB檔案或AOF檔案恢復記憶體中的資料。

image.png

問題1：不過持久化後的資料仍然只在一臺機器上，因此當硬體發生故障時，比如主機板或CPU壞了，這時候無法重啟伺服器，有什麼辦法可以保證伺服器發生故障時資料的安全性？或者可以快速恢復資料呢？

問題2：容量瓶頸

5.1.2 解決辦法

針對這些問題，redis提供了複製(replication)的功能，通過"主從(一主多從)"和"叢集(多主多從)"的方式對redis的服務進行水平擴充套件,用多臺redis伺服器共同構建一個高可用的redis服務系統。

5.1.3 主從複製

主從複製，是指將一臺Redis伺服器的資料，複製到其他的Redis伺服器。前者稱為主節點(master)，後者稱為從節點(slave),資料的複製是單向的，只能由主節點到從節點。

image.png image.png

5.1.4 常用策略

策略1 ：一主多從 主機(寫)，從機(讀)

image.png

策略2：薪火相傳

image.png

5.1.5 主從複製原理

Redis的主從複製是非同步複製，非同步分為兩個方面，一個是master伺服器在將資料同步到slave時是非同步的，因此master伺服器在這裡仍然可以接收其他請求，一個是slave在接收同步資料也是非同步的。

複製方式

redis-cli -p 6379 info | grep run

  • 全量複製

    master伺服器會將自己的rdb檔案傳送給slave伺服器進行資料同步，並記錄同步期間的其他寫入，再發送給slave伺服器，以達到完全同步的目的，這種方式稱為全量複製。

image.png - 增量複製

因為各種原因`master`伺服器與`slave`伺服器斷開後，`slave`伺服器在重新連上`maste`r伺服器時會嘗試重新獲取斷開後未同步的資料即部分同步，或者稱為部分複製。

image.png

工作原理

master伺服器會記錄一個replicationId的偽隨機字串，用於標識當前的資料集版本，還會記錄一個當資料集的偏移量offset，不管master是否有配置slave伺服器，replication Id和offset會一直記錄併成對存在，我們可以通過以下命令檢視replication Id和offset：

> info repliaction

通過redis-cli在master或slave伺服器執行該命令會列印類似以下資訊(不同伺服器資料不同，列印資訊不同)：

connected_slaves:1  slave0:ip=127.0.0.1,port=6380,state=online,offset=9472,lag=1  master_replid:2cbd65f847c0acd608c69f93010dcaa6dd551cee  master_repl_offset:9472

當master與slave正常連線時，slave使用PSYNC命令向master傳送自己記錄的舊master的replication id和offset，而master會計算與slave之間的資料偏移量，並將緩衝區中的偏移數量同步到slave，此時master和slave的資料一致。

而如果slave引用的replication太舊了，master與slave之間的資料差異太大，則master與slave之間會使用全量複製的進行資料同步。

5.1.6 配置主從複製

注：主從複製的開啟，完全是在從節點發起的；不需要我們在主節點做任何事情。

從節點開啟主從複製，有3種方式：

（1）配置檔案：在從伺服器的配置檔案中加入：slaveof

（2）redis-server啟動命令後加入 --slaveof

（3）Redis伺服器啟動後，直接通過客戶端執行命令：slaveof ，則該Redis例項成為從節點

演示：

①、通過 info replication 命令檢視三臺節點角色

image.png

初始狀態，三臺節點都是master

②、設定主從關係，從節點執行命令：SLAVEOF 127.0.0.1 6379

image.png

再看主節點資訊：

image.png

這裡通過命令來設定主從關係，一旦服務重啟，那麼角色關係將不復存在。想要永久的儲存這種關係，可以通過配置redis.conf 檔案來配置。

slaveof 127.0.0.1 6379

5.1.7 測試主從關係

①、增量複製

master 操作寫入：

image.png slave操作獲取：

image.png

②、全量複製

通過執行 SLAVEOF 127.0.0.1 6379，如果主節點 6379 以前還存在一些 key，那麼執行命令之後，從節點會將以前的資訊也都複製過來

③、主從讀寫分離

嘗試slave操作獲取：

image.png

原因是在配置檔案 6380redis.conf 中對於 slave-read-only 的配置

image.png

image.png 如果我們將其修改為 no 之後，執行寫命令是可以的，但是從節點寫命令的資料從節點或者主節點都不能獲取的。

④、主節點宕機

主節點 Maste 掛掉，兩個從節點角色會發生變化嗎？

image.png

image.png

上圖可知主節點 Master 掛掉之後，從節點角色還是不會改變的。

⑤、主節點宕機後恢復

主節點Master掛掉之後，馬上啟動主機Master，主節點扮演的角色還是 Master 嗎？

image.png

也就是說主節點掛掉之後重啟，又恢復了主節點的角色。

5.2 sentinel哨兵模式

通過前面的配置，主節點Master 只有一個，一旦主節點掛掉之後，從節點沒法擔起主節點的任務，那麼整個系統也無法執行。

如果主節點掛掉之後，從節點能夠自動變成主節點，那麼問題就解決了，於是哨兵模式誕生了。

image.png

哨兵模式是一種特殊的模式，首先Redis提供了哨兵的命令，哨兵是一個獨立的程序，作為程序，它會獨立執行。其原理是哨兵通過傳送命令，等待Redis伺服器響應，從而監控執行的多個Redis例項。

哨兵模式搭建步驟：　

①、在配置檔案目錄下新建 sentinel.conf 檔案，名字絕不能錯，然後配置相應內容

image.png

sentinel monitor 被監控機器的名字(自己起名字) ip地址 埠號 得票數

image.png

分別配置被監控的名字，ip地址，埠號，以及得票數。上面的得票數為1表示表示主機掛掉後salve投票看讓誰接替成為主機，得票數大於1便成為主機

②、啟動哨兵

redis-sentinel /etc/redis/sentinel.conf

image.png

接下來，我們幹掉主機 6379，然後看從節點有啥變化。

image.png

幹掉主節點之後，我們檢視後臺列印日誌，發現 6380投票變為主節點

image.png

PS：哨兵模式也存在單點故障問題，如果哨兵機器掛了，那麼就無法進行監控了，解決辦法是哨兵也建立叢集，Redis哨兵模式是支援叢集的。

6. Redis Cluster

引言

6.1主從 + 哨兵 問題分析

image.png

（1）在主從 + 哨兵模式中，仍然只有一個Master節點。當併發寫請求較大時，哨兵模式並不能緩解寫壓力

（2） 在Redis Sentinel模式中，每個節點需要儲存全量資料，冗餘比較多

6.2 Cluster概念

從3.0版本之後，官方推出了Redis Cluster，它的主要用途是實現資料分片(Data Sharding)，不過同樣可以實現HA，是官方當前推薦的方案。

image.png

  • 1.Redis-Cluster採用無中心結構
  • 2.只有當叢集中的大多數節點同時fail整個叢集才fail。
  • 3.整個叢集有16384個slot，當需要在 Redis 叢集中放置一個 key-value 時，根據 CRC16(key) mod 16384的值，決定將一個key放到哪個桶中。讀取一個key時也是相同的演算法。
  • 4.當主節點fail時從節點會升級為主節點，fail的主節點online之後自動變成了從節點

6.3 故障轉移

image.png

Redis叢集的主節點內建了類似Redis Sentinel的節點故障檢測和自動故障轉移功能，當叢集中的某個主節點下線時，叢集中的其他線上主節點會注意到這一點，並對已下線的主節點進行故障轉移。

6.4 叢集分片策略

Redis-cluster分片策略，是用來解決key儲存位置的

常見的資料分佈的方式：順序分佈、雜湊分佈、節點取餘雜湊、一致性雜湊..

image.png

6.5 Redis 叢集的資料分片

Redis 叢集沒有使用一致性hash, 而是引入了 雜湊槽的概念.

預設虛擬槽，每個槽就相當於一個數字，有一定範圍

Redis Cluster中預設虛擬槽的範圍為0到16383

image.png

步驟：

  • 1.把16384槽按照節點數量進行平均分配，由節點進行管理

  • 2.對每個key按照CRC16規則進行hash運算

  • 3.把hash結果對16383進行取餘

  • 4.把餘數傳送給Redis節點

  • 5.節點接收到資料，驗證是否在自己管理的槽編號的範圍

    • 如果在自己管理的槽編號範圍內，則把資料儲存到資料槽中，然後返回執行結果
    • 如果在自己管理的槽編號範圍外，則會把資料傳送給正確的節點，由正確的節點來把資料儲存在對應的槽中

需要注意的是：Redis Cluster的節點之間會共享訊息，每個節點都會知道是哪個節點負責哪個範圍內的資料槽

虛擬槽分佈方式中，由於每個節點管理一部分資料槽，資料儲存到資料槽中。當節點擴容或者縮容時，對資料槽進行重新分配遷移即可，資料不會丟失。

6.6 搭建Redis Cluster

步驟分析：

  • 啟動節點：將節點以叢集方式啟動，此時節點是獨立的。
  • 節點握手：將獨立的節點連成網路。
  • 槽指派：將16384個槽位分配給主節點，以達到分片儲存資料庫鍵值對的效果。
  • 主從複製：為從節點指定主節點。

步驟實現

啟動節點

（1）新建目錄，並拷貝出6個節點的配置檔案

mkdir redis-cluster mkdir 900{1,2,3,4,5,6}

image.png

（2）將redis.conf，依次拷貝到每個900X目錄內，並修改每個900X目錄下的redis.conf配置檔案：

``` 以叢集方式啟動

cluster-enabled yes 將前面的 # 去掉

叢集節點nodes資訊配置檔案（是自動生成的） # cluster-config-file nodes-6379.conf 修改為 cluster-config-file "/usr/local/redis/cluster/nodes-9001.conf" # 對應各個埠 ```

（3）啟動6個Redis例項

image.png

檢視程序：

image.png

節點握手&槽指派&主從複製

redis5.0使用redis-cli作為建立叢集的命令，使用c語言實現，不再使用ruby語言。

1）有了例項後，搭建叢集非常簡單，使用redis-cli一行命令即可

```

replicas表示副本數，如果指定1則表示1個從庫做備用

redis-cli --cluster create 127.0.0.1:9001 127.0.0.1:9002 127.0.0.1:9003 --cluster-replicas 1 ```

引數解釋： –cluster-replicas 1：表示希望為叢集中的每個主節點建立一個從節點(一主一從)。 –cluster-replicas 2：表示希望為叢集中的每個主節點建立兩個從節點(一主二從)。

2）備註：如果節點上有資料，可能會有錯誤提示：

[ERR] Node 127.0.0.1:8004 is not empty. Either the node already knows other nodes (check with CLUSTER NODES) or contains some key in database 0.

刪除dump.rdb，nodes.conf，登入redis-cli，flushdb即可

3）如果沒問題，將收到叢集建立成功的訊息：

```

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:8081) M: a085dd0366e08d4c03093ea24351ce4e12fcb69f 127.0.0.1:8081 slots:[0-5460] (5461 slots) master M: 843d8da882f78d3cb09b1eb837140aefba309e06 127.0.0.1:8082 slots:[5461-10922] (5462 slots) master M: 043d39422d93ef5c7c69e1c6cfb1557f655b5d72 127.0.0.1:8083 slots:[10923-16383] (5461 slots) master [OK] All nodes agree about slots configuration. Check for open slots... Check slots coverage... [OK] All 16384 slots covered. ```

叢集驗證

用redis-cli在伺服器上set多個值，比如czbk，分別在不同的例項上，分片成功！

1）cluster命令驗證

```

使用redis-cli登入任意節點，使用cluster nodes可以檢視叢集資訊

127.0.0.1:9001> cluster nodes 39c613372129fe80fe93b6fb3070f9562c315a59 127.0.0.1:[email protected] master - 0 1615193645000 2 connected 5461-10922 725c09c568cb4010afe84d5cb4672fff5a248879 127.0.0.1:[email protected] master - 0 1615193645976 3 connected 10923-16383 9fad54e90628814c1b2a5b57c2ad22b92f0f7b05 127.0.0.1:[email protected] myself,master - 0 1615193644000 1 connected 0-5460 ```

2）使用key值和資料驗證

```

注意，redis-cli引數：

-c ： 自動重定向到對應節點獲取資訊，如果不加，只會返回重定向資訊，不會得到值

不加 -c

[[email protected] src]# redis-cli -p 9001 127.0.0.1:9001> set a a (error) MOVED 15495 127.0.0.1:8083

加上 -c

[[email protected] src]# redis-cli -p 9001 -c 127.0.0.1:9001> set a a -> Redirected to slot [15495] located at 127.0.0.1:9003 #自動跳到9003 OK 127.0.0.1:9003> get a #可以成功get到a的值 "a" ```

擴容

1）按上面方式，新起一個redis ， 8084埠

```

第一個引數是新節點的地址，第二個引數是任意一個已經存在的節點的IP和埠

redis-cli --cluster add-node 127.0.0.1:9004 127.0.0.1:9001 redis-cli --cluster add-node 127.0.0.1:9098 127.0.0.1:9001 ```

2）使用redis-cli登入任意節點，使用cluster nodes檢視新叢集資訊

``` 127.0.0.1:9001> cluster nodes

注意！新加進來的這個8084是空的，沒有分配片段

eb49056da71858d58801f0f28b3d4a7b354956bc 127.0.0.1:[email protected] master - 0 1602665893207 0 connected 16a3f8a4be9863e8c57d1bf5b3906444c1fe2578 127.0.0.1:[email protected] master - 0 1602665891204 2 connected 5461-10922 214e4ca7ece0ceb08ad2566d84ff655fb4447e19 127.0.0.1:[email protected] master - 0 1602665892000 3 connected 10923-16383 864c3f763ab7264ef0db8765997be0acf428cd60 127.0.0.1:[email protected] myself,master - 0 1602665890000 1 connected 0-5460 ```

3）重新分片

``` redis-cli --cluster reshard 127.0.0.1:9001

redis-cli --cluster reshard 127.0.0.1:9001 --cluster-from 10ac7df576168e7f6ec86b20b249e02b1fc13a25,43284b05c5a359b28507b49c29a49637f1f6312b,02a79c59682b7c05f13d41e46e814fc792fa2c50 --cluster-to 07e3416aba80cfb8a8ef81d27228559e5a9d6415 --cluster-slots 1024

根據提示一步步進行，再次檢視node分片，可以了！

127.0.0.1:8081> cluster nodes eb49056da71858d58801f0f28b3d4a7b354956bc 127.0.0.1:[email protected] master - 0 1602666306047 4 connected 0-332 5461-5794 10923-11255 16a3f8a4be9863e8c57d1bf5b3906444c1fe2578 127.0.0.1:[email protected] master - 0 1602666305045 2 connected 5795-10922 214e4ca7ece0ceb08ad2566d84ff655fb4447e19 127.0.0.1:[email protected] master - 0 1602666305000 3 connected 11256-16383 864c3f763ab7264ef0db8765997be0acf428cd60 127.0.0.1:[email protected] myself,master - 0 1602666303000 1 connected 333-5460 ```

4）平衡雜湊槽

為了保證redis雜湊槽的在每一個節點的均衡，需要對雜湊槽進行均衡

redis-cli --cluster rebalance 127.0.0.1:9001

springboot

  • 由以上原理就不難理解，springboot連線redis cluster時，可以連任意一臺，也可以全部寫上。
  • boot1.x預設客戶端為jedis，2.x已經替換為Lettuce，Jedis在實現上是直接連線的redis server，Lettuce的連線是基於Netty的。兩者配置項上略有不同。基礎知識和配置，可以翻閱springboot data部分文件。
  • cluster下slave一般只作為對應master機器的資料備份，可以通過設定readonly作為讀庫，但一般不這麼搞。如果你只是用作快取，不在乎資料的丟失，覺得它浪費了資源，甚至你可以讓slave數量為0，只做資料分片用。
  • Jedis也好，Lettuce也好，其對於redis-cluster架構下的資料的讀取，都是預設是按照redis官方對redis-cluster的建議，所以兩者預設均不支援redis-cluster下的讀寫分離。
  • 如果我們強行只配置slave地址而不配置master（這個操作比較欠），實際上還是可以讀到資料，但其內部操作是通過slave重定向到相關的master主機上，然後再將結果獲取和輸出。

如果，你看到這裡了，那你可真不是一般人，因為一般人根本看不到這裡

既然看到了，相信你一定會有收穫，那就順手給狂野君點個讚唄，點不了吃虧，也點不了上當

您的認可，是我最大的動力

下面是往期的乾貨，希望對你有幫助

我用Redis分散式鎖，搶了瓶茅臺，然後GG了~~ 新來的，你說下Redis的持久化機制，哪一種能解決我們遇到的這個業務問題？ 怎樣才能快速成為一名架構師？

「」
「」