Redis安裝（單機及各類集群，阿里云）

前言

上周，我朋友突然悄悄咪咪地指著手機上的一篇博客說，這是你的博客吧，我看了一眼，是之前發布的《Rabbit安裝（單機及集群，阿里云》，我朋友很哈皮地告訴我，我的博客被某個Java平臺進行了微信推送，看到許多人閱讀，并認同了我的博客，心理還是很開心的，

好了，話題識訓來，這次就Redis在實際服務器中的各種安裝，進行詳細描述，

另外由于內容較多，并不一定能涵蓋各個方面，萬望見諒，如果存在什么問題，或者有什么需要添加的，請私信或@我，

最后，由于打馬賽克太麻煩了，并且我之后可能會開放安裝視頻，所以有的IP什么的，我并不方便打馬賽克，但是希望你們不要做壞事兒哈，

Redis安裝簡述

簡介

Redis是一款快取中間件，其安裝分為：

單機
主從賦值
哨兵機制
哨兵集群
分片集群

應用

redis通過解壓包中的src下的各類程式，直接應用，

常用的程式有：

redis-server
redis-cli
redis-sentinel

安裝環境

平臺：阿里云

ECS實體規格：ecs.t5-lc1m1.small (性能約束實體)

CPU：單核

記憶體：1G

硬碟：40G

作業系統：CentOS7.6（已經測驗CentOS7.3會出現問題）

購買ECS，用于平時測驗，學習的話，四點建議：

只需要購買共享型，比較適合平時用得不多，測驗也負擔不大，偶爾壓測，
如果資金允許，直接購買將長時間，比較劃算，日后需要也可以提升配置，
阿里云部分地區有優惠（目前有兩個地區）
如果想要嘗試集群等操作，并且打算購買多個服務器，請一定要在同一個內網內，這樣才可以利用內網通信，

防火墻

云服務器的防火墻，我依舊將其分為云平臺的安全策略與服務器本身的防火墻服務，

而阿里云的官方CentOS7.6鏡像，是不開啟firewall，可以通過systemctl status firewalld來進行確認，

而云平臺的安全策略是需要在安全組內進行設定的，這個部分網上很多資料，就不在此贅述了，

而RabbitMQ需要開放6379埠（默認的redis通信介面，可以在組態檔中修改），26380（本次開放給哨兵的埠）兩個埠，

單機安裝

下載程式包

在阿里云的Linux上可以通過以下方式，進行下載，

wget http://download.redis.io/releases/redis-5.0.3.tar.gz

同樣因為XXX緣故，速度可能會比較感人，這里同樣提供網盤下載，

redis-5.0.3：提取碼：6loe

創建檔案夾

mkdir /developer/redis/conf
mkdir /developer/redis/data
mkdir /developer/redis/logs

解壓檔案

（說明一下，我的壓縮包是放在/developer目錄下的，如果不在此目錄，請指定解壓目錄）

tar -zxvf redis-5.0.3.tar.gz

無配置（默認配置）啟動

為了避免由于目錄，造成理解錯誤，這里采用絕對路徑，

/developer/redis-5.0.3/src/redis-server

成功啟動后，會看到如下畫面：

在這里插入圖片描述

組態檔

為了避免”裸奔“，這里還是配置一下組態檔，

新建組態檔

touch /developer/redis/conf/redis.conf

組態檔


	# 組態檔進行了精簡，完整配置可自行和官方提供的完整conf檔案進行對照，埠號自行對應修改
	#后臺啟動的意思
	daemonize yes
	#埠號(如果同一臺服務器上啟動多個redis實體，注意要修改為不同的埠)
	port 6379
	# IP系結，redis不建議對公網開放，直接系結0.0.0.0沒毛病，也可以直接注釋
	#bind 0.0.0.0
	# 這個檔案會自動生成(如果同一臺服務器上啟動，注意要修改為不同的埠)，多臺服務器，直接默認即可
	#pidfile /var/run/redis_6379.pid
	# 關閉保護模式（默認是開啟的，開啟后，只能通過配置bind ip或者設定訪問密碼，才可以訪問）
	protected-mode no

組態檔啟動

/developer/redis-5.0.3/src/redis-server /developer/redis/conf/redis.conf

這樣啟動后，會出現以下頁面：

在這里插入圖片描述

單機啟動的各類問題

單機啟動時，會看到下面圖片中標出的三個問題：

在這里插入圖片描述

修改Linux內核引數

WARNING The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.

解決：

echo 1024 >/proc/sys/net/core/somaxconn

overcommit_memory問題

WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.

解決：

echo "vm.overcommit_memory = 1" >> /etc/sysctl.conf

sysctl vm.overcommit_memory=1

THP問題

WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled

解決：

echo never > /sys/kernel/mm/transparent_hugepage/enabled

校驗

為了更好的校驗，這里給大家提供一個工具-Redis-desktop-manager

redis-desktop-manager：提取碼：jdc2

作為正版軟體，會有14天的試用期，當然，如果幾乎不用，也可以使用盜版，但是還是推薦正版的說（正版功能強大），貌似還有github提交，就可以免費的說法（起碼以前是存在的，現在就不清楚了），

如果看到以下畫面，就表示OK了：

在這里插入圖片描述

另外，可以通過以下命令校驗：

/developer/redis-5.0.3/src/redis-cli -p 6379 info

一般看到如下畫面即可：

在這里插入圖片描述

Redis主從復制

Redis的主從復制還是較為簡單的，

主要分為兩個方面，一方面是多個獨立的Redis實體，另一方面是Redis的slaveof配置（共有三種方式），

Redis檔案發送

通過以下命令，進行Redis的檔案發送：

scp -r /developer/ [email protected]:/

上述命令，是將當前服務器的/developer目錄整個（-r 表示遞回）發送給172.26.40.224服務器，

slaveof配置

這里的Redis主服務器的地址為172.26.40.225，其埠為6379

組態檔設定

在組態檔中添加以下陳述句：

slaveof 172.26.40.225 6379

正常啟動，控制臺并不會有專門的提示，正常如下：

在這里插入圖片描述

redis-server啟動時配置引數

這種情況下，無法使用組態檔，

起碼沒法直接使用，可能我的使用存在問題（平時不用這個），囧

正常使用，可以看到如下畫面：

在這里插入圖片描述

redis-cli運行時設定

而通過redis-cli程式，在程式運行時，進行集群調整，

在這里插入圖片描述

脫離集群

擴展一下，有的時候，我們需要將實體，移出當前集群，

既然是運行時，那當然是通過redis-cli程式，

在這里插入圖片描述

校驗

可以通過以下命令：

/developer/redis-5.0.3/src/redis-cli -p 6379 info replication

分別查看Redis實體資訊，

如果看到以下頁面，表示Redis主從集群正常啟動：

Redis主實體：

在這里插入圖片描述

Redis從實體：

在這里插入圖片描述

讀寫分離應用

這里簡單談一下，程式如何使用讀寫分離，如Jedis如何實作讀寫分離，

目前看到的主要有兩種：

建立多個Jedis物件，并通過Jedsi.slaveof來設定主從
在組態檔中建立多個redis資料源，并通過動態轉換類，實作在不同需求時，注入不同的redis連接

當然上述編碼并不友好，一方面這些硬編碼在應用程式中（這個可以通過配置來解決），另一方面存在一致性與擴展性問題（程式中的設定，與Redis的集群本身耦合較高，至于這屬于哪種級別的耦合，我忘了，囧），

當然，我們也可以只獲取Redis主實體的連接資訊，再通過拼接”info replication“命令等，來獲取Redis從實體的連接資訊，

這樣就提高了系統擴展性，因為不再受限于Redis從實體設定，但如果Redis主實體掛了，就比較尷尬了，不過，我們也可以繼續深入去進行Redis主實體監聽，從而便于進行主從切換等，

而這兒，就引出了哨兵機制，

（不是只談安裝嘛，但是一時忍不住，就簡單談一下自己的思路哈）

哨兵機制

正如其名，哨兵機制類似于一個Redis主從集群的代理，對應用程式透明，從而避免應用程式與Redis集群機制的高度耦合，

說個人話，哨兵會根據Redis集群情況，自行進行主從切換，從而確保為應用程式提供有效的Redis快取服務，

接下來就開始Redis哨兵機制的部署吧，

啟動Redis主從集群

Redis哨兵機制是基于Redis主從集群的，所以首先，需要根據前面的操作步驟，安裝并啟動Redis主從集群，

前面有詳談，這里不再贅述，

哨兵機制的配置

話不多說，直接上配置：


	# 組態檔：sentinel.conf，在sentinel運行期間是會被動態修改的
	# sentinel如果重啟時，根據這個配置來恢復其之前所監控的redis集群的狀態
	# 系結IP
	#bind 0.0.0.0
	# 后臺運行
	daemonize yes
	# 默認yes，沒指定密碼或者指定IP的情況下，外網無法訪問
	protected-mode no
	# 哨兵的埠，客戶端通過這個埠來發現redis
	port 26380
	# 哨兵自己的IP，手動設定也可自動發現，用于與其他哨兵通信
	# sentinel announce-ip
	# 臨時檔案夾
	dir "/developer/redis/tmp"
	# 日志
	logfile "/developer/redis/logs/sentinel-26380.log"
	# sentinel監控的master的名字叫做mymaster,(redis的master服務器，哨兵需要通過這個master獲取集群資訊）初始地址為 172.26.40.223 6379,2代表兩個及以上哨兵認定為死亡，才認為是真的死亡，即客觀下線，由于目前是單個哨兵，所以設定為1，即主觀下線等同客觀下線，
	#sentinel monitor mymaster 172.26.40.223 6379 2
	sentinel monitor mymaster 172.26.40.223 6379 1
	# 發送心跳PING來確認master是否存活
	# 如果master在“一定時間范圍”內不回應PONG 或者是回復了一個錯誤訊息，那么這個sentinel會主觀地(單方面地)認為這個master已經不可用了
	sentinel down-after-milliseconds mymaster 1000
	# 如果在該時間（ms）內未能完成failover操作，則認為該failover失敗
	sentinel failover-timeout mymaster 3000
	# 指定了在執行故障轉移時，最多可以有多少個從Redis實體在同步新的主實體，在從Redis實體較多的情況下這個數字越小，同步的時間越長，完成故障轉移所需的時間就越長（因為越多的從實體同步新主實體，新主實體的負載壓力越大，對外提供的服務能力就越弱）
	sentinel parallel-syncs mymaster 1

啟動哨兵

然后就是通過以下命令，啟動哨兵：

/developer/redis-5.0.3/src/redis-sentinel /developer/redis/conf/sentinel.conf

啟動后，光從控制臺的回饋是看不到任何東西的，

校驗

需要通過以下命令進行校驗：

/developer/redis-5.0.3/src/redis-cli -p 26380 info sentinel

如果看到以下頁面，表示哨兵正常啟動：

在這里插入圖片描述

其實，還有一個驗證方式，那就是查看哨兵配置（因為哨兵正常啟動后，會將持久化資訊，保存在配置中），

詳見下圖：

在這里插入圖片描述

從圖中可以看到，不僅新增了兩個從服務器的資訊（哨兵通過info命令，與master互動獲得），還改動了原來的幾處配置（生成myid，替代ip:port等），

哨兵機制的自動主從切換

正如前面提到的，哨兵機制可以自動進行主從切換，

接下來會闡述一下哨兵機制進行主從切換的內在，不感興趣的朋友可以直接跳過，

就拿上面的服務器狀態，進行嘗試，直接關閉Redis主實體，

原Redis主實體

其中最引人矚目的，自然是原Redis主實體的變化，詳見下圖：

在這里插入圖片描述

可以看出，在原Redis主實體剛啟動時，它還是獨立的Redis單機實體，

但是在稍等一會兒（如十秒）后，原Redis主實體就會加入原來的集群中，成為原來集群的一個slave，

新Redis主實體

再就是新Redis主實體的變化：

在這里插入圖片描述

新Redis主實體，會從原來的slave，晉級為master，這個晉級實體的選擇并不是隨機的，而是有著一定規則的，以后有機會再介紹，

其它Redis從實體

在這里插入圖片描述

其它Redis從實體，將會改變集群中的master，

配置變化

其實，更為直接的觀察，可以查看配置，

其實，我剛開始了解哨兵時，我非常好奇一個現象，那就是原Redis主實體，在重新上線后，再次加入集群的流程是怎樣的？其中的持久化資訊（如IP等）是保存在哪里的？

經過一番思考后，我查看了Redis配置與哨兵配置，才發現這一切都在配置中有所體現：

Redis配置

哨兵機制下，Redis配置的變化，有兩個時間，一個是哨兵啟動時，另一個是主從切換時，

在這里插入圖片描述

紅框標記的部分，表示該Redis實體，從172.26.40.224（master）處，進行復制，

如果是Redis主實體，那么其配置的紅框部分則為：

# Generated by CONFIG REWRITE
dir "/root"

哨兵配置

在這里插入圖片描述

由于哨兵保留了整個集群的資訊，所以它可以自由控制集群中各個實體節點的狀態，

這也解釋了原Redis實體在離開集群，重啟后，為什么可以迅速回歸集群，因為其在哨兵配置中已經留有“案底“了，

哨兵機制的應用

簡單說，使用哨兵機制后，客戶端可以直連哨兵，而不再是Redis服務實體了，

這里的哨兵將類似于一個代理，

哨兵集群

當然之前的哨兵存在單點故障問題，所以需要將哨兵構造成集群，

但是哨兵的集群搭建，其實和之前并沒有區別，只不過這次啟動了多個哨兵而已，

當然哨兵的配置可以稍作修改，來提高哨兵集群的價值，

哨兵配置


	# 組態檔：sentinel.conf，在sentinel運行期間是會被動態修改的
	# sentinel如果重啟時，根據這個配置來恢復其之前所監控的redis集群的狀態
	# 系結IP
	#bind 0.0.0.0
	# 后臺運行
	daemonize yes
	# 默認yes，沒指定密碼或者指定IP的情況下，外網無法訪問
	protected-mode no
	# 哨兵的埠，客戶端通過這個埠來發現redis
	port 26380
	# 哨兵自己的IP，手動設定也可自動發現，用于與其他哨兵通信
	# sentinel announce-ip
	# 臨時檔案夾
	dir "/developer/redis/tmp"
	# 日志
	logfile "/developer/redis/logs/sentinel-26380.log"
	# sentinel監控的master的名字叫做mymaster,(redis的master服務器，哨兵需要通過這個master獲取集群資訊）初始地址為 172.26.40.224 6379,2代表兩個及以上哨兵認定為死亡，才認為是真的死亡，即客觀下線，
	sentinel monitor mymaster 172.26.40.224 6379 2
	# 發送心跳PING來確認master是否存活
	# 如果master在“一定時間范圍”內不回應PONG 或者是回復了一個錯誤訊息，那么這個sentinel會主觀地(單方面地)認為這個master已經不可用了
	sentinel down-after-milliseconds mymaster 1000
	# 如果在該時間（ms）內未能完成failover操作，則認為該failover失敗
	sentinel failover-timeout mymaster 3000
	# 指定了在執行故障轉移時，最多可以有多少個從Redis實體在同步新的主實體，在從Redis實體較多的情況下這個數字越小，同步的時間越長，完成故障轉移所需的時間就越長（因為越多的從實體同步新主實體，新主實體的負載壓力越大，對外提供的服務能力就越弱）
	sentinel parallel-syncs mymaster 1

其實就是修改了 sentinel monitor mymaster 172.26.40.224 6379 2 ，

數字1改為2，是為了確保故障轉移的客觀性（詳情了解主觀下線與客觀下線），

IP地址的變換，是因為現在的master是172.26.40.224而已，

啟動

只需要通過以下命令：

/developer/redis-5.0.3/src/redis-sentinel /developer/redis/conf/sentinel.conf

依次啟動多個哨兵實體（甚至可以在一臺服務器上啟動，那就需要修改哨兵配置中的埠號）

校驗

啟動后，通過以下命令驗證各個哨兵實體：

/developer/redis-5.0.3/redis-cli -p 26380 info sentinel

如果看到以下頁面，則表示啟動成功：

在這里插入圖片描述

PS：頁面中顯示了哨兵監控的Redis集群master（哨兵可以監控多個Redis集群），對應Redis集群master0的相關資訊（如name，狀態，主服務器ip:port，以及從服務器數量，對應哨兵數量）等，

哨兵集群的應用

哨兵集群在應用中的使用與哨兵類似，不過這次需要在應用中配置哨兵集群（即配置多個哨兵地址），

擴展

忍不住多說兩句，

哨兵的持久化資訊是保存在哨兵配置中的，

哨兵之間的通信是通過Redis的pubsub機制實作的（包括互相發現），詳見：基于pubsub機制的哨兵通信

分片集群（多主多從的混合架構）

前面哨兵說得再騷氣，也逃不過一個瓶頸，那就是Redis寫瓶頸，畢竟是一主多從的，

所以當寫壓力超過Redis單例上限時，就需要Redis分片集群了，畢竟多主可以多個Redis主實體進行寫操作，所以可以突破主從架構的寫瓶頸，

當然多主多從的混合架構，才是目前的主流（即每個主，都有從服務器用于確保可用性），

而混合架構會比單純的多主無從架構，復雜一些，所以這里直接上多主多從的混合架構，

配置修改

為了開啟分片集群，需要修改每個Redis的配置（即之前的redis.conf）

# 組態檔進行了精簡，完整配置可自行和官方提供的完整conf檔案進行對照，埠號自行對應修改
#后臺啟動的意思
daemonize yes
#埠號(如果同一臺服務器上啟動，注意要修改為不同的埠)
port 6379
# IP系結，redis不建議對公網開放，直接系結0.0.0.0沒毛病，這里直接外網測驗吧，比較方便，生產環境不要這樣，
#bind 0.0.0.0
# 這個檔案會自動生成(如果同一臺服務器上啟動，注意要修改為不同的埠)，多臺服務器，直接默認即可
#pidfile /var/run/redis_6379.pid
# 關閉保護模式（默認是開啟的）
protected-mode no

# 新增配置
# 資料保存目錄
dir /developer/redis/data
# 開啟AOF
appendonly yes


# just for cluster
# 開啟集群
cluster-enabled yes
# 集群配置會自動生成在上述的data目錄
cluster-config-file cluster_node_00.conf
# 集群節點失聯時長判斷
cluster-node-timeout 5000
# 如果是在單臺集群部署集群，需要設定pidfile，這里由于每個服務器都只有一個實體，故采用默認設定（6379）

上述新增配置，均有注釋，這里簡單提一下，這個配置只是令單個Redis實體有了成為Redis集群實體的資格，當這些Redis實體構成集群時，集群的配置資訊會由集群生成，并由每個Redis實體保存至配置中設定的目錄中，

這里簡單展示一下，集群生成的配置（切記，這個配置只有集群啟動后才有，這里只是提前展示一下）：

node0

2e1714431f76910db0e1808ce3a3a9b645d2c38f 172.26.40.225:6379@16379 master - 0 1577441663610 7 connected 0-99 10923-16383
cf755c2ca1757c1828b8da972fc7841305b9b41f 172.26.40.224:6379@16379 master - 0 1577441665000 2 connected 5461-10922
29c4fc9d4807c1e25a56b1cc0c9387ba1e6f5831 172.26.40.226:6379@16379 slave 45c1607ecf3d80f08cf6056d53f73a529ffc17de 0 1577441664000 1 connected
7aaa3b4a7dc9ad6c2348f9d6227c4c555e24f3fb 172.26.40.228:6379@16379 slave 2e1714431f76910db0e1808ce3a3a9b645d2c38f 0 1577441665615 7 connected
24c8fefdb293087adb40eaa45cd9213a8d7d5191 172.26.40.227:6379@16379 slave cf755c2ca1757c1828b8da972fc7841305b9b41f 0 1577441664613 5 connected
45c1607ecf3d80f08cf6056d53f73a529ffc17de 172.26.40.223:6379@16379 myself,master - 0 1577441664000 1 connected 100-5460
vars currentEpoch 7 lastVoteEpoch 0

node1

2e1714431f76910db0e1808ce3a3a9b645d2c38f 172.26.40.225:6379@16379 master - 1577441665696 1577441663000 7 connected 0-99 10923-16383
45c1607ecf3d80f08cf6056d53f73a529ffc17de 172.26.40.223:6379@16379 master - 0 1577441664000 1 connected 100-5460
29c4fc9d4807c1e25a56b1cc0c9387ba1e6f5831 172.26.40.226:6379@16379 slave 45c1607ecf3d80f08cf6056d53f73a529ffc17de 0 1577441664687 1 connected
24c8fefdb293087adb40eaa45cd9213a8d7d5191 172.26.40.227:6379@16379 slave cf755c2ca1757c1828b8da972fc7841305b9b41f 0 1577441664000 5 connected
7aaa3b4a7dc9ad6c2348f9d6227c4c555e24f3fb 172.26.40.228:6379@16379 slave 2e1714431f76910db0e1808ce3a3a9b645d2c38f 1577441665696 1577441663000 7 connected
cf755c2ca1757c1828b8da972fc7841305b9b41f 172.26.40.224:6379@16379 myself,master - 0 1577441663000 2 connected 5461-10922
vars currentEpoch 7 lastVoteEpoch 0

node5

7aaa3b4a7dc9ad6c2348f9d6227c4c555e24f3fb 172.26.40.228:6379@16379 myself,slave 2e1714431f76910db0e1808ce3a3a9b645d2c38f 0 1577441661000 6 connected
cf755c2ca1757c1828b8da972fc7841305b9b41f 172.26.40.224:6379@16379 master - 1577441665165 1577441663696 2 connected 5461-10922
2e1714431f76910db0e1808ce3a3a9b645d2c38f 172.26.40.225:6379@16379 master - 0 1577441663000 7 connected 0-99 10923-16383
45c1607ecf3d80f08cf6056d53f73a529ffc17de 172.26.40.223:6379@16379 master - 0 1577441664000 1 connected 100-5460
24c8fefdb293087adb40eaa45cd9213a8d7d5191 172.26.40.227:6379@16379 slave cf755c2ca1757c1828b8da972fc7841305b9b41f 0 1577441664665 5 connected
29c4fc9d4807c1e25a56b1cc0c9387ba1e6f5831 172.26.40.226:6379@16379 slave 45c1607ecf3d80f08cf6056d53f73a529ffc17de 0 1577441664163 1 connected
vars currentEpoch 7 lastVoteEpoch 0

啟動Redis實體

在配置完成后，需要將每個組成Redis集群的實體，通過以下指令，分別啟動，

/developer/redis-5.0.3/src/redis-server /developer/redis/conf/redis.conf

當然，集群啟動后，也還是可以動態增刪節點的，所以不必太過擔心，

這里的啟動與驗證，與之前Redis啟動是一樣的，這里不再贅述，

創建集群

在集群基本構成的各個Redis實體節點都正常啟動后，接下來就是將它們串聯起來，構成Redis集群，

通過以下指令，構建集群（該指令只適用于5.0+版本）：

/developer/redis-5.0.3/src/redis-cli --cluster create 172.26.40.223:6379 172.26.40.224:6379 172.26.40.225:6379 172.26.40.226:6379 172.26.40.227:6379 172.26.40.228:6379 --cluster-replicas 1

簡單解釋一下這個指令，前半部分就是通過redis-cli呼叫集群模式（--cluster）下的create指令，將上述6個Redis實體構成集群（通過ip:port定位，所以可以單機部署集群，雖然非常雞肋就是了），最后部分，就是通過--cluster-replicas引數設定這個集群每個master都有1個slave實體，這里可以設定多個slave實體，并且slave實體還可以設定自己的slave實體，

成功運行后，可以見到如下頁面：

在這里插入圖片描述

這時候，直接yes確認即可，如果需要修改，可以后續調整，

確認后，可以看到如下圖片：

在這里插入圖片描述

這個時候就已經完成了分片集群的搭建，

集群校驗

通過以下命令，可以確認redis集群槽點分布的資訊：

/developer/redis-5.0.3/src/redis-cli -c -p 6379 cluster nodes

如果看到以下畫面，表示槽點分片OK：

在這里插入圖片描述

集群測驗

為了確認Redis分片集群的功能，我們來做一個簡單的測驗，

就是進入node2的redis實體（主實體），保存a=1資料，然后看是否可以通過node0（主實體，也可以從實體）來獲取a對應的值，

在這里插入圖片描述

上述圖片中，還通過

CLUSTER KEYSLOT a

來確認key=a的資料所在槽點，確實是node0重導向的15495槽點位，

集群操作

前面已經完成了Redis分片集群的安全與確認，這里簡單說一下集群操作，不感興趣的朋友，可以直接跳過，

槽點整理

由于資料傾斜與訪問傾斜問題，新master入集群（新master進入集群時是不會分配槽點的）等問題，可能我們對于原先的槽點分布并不滿意，所以需要將一個master實體上的槽點，移動一定數量到另一個master槽點，

可以通過以下指令實作：

/developer/redis-5.0.3/src/redis-cli --cluster reshard 172.26.40.223:6379 --cluster-from 45c1607ecf3d80f08cf6056d53f73a529ffc17de --cluster-to 2e1714431f76910db0e1808ce3a3a9b645d2c38f --cluster-slots 100 --cluster-yes

該指令，將從id為45c1607ecf3d80f08cf6056d53f73a529ffc17de的master實體，劃分100個槽點到id為2e1714431f76910db0e1808ce3a3a9b645d2c38f的master實體，

PS：master-id可以通過前面的cluster nodes等指令查看，

可以看到以下畫面：

在這里插入圖片描述

然后，通過

/developer/redis-5.0.3/src/redis-cli --cluster check 172.26.40.223:6379

檢查集群的槽點狀態，可以看到以下畫面：

在這里插入圖片描述

可以明顯看到槽點整理的結果，

洗掉節點

接下來都比較簡單，我就簡單放上圖片了，需要的地方，我會提示一下，

在這里插入圖片描述

PS：洗掉節點時，該實體不僅從當前集群移除，并且會被shutdown，

增加節點

首先，啟動對應節點，這里不再贅述，

其次，通過以下指令，實作節點添加：

/developer/redis-5.0.3/src/redis-cli --cluster add-node 172.26.40.226:6379 172.26.40.223:6379

PS：上面兩個連接資訊，前者表示需要添加的新節點資訊，后者表示集群中存在的節點資訊（表示由該節點執行節點添加操作），

PS：如果添加的節點是之前存在過集群中的節點，則會出現以下報錯：

在這里插入圖片描述

這個時候，根據報錯資訊，洗掉redis配置相關資訊即可，即洗掉之前配置的 /developer/redis/data/目錄下的三個檔案：

在這里插入圖片描述

然后啟動目標實體（如果已經啟動，請重啟），即可成功運行，看到以下畫面：

在這里插入圖片描述

另外，資料中也有提到，可能在某些情況下，還需要進行db清除操作（但是我這里并不需要），

增加從節點

可以明顯看出，上述的節點添加后，該節點直接成為了master節點，而我們往往需要添加從節點，

通過以下命令，我們可以為集群添加從節點：

/developer/redis-5.0.3/src/redis-cli --cluster add-node 172.26.40.226:6379 172.26.40.223:6379 --cluster-slave

運行后，可以看到如下畫面：

在這里插入圖片描述

緊接著，校驗一下：

在這里插入圖片描述

這里默認是將新增從節點，分配給從節點數最少的主節點，

如果希望將新增從節點分配給指定的主節點，則需要以下指令：

/developer/redis-5.0.3/src/redis-cli --cluster add-node 172.26.40.226:6379 172.26.40.223:6379 --cluster-slave --cluster-master-id <master-id>

具體執行其實都是類似的，這里不再贅述，

補充

雖然分片集群有16384個槽點，理論可以支撐16384個Redis主實體，但是官方推薦是最多1000個實體（畢竟集群間通信等，還是存在瓶頸的）
redis集群的每個節點使用TCP連接有其它每個節點連接（這也算解釋了前面一條）
資料傾斜與訪問傾斜問題，需要通過調整key的策略，以及slot遷移實作，

這里剽竊一下網易云給出的遷移流程：

在遷移目的節點執行cluster setslot IMPORTING 命令，指明需要遷移的slot和遷移源節點，
在遷移源節點執行cluster setslot MIGRATING 命令，指明需要遷移的slot和遷移目的節點，
在遷移源節點執行cluster getkeysinslot獲取該slot的key串列，
在遷移源節點執行對每個key執行migrate命令，該命令會同步把該key遷移到目的節點，
在遷移源節點反復執行cluster getkeysinslot命令，直到該slot的串列為空，
在遷移源節點和目的節點執行cluster setslot NODE ，完成遷移操作，

總結

至此，Redis相關的各類安裝操作，以及一些安裝問題就全部說完了，

有什么問題，或者需要補充的，可以私信或@我，

覺得不錯的話，可以幫忙點個推薦，以及分享給自己的小伙伴，

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/26005.html

標籤：架構設計

上一篇：你連微服務的網關都說不清楚，還天天鼓搗著要把專案拆分微服務？

下一篇：架構到底是什么？來聽程式老兵怎么說！