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缓存数据量有一个预估，从而对架构的硬件配置有个预估，就不会产生扩容这个操做，但每每业务数据量是一个动态的，没法预估的，因此须要经过扩容节点的操做慢在业务的需求，须要保证扩容过程正保证数据的正确性。