Redis 集群模式

一、集群模式概述

Redis 中哨兵模式虽然提高了系统的可用性,但是真正存储数据的还是主节点和从节点,并且每个节点都存储了全量的数据,此时,如果数据量过大,接近或超出了 主节点 / 从节点机器的物理内存,就会出现严重的问题;

集群模式就是为了解决这个问题的,它通过引入更多的主节点和从节点,每一组主节点及其所对应的从节点存储了数据全集的一部分,多组这个的结构构成了一个更大的整体,这就是集群

如下图所示,假定引入了三组主从节点来存储全量数据,那么每组机器只需要存储全集的 1/3 即可,其中每组机器中的每个节点保存的数据内容是一样的,这样的一组机器(包含一个主节点和多个从节点)也称为一个分片;

此时,如果全量数据继续增加,就只需引入更多的分片即可;

二、数据分片算法

1. 哈希求余

设有 N 个分片,使用 [0,N-1] 来编号;

哈希求余就是针对给定的 key,先根据一个 hash 函数计算出 hash 值(例如使用 MD5 算法计算 hash 值),再把得到的结果进行 % N,得到的结果就是其所对应的分片编号;

优点:简单高效,数据分配均匀;

缺点:一旦需要进行扩容,N 就会改变,导致原有的映射规则被破坏(hash(key) % N),就需要让节点之间的数据相互传输,重新排列,以满足新的映射规则,此时需要搬运的数据量非常多,开销很大;

2. 一致性哈希算法

首先,把 [0,2^32-1] 这个数据空间,映射到一个圆环上,数据按照顺时针方向增长;

假设存在三个分片,如下图所示

假设有一个 key,通过 hash 函数计算得到 hash 值 H,那么这个 key 对应的分片就是从 H 所在位置,顺时针往下找,找到的第一个分片;

这就相当于,N 个分片的位置,把整个圆环分成了 N 个区间,key 的 hash 值落在某个区间内,就归对应区间管理;

当需要扩容时,原有分片在环上的位置不动,只需要在环上新安排一个分片位置即可;

优点:大大降低了扩容时数据搬运的规模,提高了扩容操作的效率;

缺点:数据分配不均匀(有的分片数据多,有的少,数据倾斜);

3. 哈希槽分区算法(Redis 采用)

为了解决上述搬运成本高 和 数据分配不均匀的问题,Redis cluster 引入了哈希槽 (hash slots) 算法;

hash_slot = crc16(key) % 16384

16384 = 16 * 1024 = 2 ^ 14,这就相当于把整个 hash 值,映射到 16384 个槽位上,即[0,16383]然后再把这些槽位比较均匀的分配给每个分片,同时每个分片的节点都要记录自己持有哪些分片;

比如有三个分片,则槽位的分配方式可能为:

  • 0 号分片:[0,5461],共 5462 个槽位
  • 1 号分片:[5462,10923],共 5462 个槽位
  • 2 号分片:[10924,16383],共 5460 个槽位

每个分片的节点使用 位图来表示自己持有哪些槽位,对于 16384 个槽位来说,需要 2048 个字节即 2 KB 大小的内存空间来表示;

当需要进行扩容时,比如新加一个 3 号分片,就可以针对原有的槽位进行重新分配,分配的结果可能为:

  • 0 号分片:[0,4095],共 4096 个槽位
  • 1 号分片:[5462,9557],共 4096 个槽位
  • 2 号分片:[10924,15019],共 4096 个槽位
  • 3 号分片:[4096,5461],[9558,10923],[15020,16383],共 4096 个槽位

在实际使用 Redis 集群分片的时候,不需要手动指定哪些槽位分配给某个分片,只需要告诉某个分片应该持有多少个槽位即可,Redis 会自动完成后续的槽位分配,以及对应的 key 搬运的工作;

为什么是 16384 个槽位呢?

Redis 官方的解释是:节点之间通过心跳包通信,心跳包中包含了该节点持有哪些 slots,这个是使用位图这样的数据结构表示的,表示 16384 (16k) 个 slots,需要的位图大小是 2KB,如果给定的 slots 数更多了,比如 65536 个了,此时就需要消耗更多的空间,8 KB 位图表示了,8 KB,对于内存来说不算什么,但是在频繁的网络心跳包中,还是⼀个不小的开销的;

另一方面,Redis 集群一般不建议超过 1000 个分片,所以 16k 对于最大 1000 个分片来说是足够用的,同时也会使对应的槽位配置位图体积不至于很大;

三、集群故障处理

1. 故障判定

集群中的所有节点,都会周期性的使用心跳包进行通信;

  • 当节点 A 给节点 B 发送 ping 包,B 就会给 A 返回一个 pang 包;每个节点,每秒钟,都会给一些随机的节点发起 ping 包,这样设定是为了避免在节点很多的时候,心跳包也非常多;
  • 若节点 A 给节点 B 发起 ping 包,B 不能如期回应时,此时 A 就会尝试重置和 B 的 tcp 连接,看能否连接成功,如果仍然连接失败,A 就会把 B 设为 PFAIL 状态(相当于主观下线);
  • 当A 判定 B 为 PFAIL 之后,会通过 redis 内置的 Gossip 协议,和其他节点进行沟通,向其他节点确认 B 的状态,(每个节点都会维护一个自己的 "下线列表",由于视角不同,每个节点的下线列表也不⼀定相同);
  • 此时 A 发现其他很多节点,也认为 B 为 PFAIL,并且数目超过总集群个数的一半,那么 A 就会把 B 标记成 FAIL (相当于客观下线),并且把这个消息同步给其他节点 (其他节点收到之后,也会把 B 标记成 FAIL)

至此 B 就被彻底判定为故障节点了;

若某部分节点宕机,有可能会引起整个集群宕机 (整个集群处于 fail 状态),主要有以下三种情况:

  • 某个分片上的主节点和所有从节点都挂了
  • 某个分片上的主节点挂了,并且没有从节点(可归纳为第一种)
  • 超过半数的主节点挂了(此时就无法完成投票选举主节点的工作了)

2. 故障迁移

在上述故障判定中,若 B 是从节点,则不需要进行故障迁移,若 B 是主节点,并假设 B 有两个从节点 C 和 D,此时就会由 从节点 C D 触发故障迁移(把从节点提拔为主节点);

故障迁移的具体步骤为:

  1. 从节点判定自己是否具有参选资格: 如果从节点和主节点已经太久没通信(此时认为从节点的数据和主节点差异太大了), 时间超过阈值, 就失去竞选资格;
    1. 具有资格的节点,比如 C 和 D,会先休眠一定时间,休眠时间 = 500ms 基础时间 + [0, 500ms] 随机时间 + 排名 * 1000ms,offset 的值越大,则排名会越靠前(越小);
    2. 比如 C 的休眠时间到了,C 就会给其他所有集群中的节点,进行拉票操作,但是只有主节点才有投票资格;
    3. 主节点就会把自己的票投给 C (每个主节点只有 1 票); 当 C 收到的票数超过主节点数目的一半, C 就会晋升成主节点; (C 自己负责执行 slaveof no one, 并且让 D 执行 slaveof C);
    4. 同时,C 还会把自己成为主节点的消息,同步给其他集群的节点;大家也都会更新自己保存的集群结构信息;

四、集群扩容

  1. 把新的主节点加入到集群

    redis-cli --cluster add-node (新的主节点的ip地址和端口号) (集群中任意节点的ip地址和端口号)

  2. 重新分配 slots

    redis-cli --cluster reshard (集群中任意节点的ip地址和端口号)

  3. 给新的主节点添加从节点

    redis-cli --cluster add-node (新的从节点的ip地址和端口号) (集群中任意节点的ip地址和端口号) --cluster-slave --cluster-master-id (新的主节点的 nodeId)

相关推荐
The_Ticker1 小时前
CFD平台如何接入实时行情源
java·大数据·数据库·人工智能·算法·区块链·软件工程
Elastic 中国社区官方博客1 小时前
Elasticsearch 开放推理 API 增加了对 IBM watsonx.ai Slate 嵌入模型的支持
大数据·数据库·人工智能·elasticsearch·搜索引擎·ai·全文检索
企鹅侠客1 小时前
ETCD调优
数据库·etcd
Json_181790144801 小时前
电商拍立淘按图搜索API接口系列,文档说明参考
前端·数据库
煎饼小狗1 小时前
Redis五大基本类型——Zset有序集合命令详解(命令用法详解+思维导图详解)
数据库·redis·缓存
永乐春秋1 小时前
WEB-通用漏洞&SQL注入&CTF&二次&堆叠&DNS带外
数据库·sql
打鱼又晒网2 小时前
【MySQL】数据库精细化讲解:内置函数知识穿透与深度学习解析
数据库·mysql
大白要努力!2 小时前
android 使用SQLiteOpenHelper 如何优化数据库的性能
android·数据库·oracle
tatasix3 小时前
MySQL UPDATE语句执行链路解析
数据库·mysql
秋意钟3 小时前
缓存雪崩、缓存穿透【Redis】
redis