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

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相關的各類安裝操作，以及一些安裝問題就全部說完了。

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

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