Redis cluster02:深入集群


Redis cluster02:深入集群

集群通信

  • 在分布式存储中需要提供维护节点元数据信息的机制,所谓元数据是指:节点负责哪些数据,是否出现故障等状态信息
  • Redis集群采用P2P的 Gossip(流言)协议, Gossip协议工作原理就是节点彼此不断通信交换信息,一段时间后所有的节 点都会知道集群完整的信息,这种方式类似流言传播,如下图所示:

集群伸缩

伸缩原理

​ Redis集群提供了灵活的节点扩容和收缩方案。 在不影响集群对外服务的情况下, 可以为集群添加节点进行扩容也可以下线部分节点进行缩容, 如下图所示:

​ 从上图看出, Redis集群可以实现对节点的灵活上下线控制。 其中原理可抽象为槽和对应数据在不同节点之间灵活移动。 首先来看我们之前搭建的集群槽和数据与节点的对应关系, 如下图所示:

​ 三个主节点分别维护自己负责的槽和对应的数据, 如果希望加入1个节点实现集群扩容时, 需要通过相关命令把一部分槽和数据迁移给新节点, 如下图所示:Redis集群--Cluster--集群伸缩--过程/原理_redis_03

图中每个节点把一部分槽和数据迁移到新的节点6385, 每个节点负责的槽和数据相比之前变少了从而达到了集群扩容的目的。 这里我们故意忽略了槽和数据在节点之间迁移的细节, 目的是想让读者重点关注在上层槽和节点分配上来, 理解集群的水平伸缩的上层原理: 集群伸缩=槽和数据在节点之间的移动, 下面将介绍集群扩容和收缩的细节。

扩容集群

扩容是分布式存储最常见的需求,Redis集群扩容操作可分为如下步骤:

  1. 准备节点
  2. 加入集群
  3. 迁移槽和数据

以下来具体演示:

准备新节点

新节点要求:
    集群模式
    配置和其他节点统一
    启动后是孤儿节点

具体命令:

redis-server conf/redis-6385.conf
redis-server conf/redis-6386.conf

此时集群状态

加入集群

新节点依然采用cluster meet命令加入到现有集群中。在集群内任意节点执行cluster meet命令让6385和6386节点加入进来

redis-cli -p 6379 cluster meet 127.0.0.1 6385
redis-cli -p 6379 cluster meet 127.0.0.1 6386

  • 集群内新旧节点经过一段时间的ping/pong消息通信之后,所有节点会发现新节点并将它们的状态保存到本地

迁移槽和数据

槽是Redis集群管理数据的基本单位,首先需要为新节点制定槽的迁移计划,确定原有节点的哪些槽需要迁移到新节点。迁移计划需要确保每个节点负责相似数量的槽,从而保证各节点的数据均匀。计划图如下:

数据迁移过程是逐个槽进行的

具体流程图:

伪代码(通过pipeline来传递数据):

image-20221102003138822

或者使用 redis-trib.rb 中的reshard完成槽的分配

缩容集群

流程说明:
1)首先需要确定下线节点是否有负责的槽,如果是,需要把槽迁移到其他节点,保证节点下线后整个集群槽节点映射的完整性
2)当下线节点不再负责槽或者本身是从节点时,就可以通知集群内其他节点忘记下线节点,当所有的节点忘记该节点后可以正常关闭

流程图如下:

下线槽

迁移命令同样可以使用redis-trib的reshard命令

忘记槽

命令:

cluster forget {downNodeId}

注意:对于主从节点,要先下线从节点再下线主节点

参考资料

Redis~集群(分布理论、一致性哈希分区、虚拟槽分区、节点握手、集群通信、集群伸缩、请求路由、故障转移、集群维护)

Redis集群–Cluster–集群伸缩–过程/原理


文章作者: 银色回廊
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 银色回廊 !
评论
  目录