Redis集羣節點擴容大法

[ 架構描述 ]

redis

組件版本：

redis：5.0.8

節點架構：

3主3從、6主機

擴容後架構：

6主6從、12主機

[問題描述]

Redis（RemoteDictionary Server )，即遠程字典服務，是一個開源的使用ANSIC語言編寫、支持網絡、可基於內存亦可持久化的日誌型、Key-Value數據庫，並提供多種語言的API。

redis是一個key-value存儲系統,支持存儲的value類型包括string(字符串)、list(鏈表)、set(集合)、zset(sortedset--有序集合)和hash（哈希類型）。這些數據類型都支持push/pop、add/remove及取交集並集和差集及更豐富的操做，並且這些操做都是原子性的。在此基礎上，redis支持各類不一樣方式的排序。與memcached同樣，爲了保證效率，數據都是緩存在內存中。區別的是redis會週期性的把更新的數據寫入磁盤或者把修改操做寫入追加的記錄文件，而且在此基礎上實現了master-slave(主從)同步。

某業務系統採用rediscluster架構，因爲數據量的增加致使部分數據還未過時時就被redis最大內存限制給刪除掉，因此業務在當前三柱三從架構沒法知足業務數據量持續增加的狀況，須要擴容節點至六主六從。

[結構及詳細說明]

Redis集羣大體架構圖：

一組RedisCluster是由多個Redis實例組成，官方推薦使用6實例，其中3個爲主節點，3個爲從結點。一旦有主節點發生故障的時候，RedisCluster能夠選舉出對應的從結點成爲新的主節點，繼續對外服務，從而保證服務的高可用性。那麼對於客戶端來講，知道知道對應的key是要路由到哪個節點呢？原來，RedisCluster把全部的數據劃分爲16384個不一樣的槽位，能夠根據機器的性能把不一樣的槽位分配給不一樣的Redis實例，對於Redis實例來講，他們只會存儲部門的Redis數據，固然，槽的數據是能夠遷移的，不一樣的實例之間，能夠經過必定的協議，進行數據遷移。

須要把3主3從擴容爲6主6從，就須要增長6個節點，依次添加3個主節點hash槽，再添加3個從節點手動分配給主節點。

[操做過程]

一、建立節點

複製原有集羣節點的配置文件更改端口目錄等而後再啓動redis，要添加6個節點需建立6個節點並啓動：

./redis-server../6001/redis.conf

./redis-server../6002/redis.conf

./redis-server../6003/redis.conf

./redis-server../6004/redis.conf

./redis-server../6005/redis.conf

./redis-server../6006/redis.conf

二、添加主節點

第一個ip:port爲須要添加的節點ip和端口，第二個ip:port爲當前集羣中的節點和端口；前後執行如下命令：

./redis-cli--cluster add-node 192.168.8.20:6001 192.168.8.10:7001 -a 123456

./redis-cli--cluster add-node 192.168.8.21:7002 192.168.8.10:7001 -a 123456

……

三、分配hash槽

新添加的節點沒有哈希槽，並不能正常存儲數據，須要給新添加的節點分配哈希槽。

1. 從新分配哈希槽

./redis-cli--cluster reshard  ip:port -a passwd

1. 輸入要分配多少個哈希槽（數量）

1. 輸入指定要分配哈希槽的節點ID

1. 選擇須要分配的哈希槽來源

輸入all須要分配給目標節點的哈希槽來着當前集羣的其餘主節點（每一個節點拿出的數量爲集羣自動決定）

分配哈希槽有兩種方式

（1）將全部節點用做哈希槽的源節點。

（2）在指定的節點拿出指定數量的哈希槽分配到目標節點：

四、添加從節點

添加6004節點（slave的添加方法，master爲7004）

#節點ID是主節點的ID

#192.168.8.20:6004 是新加的從節點

#192.168.8.10:7004 做爲從節點的主節點

./redis-cli--cluster add-node --cluster-slave --cluster-master-idxxxxxxxxxxxxxxxxxxx 192.168.8.20:6004 192.168.8.10:7004

[總結]

一、redis擴容通常有兩種方法，一種是在線擴容，一種是離線擴容，從業務的角度來講，在線擴容是最方便的方法，但在線擴容有個問題是，過程當中若是某個槽正在操做會致使遷移槽是發送錯誤，須要人工干預。

二、離線擴容是比較快速的方法，人工干預比較少由集羣自動分配哈希槽，缺點是需停掉業務。

三、通常來講業務上線前會對redis緩存數據量有一個預估，從而對架構的硬件配置有個預估，就不會產生擴容這個操做，但每每業務數據量是一個動態的，沒法預估的，因此須要經過擴容節點的操做慢在業務的需求，須要保證擴容過程正保證數據的正確性。