Redis安裝（單機及各類集羣，阿里雲）

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

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

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