目录
- 一、Redis集群介绍
- 1、设计目标
- 2、为什么需要分片存储
- 二、官网集群方案
- 三、搭建集群
- 1、准备6个独立的Redis服务
- 2、通过redis-cli工具创建集群
- 3、检验集群
- 4、集群重新分片
- 5、故障转移测试
- 6、集群扩容
- 7、集群节点删除
- 四、集群关心的问题
- 五、集群功能限制
一、Redis集群介绍
1、设计目标
Redis集群是Redis的分布式实现，设计目标如下：
- 高性能: 高达1000个节点的线性扩展，无代理，异步复制，对值没有合并操作。
- 写安全的可接受度：系统尽量保留连上master节点客户端的写请求。通常有段小的时间窗口，可能会丢失确认的写入。当客户端处于少数分区时，丢失确认写的时间窗口会更大。
- 可用性：Redis集群是能在大多数master节点可用的分区中存活，对于每个不可用的master节点至少会分配一个可用的从节点。此外，通过副本迁移，没有任何从节点的master节点将会从其它有多个从节点的master节点中接收一个从节点。
2、为什么需要分片存储
示例：公司用户量3千万，用户基本信息缓存到Redis中，需要内存10G，如何设计Redis的缓存架构？
- 3千万用户，各种业务对用户信息的访问量很大(单台redis读写瓶颈凸显)。
- 单Redis实例管理10G内存，必然影响处理效率。
- Redis的内存需求可能超过机器的最大内存。(一台机器不够用)
二、官网集群方案
Redis Cluster是Redis的分布式集群解决方案，在3.0版本推出后有效地解决了Redis分布式方面的需求，实现了数据在多个Redis节点之间自动分片、故障自动转移、扩容机制功能。
三、搭建集群
这里我的Redis版本选择的是Redis 6.2.10，接下来我们一步步来搭建一个Redis集群，实现一个三主三从的部署。
1、准备6个独立的Redis服务
# 配置文件进行了精简，完整配置可自行和官方提供的完整conf文件进行对照。端口号自行对应修改
#后台启动的意思
daemonize yes
#端口号
port 6381
# IP绑定，redis不建议对公网开放，直接绑定0.0.0.0
bind 172.17.0.13 127.0.0.1
# redis数据文件存放的目录
dir /redis/workingDir
# 日志文件
logfile "/redis/logs/cluster-node-6381.log"
# 开启AOF
appendonly yes# 开启集群
cluster-enabled yes
# 集群持久化配置文件，内容包含其它节点的状态信息等，会自动生成在上面配置的dir目录下
cluster-config-file cluster-node-6381.conf
# 集群节点不可用的最大时间(毫秒)，如果主节点在指定时间内不可达，那么会进行故障转移
cluster-node-timeout 5000
2、通过redis-cli工具创建集群
这里我们通过--cluster-replicas参数指定从节点的数量，下面配置的意思为每个主节点分配一个从节点，也就是上面我们说的三主三从。
#创建集群命令
redis-cli --cluster create \
172.17.0.13:6381 \
172.17.0.13:6382 \
172.17.0.13:6383 \
172.17.0.13:6384 \
172.17.0.13:6385 \
172.17.0.13:6386 \
--cluster-replicas 1
3、检验集群
(1) 检查集群节点信息
redis-cli -c -p 6381 cluster nodes
812fd1150d30fed779153c997f75dbd95cc2dd24 172.17.0.13:6386@16386 slave 7a9f2553d4888d195b4b23a59c50c1c513f6ca4d 0 1596521816554 6 connected
7a9f2553d4888d195b4b23a59c50c1c513f6ca4d 172.17.0.13:6382@16382 master - 0 1596521815000 2 connected 5461-10922
0112d98afb37f7865a0ffc6163fb79fe2f1e91c2 172.17.0.13:6384@16384 slave 44af0912d9b66f6a5a5093f3433e8069abbeb0b0 0 1596521816654 4 connected
ccb82aeb499332507962d7acada5eeae51b53193 172.17.0.13:6381@16381 myself,master - 0 1596521815000 1 connected 0-5460
84198cd9115a11ae336ddc55f0d197780fea98d7 172.17.0.13:6385@16385 slave ccb82aeb499332507962d7acada5eeae51b53193 0 1596521815652 5 connected
44af0912d9b66f6a5a5093f3433e8069abbeb0b0 172.17.0.13:6383@16383 master - 0 1596521816554 3 connected 10923-16383
节点id ip+端口 角色标识 masterId 发送ping的unix时间戳 接收ping的unix时间戳 配置版本 节点连接状态 槽的分配情况
通过cluster nodes命令我们可以查看集群节点的IP、端口、主从标识、从节点的归属信息，以及分配的Hash槽的范围。
备注：myself代表当前客户端操作的节点。
(2) 设置、获取值
#设置值
redis-cli -c -p 6381 set name lyl
Redirected to slot [5798] located at 172.17.0.13:6382
#获取值
redis-cli -c -p 6381 get name
备注：
-c表示开启集群模式，支持重定向。
(3) 查看key属于哪个节点
# 可返回key对应的slot
cluster keyslot name
4、集群重新分片
(1) 分片命令
redis-cli --cluster
reshard <host>:<port> // 任一节点ip和端口
--cluster-from <node-id> // 源节点id，即释放hash槽的节点
--cluster-to <node-id> // 目标节点id，即接收hash槽的节点
--cluster-slots <number of slots> // 迁移的hash槽数量
--cluster-yes
示例1，启动交互式引导分片。
redis-cli --cluster reshard <host>:<port> // 任一节点ip和端口
示例2，指定节点分片，--cluster-yes属性将会自动回答yes，跳过交互式询问。
# 通过redis-cli分片
redis-cli --cluster reshard 172.17.0.13:6381 --cluster-from 55d6a753090b5bdee42563f4ae6fa1593e45ddbb --cluster-to 1a885cf3ff5bd6c5559a7e7c382bead603a7b3fa --cluster-slots 100 --cluster-yes
(2) 检查分片是否成功
# 重新检查集群
redis-cli --cluster check 172.17.0.13:6381
172.17.0.13:6381 (55d6a753...) -> 0 keys | 5361 slots | 1 slaves.
172.17.0.13:6382 (1a885cf3...) -> 0 keys | 5562 slots | 1 slaves.
172.17.0.13:6383 (29be9615...) -> 0 keys | 5461 slots | 1 slaves.
[OK] 0 keys in 3 masters.
0.00 keys per slot on average.
>>> Performing Cluster Check (using node localhost:6381)
M: 55d6a753090b5bdee42563f4ae6fa1593e45ddbb localhost:6381slots:[100-5460] (5361 slots) master1 additional replica(s)
S: 601ff5493cf3dfc148e9ca7baac0f0bd84210755 172.17.0.13:6384slots: (0 slots) slavereplicates 29be96152e02f59873bfe01f25f5c7e28e46f874
S: 99c6abc9b89f65e4e3ce43a96f618415f3227139 172.17.0.13:6385slots: (0 slots) slavereplicates 55d6a753090b5bdee42563f4ae6fa1593e45ddbb
S: 9bb5521f52148fb3372d6b5102ce06f69fcb999a 172.17.0.13:6386slots: (0 slots) slavereplicates 1a885cf3ff5bd6c5559a7e7c382bead603a7b3fa
M: 1a885cf3ff5bd6c5559a7e7c382bead603a7b3fa 172.17.0.13:6382slots:[0-99],[5461-10922] (5562 slots) master1 additional replica(s)
M: 29be96152e02f59873bfe01f25f5c7e28e46f874 172.17.0.13:6383slots:[10923-16383] (5461 slots) master1 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
5、故障转移测试
(1) 自动故障转移
shutdown其中一台主节点，发现端口为6381的节点已经处于fail状态，查看节点信息：
redis-cli -p 6382 cluster nodes
29be96152e02f59873bfe01f25f5c7e28e46f874 172.17.0.13:6383@16383 master - 0 1596694656227 3 connected 10923-16383
601ff5493cf3dfc148e9ca7baac0f0bd84210755 172.17.0.13:6384@16384 slave 29be96152e02f59873bfe01f25f5c7e28e46f874 0 1596694655000 4 connected
99c6abc9b89f65e4e3ce43a96f618415f3227139 172.17.0.13:6385@16385 master - 0 1596694656028 9 connected 100-5460
1a885cf3ff5bd6c5559a7e7c382bead603a7b3fa 172.17.0.13:6382@16382 myself,master - 0 1596694655000 7 connected 0-99 5461-10922
55d6a753090b5bdee42563f4ae6fa1593e45ddbb 172.17.0.13:6381@16381 master,fail - 1596694126578 1596694124000 1 disconnected
9bb5521f52148fb3372d6b5102ce06f69fcb999a 172.17.0.13:6386@16386 slave 1a885cf3ff5bd6c5559a7e7c382bead603a7b3fa 0 1596694655225 7 connected
重新启动被shutdown的主节点，重新查看节点信息，可以看到端口为6381的节点已经变为从节点，原先端口为6385的从节点晋升为了主节点。
55d6a753090b5bdee42563f4ae6fa1593e45ddbb 172.17.0.13:6381@16381 myself,slave 99c6abc9b89f65e4e3ce43a96f618415f3227139 0 1596694940000 1 connected
601ff5493cf3dfc148e9ca7baac0f0bd84210755 172.17.0.13:6384@16384 slave 29be96152e02f59873bfe01f25f5c7e28e46f874 0 1596694941572 4 connected
1a885cf3ff5bd6c5559a7e7c382bead603a7b3fa 172.17.0.13:6382@16382 master - 0 1596694941000 7 connected 0-99 5461-10922
9bb5521f52148fb3372d6b5102ce06f69fcb999a 172.17.0.13:6386@16386 slave 1a885cf3ff5bd6c5559a7e7c382bead603a7b3fa 0 1596694941071 7 connected
29be96152e02f59873bfe01f25f5c7e28e46f874 172.17.0.13:6383@16383 master - 0 1596694942073 3 connected 10923-16383
99c6abc9b89f65e4e3ce43a96f618415f3227139 172.17.0.13:6385@16385 master - 0 1596694942073 9 connected 100-5460
(2) 手动切主
在从节点下执行故障转移命令，将从节点重新变为主节点，如下：
127.0.0.1:6381> CLUSTER FAILOVER
OK
127.0.0.1:6381> CLUSTER nodes
55d6a753090b5bdee42563f4ae6fa1593e45ddbb 172.17.0.13:6381@16381 myself,master - 0 1596695329000 10 connected 100-5460
601ff5493cf3dfc148e9ca7baac0f0bd84210755 172.17.0.13:6384@16384 slave 29be96152e02f59873bfe01f25f5c7e28e46f874 0 1596695329540 4 connected
1a885cf3ff5bd6c5559a7e7c382bead603a7b3fa 172.17.0.13:6382@16382 master - 0 1596695330342 7 connected 0-99 5461-10922
9bb5521f52148fb3372d6b5102ce06f69fcb999a 172.17.0.13:6386@16386 slave 1a885cf3ff5bd6c5559a7e7c382bead603a7b3fa 0 1596695329540 7 connected
29be96152e02f59873bfe01f25f5c7e28e46f874 172.17.0.13:6383@16383 master - 0 1596695329000 3 connected 10923-16383
99c6abc9b89f65e4e3ce43a96f618415f3227139 172.17.0.13:6385@16385 slave 55d6a753090b5bdee42563f4ae6fa1593e45ddbb 0 1596695329841 10 connected
优点：手动切主与由master挂掉引发的故障切换相比更安全，在这个过程中避免了数据丢失。因此只有当系统确认新master已经复制完旧maser的数据才会将客户端从原来的master且切换到新master。
6、集群扩容
(1) 同样配置文件启动新节点
redis-server redis-6387.conf
(2) 加入到已经存在的集群作为master
redis-cli --cluster add-node new_host:new_port existed_host:existed_port
(3) 加入到已经存在的集群作为slave，若不指定node-id，则选择一个slave数量较少的master
redis-cli --cluster add-node new_host:new_port existed_host:existed_port --cluster-slave --cluster-master-id <master-node-id>
(4) 添加一个空master，然后将其转换为其它master的从节点
redis-cli -p port cluster replicate <master-node-id>
7、集群节点删除
(1) 查看要删除节点的节点id
redis-cli -p 6387 cluster nodes | grep myself
6069035a81d3e1eb3109423170236ba9d3164d22 172.17.0.13:6387@16387 myself,master - 0 1596727937000 0 connected
(2) 删除节点
redis-cli --cluster del-node 127.0.0.1:6381 6069035a81d3e1eb3109423170236ba9d3164d22
>>> Removing node 6069035a81d3e1eb3109423170236ba9d3164d22 from cluster 127.0.0.1:6381
>>> Sending CLUSTER FORGET messages to the cluster...
>>> Sending CLUSTER RESET SOFT to the deleted node.
注意：
- 删除master时要把数据清空，或者分配给其它master节点。
- 第一个参数为集群中任一节点信息，第二个参数为被删除的节点id。
四、集群关心的问题
1、增加了槽的计算，是不是比单行性能差？
- 共
16384个槽，槽的计算方式是公开的，hash_slot =CRC16(key)% 16384。 - 为了避免每次都需要服务器计算重定向，优秀的Java客户端都实现了本地计算，并且缓存槽的分配，有变动再更新本地内容，从而避免了多次重定向带来的性能损耗。
2、Redis集群大小，到底可以装多少数据？
理论上是可以做到16384个槽，每个槽对应一个实例，但Redis官方建议是最大1000个实例。
3、集群节点间是怎么通信的？
每个Redis集群节点都有一个额外的TCP端口(通过cluster nodes能看到)，每个节点使用TCP协议与其它每个节点连接，检测和故障切换这些步骤基本和哨兵类似。
4、ask和moved重定向的区别？
重定向包括两种情况：
- 若确定slot不属于当前节点，Redis会返回moved。
- 若当前Redis节点正在处理slot迁移(如reshard),则代表此处请求对应的key暂时不在此节点，返回ask，告诉客户端本次请求重定向。
5、数据倾斜和访问倾斜的问题
倾斜导致集群中部分节点数据多，压力大。解决方案分为前期和后期：
- 前期是业务层面提前预测，哪些key是热点，在设计的过程中规避。
- 后期是slot迁移，尽量将压力分摊（slot调整有自动balance、reshard和手动）。
6、slot手动迁移怎么做？
7、节点之间会交换信息，传递的信息包括槽的信息，带来带宽消耗
避免使用一个大集群，可以分为多个集群。
8、Pub/Sub发布订阅机制
对集群内任意一个节点执行publish发布消息，这个消息会在集群中进行传播，其它节点接收到发布的消息。
9、读写分离
- redis-cluster默认所有从节点上的读写都会重定向到key对应的主节点上。
- 客户端可以通过readonly设置当前连接可读，通过readwrite取消当前连接的可读状态。
注意：主从节点依然存在数据不一致的情况。
五、集群功能限制
1、key批量操作支持有限
如mset、mget，目前只支持具有slot值的key执行批量操作。对于映射为不同slot值的key由于执行mset、mget等操作
可能存在于多个节点上，因此不被支持。
2、key事务操作支持有限
同理只支持多key在同一节点上的事务操作，当多个key分布在不同的节点上时无法使用事务功能。
3、大键值对对象不能映射到不同节点
key作为数据分区的最小粒度，因此不能将一个大键值对象如hash、list等映射到不同的节点。
4、不支持多维数据空间
单机下的Redis可以支持16个数据库，集群模式下只能使用一个数据库空间，即db0。
