跳至主要內容

Redis-Cluster 集群高可用

HFwas约 856 字大约 3 分钟

Redis-Cluster 集群高可用

Redis 之前的集群方案一般有两种:

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

Redis Cluster 优势

Redis Cluster 缺点

  • key 批量操作支持有限。如 mset、mget,目前只支持相同 slot 值的 key 执行批量操作
  • key 事务操作支持有限。同1,只支持相同 slot 值的 多key 的事务操作
  • key 作为数据分区的最小粒度,因此不能将一个大的键值对象如 hash、list 等映射到不同的节点
  • 不支持多数据空间。集群模式只能使用一个数据库空间,即 db0
  • 复制结构只支持一层,从节点只能复制主节点,不支持嵌套树状复制结构

分区规则

数据分区规则主要有以下两种:哈希分区和顺序分区,两种方式的对比如下:

分区方式特点
哈希分区1、离散度好
2、数据分布业务无关
3、无法顺序访问
顺序分区1、离散度易倾斜
2、数据分布业务相关
3、可顺序访问

哈希分区规则

节点取余分区

  • 使用特点的数据,使用 hash(key)%n 计算出哈希值,用来决定数据映射到哪一个节点。
  • 存在问题:
    • 当节点数量变化时,如扩容或者收缩节点,数据节点映射关系需要重新计算,会导致数据的重新迁移

一致性哈希分区

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

虚拟槽分区

  • Redis 采用的就是虚拟槽分区
  • 虚拟槽分区巧妙的使用了哈希空间,使用分散度良好的哈希函数把所有数据映射到一个固定范围的整数集合当中,整数定义为槽(slot)。
  • 这个范围一般远远大于节点数
  • 槽是集群内数据管理和迁移的基本单位,采用大范围槽的主要目的是为了方便数据拆分和集群扩展

虚拟槽为什么是16384

Redis Cluster 当中根据计算公式slot=CRC16(key)&16383,将所有的 key 映射到 0 ~ 16383整数槽当中。

评论
  • 按正序
  • 按倒序
  • 按热度
Powered by Waline v3.1.3