Redis的分布式解决方案（redisson分布式）

Redis Cluster是Redis的分布式解决方案。当遇到内存、并发、流量等瓶颈时，就可以采用Cluster架构达到负载均衡目的。因为Redis Cluster是Redis3.0版本之后才有的，所以在Redis3.0版本之前，Redis分布式的解决方案一般有两种：

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

既然Redis已经为我们提供了分布式的解决方案Redis Cluster那么下面我们将详细介绍一下Redis Cluster的功能。

• 数据分布

Redis分布式集群首先要解决的问题就是把整个数据集按照分区规则映射到多个节点。所以下面我们介绍一下数据分区的规则。常见的分区规则有哈希分区和顺序分区两种。下表是这两种分区的对比。

看上图我们知道Redis Cluster采用的是哈希分区方式。所以下面我们重点介绍一下哈希分区的知识。

哈希分区主要有3种下面我们分别介绍一下它们3种的区别。

1.节点取余分区

使用特定的数据，例如Redis的键或者用户ID，在根据节点数量N使用公式:hash(key) % N计算出哈希值，用来决定数据映射到哪一个节点上。但这种分区有一个问题，就是当节点数量变化时，例如扩容或减少节点，数据节点映射关系都要重新计算。

2.一致性哈希分区

一致性哈希分区是为系统中的每个节点分配一个token，这些token构成了一个哈希环。数据读写执行节点查找操作时，先根据key计算hash值，然后顺时针找到第一个大于等于哈希值的token节点。

这种方式相比节点取余最大的好处是加入和删除节点只影响哈希环中相邻的节点，而对其它节点无任何影响。但这种分区也有它的弊端。下面我们看一下这种分区的弊端:

• 加减节点会造成哈希环中部分数据无法命中，需要手动处理或者忽略这部分数据，因此一致性哈希常常用于缓存场景。
• 当使用少量节点时，节点变化将大范围影响哈希环中的数据映射，因此这种方式不适合少量数据节点的分布式方案。
• 普通的一致性哈希分区在增减节点时需要增加一倍或减去一半节点才能保证数据和负载均衡。

3.虚拟槽分区

虚拟槽分区巧妙的使用了哈希空间，使用分散度良好的哈希函数把所有数据映射到一个固定范围的整数集合中，整数定义为槽。这个范围一般远远大于节点数。槽是集群内数据管理和迁移的基本单位。每个节点都会负责一定数量的槽。因为Redis Cluser采用的就是虚拟槽，所以下面重点介绍一下Redis的数据分区。

• Redis数据分区

Redis Cluser采用的是虚拟槽分区，所有的键根据哈希函数映射到0-16383整数槽内，计算公式:slot=CRC16(key) & 16383。每一个节点负责维护一部分槽以及槽所映射的键值数据。

Redis虚拟槽分区的特点:

• 解耦数据和节点之间的关系，简化了节点扩容和收缩难度。
• 节点自身维护槽的映射关系，不需要客户端或者代理服务维护槽分区元数据。
• 支持节点、槽、键之间的映射查询，用于数据路由、在线伸缩等场景。

• 集群功能限制

Redis集群相对于单机来说在功能上存在一些限制，下面我们看一下具体限制:

1.key批量操作支持有限。如mset、mget，目前只支持具有相同slot值的key执行批量操作。对于映射为不同的slot值的key由于mset、mget操作可能存在于多个节点上因此不被支持。

2.key事务操作支持有限。并且只支持多key在同一个节点上的事务操作，当多个key分布在不同的节点上时无法使用事务功能。

3.key作为数据分区的最小粒度，因此不能将一个大的键值对象如hash、list等映射到不同的节点。

4.不支持多数据库空间，单机下的Redis可以支持16个数据库，集群模式下只能使用一个数据库空间。即 db 0。

5.复制结构只支持一层，从节点只能复制主节点，不支持树状复制结构。

上述内容就是Redis Cluster的简单介绍，在下一篇中我们将介绍怎么搭建一个Redis集群。