Redis:分片技术(Redis Cluster)详解

前面两篇文章,主从复制哨兵机制保障了高可用,就读写分离而言虽然slave节点扩展了主从的读并发能力,但是写能力存储能力是无法进行扩展,就只能是master节点能够承载的上限。如果面对海量数据那么必然需要构建master(主节点分片)之间的集群,同时必然需要吸收高可用(主从复制和哨兵机制)能力,即每个master分片节点还需要有slave节点,这是分布式系统中典型的纵向扩展(集群的分片技术)的体现;所以在Redis 3.0版本中对应的设计就是Redis Cluster。

目录

Redis集群

数据分片算法

1) 哈希求余

2) 一致性哈希

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

请求重定向

#Moved 重定向​编辑

#ASK 重定向

状态检测及维护

# Gossip协议

# Gossip协议的使用

# 基于Gossip协议的故障检测

# 通讯状态和维护

# 什么时候进行心跳?

# 发送哪些心跳数据?

# 如何处理心跳?

#将信息广播给其它节点?

故障恢复(Failover)

扩容&缩容

扩容

缩容

Redis集群

Redis 的集群就是引入多组 Master / Slave , 每一组 Master / Slave 存储数据全集的一部分, 从而构成一个更大的整体, 称为 Redis 集群 (Cluster).

  • Master1 和 Slave11 和 Slave12 保存的是同样的数据. 占总数据的 1/3
  • Master2 和 Slave21 和 Slave22 保存的是同样的数据. 占总数据的 1/3
  • Master3 和 Slave31 和 Slave32 保存的是同样的数据. 占总数据的 1/3

每个部分都可以称为是一个 分片 (Sharding). 如果全量数据进一步增加, 只要再增加更多的分片, 即可解决。


数据分片算法

Redis cluster 的核心思路是用多组机器来存数据的每个部分. 那么接下来的核心问题就是, 给定一个数 据 (⼀个具体的 key), 那么这个数据应该存储在哪个分片上? 读取的时候又应该去哪个分片读取?

1) 哈希求余

设有 N 个分片, 使用 [0, N-1] 这样序号进行编号.

针对某个给定的 key, 先计算 hash 值, 再把得到的结果 % N, 得到的结果即为分片编号.

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

缺点: 扩容时数据搬运多,开销大

2) 一致性哈希

第⼀步, 把 0 -> 2^32-1 这个数据空间, 映射到一个圆环上. 数据按照顺时针方向增长.第二步, 假设当前存在三个分片, 就把分片放到圆环的某个位置上.第三步, 假定有一个 key, 计算得到 hash 值 H, 那么这个 key 映射到哪个分片呢? 规则很简单, 就是从 H 所在位置, 顺时针往下找,找到的第一个分片,就是key所在的分片。

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

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


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

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

hash_slot = crc16(key) % 16384

16384 其实是 16 * 1024, 也就是 2^14 

相当于是把整个哈希值, 映射到 16384 个槽位上, 也就是 [0, 16383]. 然后再把这些槽位比较均匀的分配给每个分片. 每个分片的节点都需要记录自己持有哪些分片.

这⾥的分片规则是很灵活的. 每个分片持有的槽位也不一定连续. 每个分片的节点使用 位图 来表⽰自己持有哪些槽位. 对于 16384 个槽位来说, 需要 2048 个字 节(2KB) 大小的内存空间表示。


请求重定向

Redis cluster采用去中心化的架构,集群的主节点各自负责一部分槽,客户端如何确定key到底会映射到哪个节点上呢

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值