013.Redis Cluster架构原理

1. Redis单master的瓶颈

• master节点的数据和slave节点的数据是一模一样的，master节点的最多能容纳多少数据量，slave节点也就只能容纳这么多数据
• 当数据量超过master的内存，redis会使用LRU算法清除部分数据
• 如果确实要容纳更多的数据量，redis主从架构是无法解决这个问题的

2. Redis Cluster架构原理

2.1 Redis Cluster架构概述

Redis Cluster是Redis的分布式解决方案，在3.0版本正式推出，解决单master架构的内存、并发、流量等瓶颈，以达到负载均衡的目的。

• 每个master负责整个集群的一部分数据，每个节点负责数据多少可能不一样
• 每个master的角色是对等的
• 每个master节点都可以有N个slave节点，当一个master节点挂掉后，它的其中一个slave节点升级为master
• redis cluster已经自动具备了主从复制能力，也就是说，我们不需要手动再去搭建主从+sentinel架构
• redis cluster适用于海量数据、高并发、高可用场景

2.2 Hash Slot算法

(1) 分布式存储的数据分配算法

• 按照顺序存储

  • 与业务相关，例如商品信息存在A节点，用户信息存在B节点，每个节点的数据可以排序
  • 容易造成数据倾斜
  • 代表产品：HBase

• 散列存储

  • 离散度好，数据均匀分布，每个节点的数据量大致相同

  • 业务无关

  • 无法顺序访问

  • 代表产品：Redis Cluster

分布式存储的hash算法演进

(2) hash算法

• 优点

  • 简单

• 问题

  • 一旦某个master宕机，就需要调整hash算法，所有的数据都需要重新计算取模(由对3取模变成对2取模)，然后重新分配数据
  • 发生这种故障时，在数据未重新分配之前，由于更换了hash算法，导致大部分的请求都无法正确的拿到数据，从而不得不去访问数据库，在高并发场景下，这样是不能接受的，所以目前分布式缓存不再使用此种算法分配数据

• 适用场景

  常用于数据库的分库分表规则，采用预分区的方式，提前根据数据量规划好分区数，保证可支撑未来一段时间的数据量

• 扩容方案

  通常采用翻倍扩容，避免数据映射全部被打乱导致全量迁移

(3) 一致性hash算法

• 实现思路
  • 每个节点被预先分配一个token(可以理解为它管理的hash值的边界)，多个节点管理范围为[0, 2^32]的hash值范围
  • 数据读写时，先根据key求hash值，然后就知道此hash值在哪段范围内
  • 顺时针找到的节点就是其数据存储的节点
• 问题
  • 加减节点会造成哈希环中部分数据(1/N的数据量，N为节点个数)无法命中，当一个master挂掉之后，例如master1挂掉，那么当请求从master1获取数据时，是获取不到的,于是继续顺时针去master2、master0获取数据，当然也是获取不到的，需要手动处理这些无法命中的数据
  • 节点数量越多，增减节点带来的影响越小，因此不适用与集群中只有少量节点的情况
  • 容易造成数据热点问题
• 扩容方案
  • master的增减，需要增加一倍或者减少一倍，才能保证数据和负载的均衡

(4) 优化后的一致性hash算法

• 给master节点之间增加了均匀分布的虚拟节点
• 如果某个区间内有大量的数据，顺时针找到的就是其他的虚拟节点，这样每个区间内的数据都会均匀的分配到不同的master中去

(5) redis的hash slot算法

• 实现原理

  • Redis Cluster使用16384个槽(slot)来管理一段整数集合(hash值)，slot是集群内数据管理和迁移的基本单位

  • 每个master节点负责管理一部分slot，例如有5个节点，那个每个节点管理大约3276个槽

  • 对每个key使用CRC32算法进行hash得到一个整数值，然后使用hash值对16384进行取模，得到此数据应该分配到的slot编号，配置该slot即可被该slot的master管理

  • 每个master管理的slot的信息就缓存在本地，客户端连接集群时，会获取集群slot配置信息，从而通过key精确找到slot所在的节点

  • 可以强制指定某个key挂在指定的slot上

• 优点

  • 解耦数据和节点之间的关系，简化了节点扩容和收缩难度，增加一个master，就让其他的master分一部分slot给新来的master管理，移除一个master，就把这个master管理的slot分配给其他的master

  • 某个master挂掉，不影响整个集群，因为请求是到slot，而不是到master，但在slot迁移完成之前，请求到挂掉的节点也是不行的

  • slot迁移的过程是很快的

  • 节点自身维护slot的映射关系，无需人为管理

  • 支持槽、节点、key之间的映射关系查询