Redis 开发与运维Redis Cluster 集群

Posted 2021-06-29 木兮同学

文章目录

• 数据分布
• • 数据分布理论
  • Redis 数据分区
  • 集群功能限制
• 搭建集群
• • 准备节点
  • 节点握手
  • 分配槽
  • 用 redis-trib.rb 搭建集群
• 节点通信
• • 通信流程
  • Gossip 消息
  • 节点选择

---

Redis Cluster 是 Redis 的分布式解决方案，有效地解决了 Redis 分布式方面的需求。当遇到单机内存、并发、流量等瓶颈时，可以采用 Cluster 架构方案达到负载均衡的目的。之前，Redis 分布式方案一般有两种：

• 客户端分区方案，优点是分区逻辑可控，缺点是需要自己处理数据路由、高可用、故障转移等问题。
• 代理方案，优点是简化客户端分布数逻辑和升级维护便利，缺点是加重架构部署复杂度和性能损耗。

数据分布

数据分布理论

分布式数据库首先要解决把整个数据集按照分区规则映射到多个节点的问题，即把数据集划分到多个节点上，每个节点负责整体数据的一个子集。需要重点关注的是数据分区规则。常见的分区规则有哈希分区和顺序分区两种，由于 Redis Cluster 采用哈希分区规则，这里我们重点讨论哈希分区

• 节点取余分区

  • 使用特定的数据，如 Redis 的键或者用户ID，再根据节点数量 N 使用公式：hash(key) % N 计算出哈希值，用来决定数据映射到哪一个节点上。
  • 这种方案存在一个问题：当节点数量变化时，如扩容或搜索节点，数据节点映射关系需要重新计算，会导致数据的重新迁移。

• 一致性哈希分区

  • 实现思路是为系统中每个节点分配一个 token ，这些 token 构成一个哈希环。数据读写执行节点查找操作时，先根据 key 计算 hash 值，然后顺时针找到第一个大于等于该哈希值的 token 节点。
  • 这种方式相比节点取余最大的好处在于加入和删除节点只影响哈希环中相邻的节点，对其他节点无影响。但还存在几个问题：
    • 加减节点会造成哈希环中部分数据无法命中，需要手动处理或者忽略这部分数据，因此一致性哈希常用语缓存场景
    • 当使用少量节点时，节点变化将大范围影响哈希环中数据映射，因此这种方式不适合少量数据节点的分布式方案
    • 普通的一致性哈希分区在增减节点时需要增加一倍或减去一半节点才能保证数据和负载的均衡

• 虚拟槽分区

  • 虚拟槽分区巧妙地使用了哈希空间，使用分散度良好的哈希函数把所有数据映射到一个固定范围的整数集合中，整数定义为槽（slot）。这个范围一般远远大于节点数，比如 Redis Cluster 槽范围是 0 ~ 16383。
  • 槽是集群内数据管理和迁移的基本单位。采用大范围槽的目的是为了方便数据拆分和集群扩展，每个节点负责一定数量的槽。
  • 例如：假如当前集群有 5 个节点，则每个节点平均大约负责 3276 个槽。

Redis 数据分区

• Redis 采用虚拟槽分区，所有的键根据哈希函数映射到 0 ~ 16383 整数槽内，计算公式：slot = CRC16(key) & 16383。虚拟机槽的分区特点：
  • 解耦数据和节点之间的关系，简化了节点扩容和搜索难度
  • 节点自身维护槽的映射关系，不需要客户端或者代理服务维护槽分区元数据
  • 支持节点、槽、键之间的映射查询，用于数据路由、在线伸缩等场景

集群功能限制

• key 批量操作支持有限。如 mset、mget，目前只支持具有相同 slot 值的 key 执行批量操作。对于映射为不同 slot 值的 key，由于执行mset、mget 等操作可能存在于多个节点上，因此不被支持。
• key 事务操作支持有限。同理只支持多 key 在同一节点上的事务操作，当多个 key 分布在不同的节点上时无法使用事务功能。
• key 作为数据分区的最小粒度，因此不能将一个大的键值对象如 hash、list 等映射到不同的节点。
• 不支持多数据库空间。单机下的 Redis 可以支持 16 个数据库，集群模式下只能使用一个数据库空间，即 db 0。
• 复制结构只支持一层，从节点只能复制主节点，不支持嵌套树状复制结构。

---

搭建集群

准备节点

• Redis 集群节点数量至少为 6 个才能保证组成完整高可用的集群。每个节点需要开启配置 cluster-enabled yes，让 Redis 运行在集群模式下。
• 第一次启动时如果没有集群配置文件，它会自动创建一份，文件名称采用 cluster-config-file 参数项控制，建议采用 node-{port}.conf 格式定义。
  • 当集群内节点信息发生变化，如添加节点、节点下线，故障转移等，节点会自动保存集群状态到配置文件中。
  • Redis 自动维护集群配置文件，不要手动修改，防止节点重启时产生集群信息错乱。
• 集群配置文件记录了集群初始状态，这里最重要的是节点 ID，一个 40 位 16 进制字符串，用于唯一标识集群内一个节点。它不同于运行 ID，节点 ID 在集群初始化时只创建一次，节点重启时会加载集群配置文件进行重用。

节点握手

• 节点握手是指一批运行在集群模式下的节点通过 Gossip 协议彼此通信，达到感知对方的过程。节点握手是集群彼此通信的第一步，由客户端发起命令：cluster meet {ip} {port}
• 我们只需要在集群内任意节点上执行 cluster meet 命令加入新节点，握手状态会通过消息在集群内传播，这样其他节点会自动发现新节点并发起握手流程。可以执行 cluster nodes 命令确认 6 个节点都彼此感知并组成集群。
• 节点建立握手之后集群还不能正常工作，这时集群处于下线状态，所有的数据读写都被禁止。使用 cluster info 命令获取集群当前状态，输出内容看被分配的槽是 0，是因为目前所有的槽没有分配到节点，因此集群无法完成槽到节点的映射。

分配槽

• 通过 cluster addslots 命令为节点分配槽。将 16384 个slot 平均分配给 6379、6380、6381 三个节点。命令如下：

redis-cli -h 127.0.0.1 -p 6379 cluster addslots {0..5461}
redis-cli -h 127.0.0.1 -p 6380 cluster addslots {5462..10922}
redis-cli -h 127.0.0.1 -p 6381 cluster addslots {10923..16383}

• 目前还有三个节点没有使用，作为一个完整的集群，每个负责处理槽的节点应该具有从节点，保证当它出现故障时可以自动进行故障转移。
• 集群模式下，Redis节点角色分为主节点和从节点。首次启动的节点和被分配槽的节点都是主节点，从节点负责复制主节点槽信息和相关的数据。
• 使用 cluster replicate {nodeId} 命令让一个节点成为从节点。其中命令执行必须在对应的从节点上执行，nodeId 是要复制主节点的节点 ID。

用 redis-trib.rb 搭建集群

上面我们依照 Redis 协议手动建立一个集群。它由6个节点构成，3 个主节点负责处理槽和相关数据，3 个从节点负责故障转移。手动搭建集群便于理解集群建立的流程和细节，不过集群搭建需要很多步骤，当集群节点众多时，必然会加大搭建集群的复杂度和运维成本。因此Redis 官方提供了 redis-trib.rb 工具方便我们快速搭建集群。

• redis-trib.rb 介绍，它采用 Ruby 实现的 Redis 集群管理工具。内部通过 Cluster 相关命令帮我们简化集群创建、检查、槽迁移和均衡等常见运维操作，使用之前需要安装 Ruby 依赖环境。
• 准备节点，和之前配置内容一样，再启动所有节点
• 创建集群
  • 启动好 6 个节点之后，使用 redis-trib.rb create 命令完成节点握手和槽分配过程，节点列表顺序用于确定主从角色，先主节点之后是从节点，命令如下：

  redis-trib.rb create --replicas 1 127.0.0.1:6481 127.0.0.1:6482 127.0.0.1:6483 
  	127.0.0.1:6484 127.0.0.1:6485 127.0.0.1:6486
  

  • 命令执行后，会打印主从节点角色分配计划，同意这份计划之后输入 yes，它会开始节点握手和槽分配操作。这里要注意节点地址必须是不包含任何槽和数据的节点，否则会拒绝创建集群。
• 集群完整性检查，集群完整性指所有的槽都分配到存活的主节点上，只要 16384 个槽中有一个没有分配给节点则表示集群不完整。可以使用 redis-trib.rb check 命令检测之前创建的两个集群是否成功，check 命令只需要给出集群中任意一个节点地址就可以完成整个集群的检查工作。

---

节点通信

通信流程

• 在分布式存储中需要维护节点元数据信息的机制，所谓元数据是指：节点负责哪些数据，是否出现故障等状态信息。常见的元数据维护方式分为：集中式和 P2P 方式。
• Redis 集群采用 P2P 的 Gossip 协议，其工作原理就是节点彼此不断通信交换信息，一段时间后所有的节点都会知道集群完整的信息。
• 集群中每个节点通过一定规则挑选要通信的节点，每个节点可能知道全部节点，也可能仅知道部分节点，只要这些节点彼此可以正常通信，最终它们会达到一致的状态。当节点出故障、新节点加入、主从角色变化、槽信息变更等事件发生时，通过不断的 ping/pong 消息通信，经过一段时间后所有的节点都会知道整个集群全部节点的最新状态，从而达到集群状态同步的目的。

Gossip 消息

• Gossip 协议的主要职责就是信息交换。信息交换的载体就是节点彼此发送的 Gossip 消息，常用的 Gossip 消息可分为：ping 消息、pong 消息、meet 消息、fail 消息等。
  • meet 消息：用于通知新节点加入。消息发送者通知接收者加入到当前集群，meet 消息通信正常完成后，接收节点会加入到集群中并进行周期性的 ping、pong 消息交换。
  • ping 消息：集群内交换最频繁的消息，集群内每个节点每秒向多个其他节点发送 ping 消息，用于检测节点是否在线和交换彼此状态信息。ping 消息发送封装了自身节点和部分其他节点的状态数据。
  • pong 消息：当接收到 ping、meet 消息时，作为响应消息回复给发送方确认消息正常通信。pong 消息内部封装了自身状态数据。节点也可以向集群内广播自身的 pong 消息来通知整个集群对自身状态进行更新。
  • fail 消息：当节点判定集群内另一个节点下线时，会向集群内广播一个 fail 消息，其他节点接收到 fail 消息之后把对应节点更新为下线状态。
• 所有的消息格式划分为：消息头和消息体。消息头包含发送节点自身状态数据，接收节点根据消息头就可以获取到发送节点的相关数据。

节点选择

• 由于内部需要频繁地进行节点信息交换，而 ping/pong 消息会携带当前节点和部分其他节点的状态数据，势必会加重带宽和计算的负担。
• 选择发送消息的节点数量
  • 集群内每个节点维护定时任务默认每秒执行 10 次，每秒会随机选取 5 个节点找出最久没有通信的节点发送 ping 消息，用于保证 Gossip 信息交换的随机性。
• 消息数据量
  • 每个 ping 消息的数据量体现在消息头和消息体中，其中消息头主要占用的字段是 myslots[CLUSTER_SLOTS/8] ，占用 2 KB，这块空间占用相对固定。
  • 消息体携带数据量跟集群的节点数息息相关，更大的集群每次消息通信的成本也就更高，因此对于 Redis 集群来说并不是大而全的集群更好。

---

来源：《Redis 开发与运维》第 10 章 集群