(四)分布式缓存——Redis分片集群

分布式缓存——Redis分片集群:

一、分片集群:

Redis使用主从集群后,虽然解决了高并发读的问题,但是主从的数据同步的性能也需要提升,其中一个提升就是redis点节点的内存不要设置太高,否则RDB的持久化或者是全量同步的时候,就会导致大量的IO操作,降低了性能。

但是单节点的内存降低,这个时候如果要存储海量的数据,又显得无能为力。
而且主从集群解决了高并发读的问题,那如果要高并发的写,又该怎么办?

以上两个问题,就需要使用分片集群来解决。

1、分片集群特征:

  1. 集群中有多个master,每个master保存不同数据
  2. 每个master都可以有多个slave节点
  3. master之间通过ping监测彼此健康状态,因此这些master也充当了哨兵。
  4. 客户端请求可以访问集群任意节点,最终都会被转发到正确节点
    在这里插入图片描述

二、散列插槽:

1、散列插槽:

节点如果发生变动,散列插槽也会自动进行更新。

散列插槽如何实现 客户端请求可以访问集群任意节点,最终都会被转发到正确节点

  1. Redis会把每一个master节点映射到0~16383共16384个插槽(hash slot)上,查看集群信息时就能看到:
    在这里插入图片描述
  2. 数据key不是与节点绑定,而是与插槽绑定。redis会根据key的有效部分计算插槽值,分两种情况:
    2.1 key中包含"{}",且“{}”中至少包含1个字符,“{}”中的部分是有效部分
    2.2 key中不包含“{}”,整个key都是有效部分

例如:key是num,那么就根据num计算,如果是{itcast}num,则根据itcast计算。计算方式是利用CRC16算法得到一个hash值,然后对16384取余,得到的结果就是slot值。
在这里插入图片描述

2、总结:

2.1 Redis如何判断某个key应该在哪个实例?

将16384个插槽分配到不同的实例
根据key的有效部分计算哈希值,对16384取余
余数作为插槽,寻找插槽所在实例即可

2.2 如何将同一类数据固定的保存在同一个Redis实例?

这一类数据使用相同的有效部分,例如key都以{typeId}为前缀

三、集群伸缩:

1、集群伸缩:

集群必须能够动态地添加节点或者删除节点。

2、添加节点:

redis-cli --cluster提供了很多操作集群的命令,可以通过下面方式查看:
在这里插入图片描述在这里插入图片描述添加节点,需要两部分参数:
new_host:new_port:添加的节点ip和端口
existing_host:existing_port:集群中已经有的节点的ip和端口

默认情况下添加的节点为主节点,如果要让它为从节点,则需要使用参数–cluster-slave和–cluster-master-id

四、故障转移:

分片集群虽然没有单独出来的哨兵,但它也具备故障修复的功能;
在这里插入图片描述在这里插入图片描述

五、RedisTemplate访问分片集群:

在这里插入图片描述

### Redis 分片集群中的一致性哈希实现及原理 Redis 分片集群并未直接采用传统意义上的一致性哈希算法,而是基于 **哈希槽(Hash Slot)** 的概念实现了类似的机制。以下是关于其设计和工作方式的具体分析: #### 1. 哈希槽的设计与作用 Redis 集群定义了固定数量的哈希槽(共 16384 个),每个键通过 CRC16 校验后对 16384 取模计算得出所属的槽号[^2]。这些槽被分布到各个节点上,从而完成数据的分片存储。 这种设计的核心优势在于简化了数据管理和迁移操作: - 数据位置由槽唯一决定,无需额外维护复杂的映射表。 - 当需要扩展或缩减节点时,只需重新分配部分槽即可,减少了全局调整的成本。 #### 2. 为何未完全采纳一致性哈希? 尽管一致性哈希能够有效减少因节点增减而导致的数据重分布量,但在实际应用中有以下几个局限性使得 Redis 放弃了这一方案: - **复杂度较高**:传统的带虚拟节点的一致性哈希虽然提高了均衡性和稳定性,但也增加了系统复杂度,尤其是在大规模动态环境中管理大量虚拟节点变得困难[^5]。 - **性能开销较大**:每次查找都需要遍历整个哈希环找到最近顺时针方向上的节点,相比简单的取模运算效率更低。 - **控制粒度过粗**:如果仅依靠少量物理节点划分区域,则难以精确调控每份资源占比;而增加更多虚拟节点又可能引发上述提到的各种麻烦。 因此,在综合考虑之后,Redis 设计团队选择了更为直观高效的 “哈希槽” 方法作为替代品。 #### 3. Hash Slot vs Consistent Hashing 两者之间存在显著差异如下所示: | 特性 | 哈希槽 (Hash Slot) | 一致性哈希 (Consistent Hashing) | |-------------------|-----------------------------------------|-------------------------------------| | 总数 | 固定为 16384 | 动态可变 | | 计算逻辑 | 使用 `CRC16` 对 key 进行散列并取余 | 将所有对象及其副本映射至大小为 \(2^{32}\) 的圆圈上 | | 平衡策略 | 明确指定哪些 slots 属于某个 master-slave pair | 自动形成闭环结构并通过指针指向下一个 server | | 扩展难度 | 较低 | 中等到高 | 从表格可以看出,hash slot 更加轻量化且易于理解实施,特别适用于像 redis 这样追求极致速度的应用场合。 #### 4. 实际案例中的表现对比 假设当前有一个三台服务器组成的简单分布式缓存服务 S={s0,s1,s2} ,下面分别展示两种技术如何处理新增一台设备 s3 后的情况: ##### A. Traditional Modulo Approach: 假如原始规则是以 keyspace size mod N 来定位目标机器的话,那么一旦总数目发生变化就会引起几乎全部记录失效. ##### B. With Virtual Nodes Applied In CHA: 即使如此精心布置过的体系依旧不可避免地要经历一定程度范围内的变动;不过由于引入了VN的缘故,受影响的比例相对较小一些罢了. 相比之下,"slots" 方案则显得格外优雅简洁——只需要把那几千条涉及的相关 entries 移交给新成员就可以了! --- ```python def calculate_slot(key): """Calculate the hash slot for a given key.""" import crc16 return crc16.crc16xmodem(key.encode()) % 16384 print(calculate_slot("my_key")) # Example usage demonstrating how to compute which slot 'my_key' belongs to. ``` 以上代码片段展示了如何利用 Python 编程语言快速估算任意字符串形式的关键字应该归属哪一个具体的编号区间之内。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值