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/ root@172.26.40.224:/

上述命令，是將當前服務器的/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相關的各種安裝操做，以及一些安裝問題就所有說完了。

有什麼問題，或者須要補充的，能夠私信或@我。

以爲不錯的話，能夠幫忙點個推薦，以及分享給本身的小夥伴。