Redis 集群伸缩原理
程序员文章站
2022-03-02 17:43:19
Redis 节点分别维护自己负责的槽和对应的数据。伸缩原理:Redis 槽和对应数据在不同节点之间移动 环境:CentOS7 搭建 Redis 集群 一、集群扩容 1. 手动扩容 (1) 准备节点 9007,并加入集群 192.168.11.40:9001> cluster meet 192.168 ......
redis 节点分别维护自己负责的槽和对应的数据。伸缩原理:redis 槽和对应数据在不同节点之间移动
一、集群扩容
1. 手动扩容
(1) 准备节点 9007,并加入集群
192.168.11.40:9001> cluster meet 192.168.11.40 9007
【注意】若 cluster meet 加入已存在于其它集群的节点,会导致集群合并,造成数据错乱!。建议使用 redis-cli 的 add-node:
# 若节点已加入其它集群或包含数据,会报错 add-node new_host:new_port existing_host:existing_port --cluster-slave # 直接添加为从节点 --cluster-master-id <arg> # 从节点对应的主节点id
(2) 迁移槽和数据
- 槽在迁移过程中集群可以正常提供读写服务
- 首先确定原有节点的哪些槽需要迁移到新节点。确保每个节点负责相似数量的槽,保证各节点的数据均匀
- 槽是 redis 集群管理数据的基本单位。数据迁移是逐槽进行的
槽迁移流程:
- 目标节点准备导入槽的数据:目标节点执行
cluster setslot {slot} importing {sourcenodeid}
- 源节点准备迁出槽的数据:源节点执行
cluster setslot {slot} migrating {targetnodeid}
- 获取 count 个属于槽 slot 的键:源节点执行
cluster getkeysinslot {slot} {count}
- 迁移键:源节点执行
migrate {targetip} {targetport} "" 0 {timeout} keys {keys...}
,把键通过流水线(pipeline)机制批量迁移到目标节点。redis3.0.6 后才支持批量迁移 - 重复上两步,直到槽下所有的键值数据迁移到目标节点
- 向集群所有主节点通知槽被分配给目标节点:集群内所有主节点执行
cluster setslot {slot} node {targetnodeid}
内部伪代码:
def move_slot(source,target,slot): # 目标节点准备导入槽 target.cluster("setslot",slot,"importing",source.nodeid); # 目标节点准备全出槽 source.cluster("setslot",slot,"migrating",target.nodeid); while true : # 批量从源节点获取键 keys = source.cluster("getkeysinslot",slot,pipeline_size); if keys.length == 0: # 键列表为空时,退出循环 break; # 批量迁移键到目标节点 source.call("migrate",target.host,target.port,"",0,timeout,"keys",keys); # 向集群所有主节点通知槽被分配给目标节点 for node in nodes: if node.flag == "slave": continue; node.cluster("setslot",slot,"node",target.nodeid);
(3) 将 9001 的槽 4096 迁移到 9007 中
准备数据
192.168.11.40:9001> set key:test:5028 value:5028 192.168.11.40:9001> set key:test:68253 value:68253
目标节点准备工作
192.168.11.40:9007> cluster nodes 8ccdb0963411ebd05ce21952bdd4b7597825afdc 192.168.11.40:9001@19001 master - 0 1620928869000 2 connected 0-5461 bb1bb0f5f9e0ee67846ba8ec94a38da700e2e80d 192.168.11.40:9007@19007 myself,master - 0 1620928868000 0 connected ... # 9007 准备导入槽 4096 的数据 192.168.11.40:9007> cluster setslot 4096 importing 8ccdb0963411ebd05ce21952bdd4b7597825afdc ok # 槽 4096 已开启导入状态 192.168.11.40:9007> cluster nodes bb1bb0f5f9e0ee67846ba8ec94a38da700e2e80d 192.168.11.40:9007@19007 myself,master - 0 1620928959000 0 connected [4096-<-8ccdb0963411ebd05ce21952bdd4b7597825afdc] ...
源节点准备工作
# 9001 准备导出槽 4096 数据 192.168.11.40:9001> cluster setslot 4096 migrating bb1bb0f5f9e0ee67846ba8ec94a38da700e2e80d ok # 槽 4096 已开启导出状态 192.168.11.40:9001> cluster nodes 8ccdb0963411ebd05ce21952bdd4b7597825afdc 192.168.11.40:9001@19001 myself,master - 0 1620929179000 2 connected 0-5461 [4096->-bb1bb0f5f9e0ee67846ba8ec94a38da700e2e80d] ...
导出数据
# 获取 100 个属于槽 4096 的键 192.168.11.40:9001> cluster getkeysinslot 4096 100 1) "key:test:5028" 2) "key:test:68253" # 查看数据 192.168.11.40:9001> mget key:test:5028 key:test:68253 1) "value:5028" 2) "value:68253" # 迁移这2个键:migrate 命令保证了每个键迁移过程的原子性 192.168.11.40:9001> migrate 192.168.11.40 9007 "" 0 5000 keys key:test:5028 key:test:68253 ok # 再次查询会报 ask 错误:引导客户端找到数据所在的节点 192.168.11.40:9001> mget key:test:5028 key:test:68253 (error) ask 4096 192.168.11.40:9007
通知所有主节点:槽 4096 指派给 9007
192.168.11.40:9001> cluster setslot 4096 node bb1bb0f5f9e0ee67846ba8ec94a38da700e2e80d 192.168.11.40:9002> cluster setslot 4096 node bb1bb0f5f9e0ee67846ba8ec94a38da700e2e80d 192.168.11.40:9003> cluster setslot 4096 node bb1bb0f5f9e0ee67846ba8ec94a38da700e2e80d 192.168.11.40:9007> cluster setslot 4096 node bb1bb0f5f9e0ee67846ba8ec94a38da700e2e80d
查看最终结果
192.168.11.40:9007> cluster nodes 8ccdb0963411ebd05ce21952bdd4b7597825afdc 192.168.11.40:9001@19001 master - 0 1620931743303 7 connected 0-4095 4097-5461 bb1bb0f5f9e0ee67846ba8ec94a38da700e2e80d 192.168.11.40:9007@19007 myself,master - 0 1620931741000 8 connected 4096 ...
2. 使用 redis-cli 扩容
redis-cli 提供了槽重分片功能
reshard 命令参数详解:
reshard host:port # 集群内任意节点地址 --cluster-from <arg> # 源节点id,逗号分隔 --cluster-to <arg> # 目标节点id,只有一个 --cluster-slots <arg> # 迁移多少个槽 --cluster-yes # 确认执行reshard --cluster-timeout <arg> # 每次 migrate 操作的超时时间,默认 60000ms --cluster-pipeline <arg> # 每次批量迁移键的数量,默认 10 --cluster-replace
将 9001、9002、9003 的槽迁移到 9007,共迁移 4096 个
$ /usr/local/redis/bin/redis-cli --cluster reshard 192.168.11.40:9001 m: 8ccdb0963411ebd05ce21952bdd4b7597825afdc 192.168.11.40:9001 slots:[0-4095],[4097-5461] (5461 slots) master 1 additional replica(s) m: bb1bb0f5f9e0ee67846ba8ec94a38da700e2e80d 192.168.11.40:9007 slots:[4096] (1 slots) master ... [ok] all 16384 slots covered. how many slots do you want to move (from 1 to 16384)? 4096 what is the receiving node id? bb1bb0f5f9e0ee67846ba8ec94a38da700e2e80d please enter all the source node ids. type 'all' to use all the nodes as source nodes for the hash slots. type 'done' once you entered all the source nodes ids. source node #1: 8ccdb0963411ebd05ce21952bdd4b7597825afdc source node #2: 5786e3237c7fa413ed22465d15be721f95e72cfa source node #3: 85ceb9826e8aa003169c46fb4ba115c72002d4f9 source node #4: done moving slot 0 from 8ccdb0963411ebd05ce21952bdd4b7597825afdc ... moving slot 12287 from 85ceb9826e8aa003169c46fb4ba115c72002d4f9 do you want to proceed with the proposed reshard plan (yes/no)? yes moving slot 0 from 192.168.11.40:9001 to 192.168.11.40:9007: ... moving slot 12287 from 192.168.11.40:9003 to 192.168.11.40:9007:
查看最终结果
192.168.11.40:9007> cluster nodes 8ccdb0963411ebd05ce21952bdd4b7597825afdc 192.168.11.40:9001@19001 master - 0 1620933907753 7 connected 1366-4095 4097-5461 5786e3237c7fa413ed22465d15be721f95e72cfa 192.168.11.40:9002@19002 master - 0 1620933906733 1 connected 6827-10922 85ceb9826e8aa003169c46fb4ba115c72002d4f9 192.168.11.40:9003@19003 master - 0 1620933905000 3 connected 12288-16383 bb1bb0f5f9e0ee67846ba8ec94a38da700e2e80d 192.168.11.40:9007@19007 myself,master - 0 1620933900000 8 connected 0-1365 4096 5462-6826 10923-12287 ...
检查节点之间槽的均衡性
$ /usr/local/redis/bin/redis-cli --cluster rebalance 192.168.11.40:9001 ... [ok] all 16384 slots covered. *** no rebalancing needed! all nodes are within the 2.00% threshold.
迁移之后所有主节点负责的槽数量差异在 2% 以内,因此集群节点数据相对均匀,无需调整
二、集群收缩
1. 迁移槽
执行 reshard 三次,将数据平均分布到其他三个节点
2. 忘记节点
60s 内对所有节点执行如下操作:(不建议)
# 执行后,会将该节点加入禁用列表(持续 60s),不再向其发送 gossip 消息 cluster forget {nodeid}
建议使用 redis-cli 的 del-node 忘记节点:
/usr/local/redis/bin/redis-cli --cluster del-node {host:port} {nodeid}
内部伪代码
def delnode_cluster_cmd(downnode): # 下线节点不允许包含slots if downnode.slots.length != 0 exit 1 end # 向集群内节点发送cluster forget for n in nodes: if n.id == downnode.id: # 不能对自己做forget操作 continue; # 如果下线节点有从节点则把从节点指向其他主节点 if n.replicate && n.replicate.nodeid == downnode.id : # 指向拥有最少从节点的主节点 master = get_master_with_least_replicas(); n.cluster("replicate",master.nodeid); #发送忘记节点命令 n.cluster('forget',downnode.id) # 节点关闭 downnode.shutdown();
若主从节点都要下线,先下线从,避免全量复制
推荐阅读
-
Springboot 2.0.x 集成基于Centos7的Redis集群安装及配置
-
JAVAEE——宜立方商城06:Redis安装、数据类型和持久化方案、Redis集群分析与搭建、实现缓存和同步
-
laravel项目利用twemproxy部署redis集群的完整步骤
-
Linux(Centos7)下redis5集群搭建和使用
-
redis集群错误解决:/usr/lib/ruby/gems/1.8/gems/redis-3.0.0/lib/redis/client.rb:79:in `call': ERR Slot 15495 is already busy (Redis::CommandError)
-
详解centos下搭建redis集群
-
基于Docker搭建Redis主从集群的实现
-
Docker上实现Redis集群搭建
-
通过Docker部署Redis 6.x集群的方法
-
Redis集群整合到springboot框架