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遷移實現。

這裡剽竊一下網易雲給出的遷移流程：

1. 在遷移目的節點執行cluster setslot IMPORTING 命令，指明需要遷移的slot和遷移源節點。
2. 在遷移源節點執行cluster setslot MIGRATING 命令，指明需要遷移的slot和遷移目的節點。
3. 在遷移源節點執行cluster getkeysinslot獲取該slot的key列表。
4. 在遷移源節點執行對每個key執行migrate命令，該命令會同步把該key遷移到目的節點。
5. 在遷移源節點反覆執行cluster getkeysinslot命令，直到該slot的列表為空。
6. 在遷移源節點和目的節點執行cluster setslot NODE ，完成遷移操作。

總結

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

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

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