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之间的映射关系查询
