redis 集群_Redis杂谈 三：Redis集群数据分片方式

     上篇文章讲到网络带宽和机器内存大小是制约Redis性能的主要瓶颈。相比于提升网络带宽，通过集群部署Redis来增加可用内存大小，进行数据分片存储，是一种更加有效的提升Redis性能的方式。将数据切分，分散的存储在Redis集群中的各个机器内存中即数据分片存储。那么应该怎么来实现Redis集群？如何保证数据分片时，数据能均匀的分布在集群中的机器中？

    在Redis 3.0发布以前，由于Redis官方没有提供集群部署解决方案，通常使用 Twemproxy 代理或者基于一致性Hash算法实现Redis集群部署、数据分片。从Redis 3.0开始，Redis官方推出了基于Hash槽的Redis集群解决方案。

• 基于一致性Hash算法的解决方案

---

    一致性Hash算法核心思想是将集群中的机器组织成一个逻辑上的hash环，hash环上的一个节点代表集群中一台机器。当有数据写入时，通过Hash算法计算出redis key所在hash环的区间，然后将redis value顺时针写入最近的机器节点。

通过hash算法计算，key1在Node1和Node2区间，key2在Node2和Node3区间，key3 - key6在Node3和Node1区间。key1在hash环上顺时针离的最近节点是Node2，key1对应的redis value写入Node2节点。以此类推key2-key6对应的redis value写入相应的节点。

    在生产环境中，Redis机器数量是有限的，在hash环上有可能机器节点分布不均匀，导致数据分片时数据分布不均匀，即某一台机器节点存储的数据量特别大，其他机器存储的数据量很小。例如Node1存储了key2、key3、key4、key5、key6四个key对应的redis value，Node2和Node3只存储了一个key对应的redis value。

    为了验证该缺陷，本地启动4个redis进程(同一个ip，不同端口)来模拟redis集群。

向模拟的集群中写入10w数据，数据分布如下：

可以看到大量数据写入到127.0.0.1:6374节点，导致严重的数据倾斜。

    通过在has环上引入虚拟节点可解决数据倾斜的问题。虚拟节点和物理节点存在一种映射关系，逻辑上存储在虚拟节点的key，实际存储在虚拟节点对应的物理节点上。

    上图引入了虚拟节点。按照一致性hash算法计算，key3应存储在虚拟节点Node1上，由于虚拟节点Node1映射物理节点Node1，所以key3实际物理存储在物理节点Node1上。以此类推key4存储在Node2上，key5存储在Node3上。

在模拟的集群中，每个物理节点引入5个虚拟节点，向模拟的集群中写入10w数据，数据分布如下：

可以看到数据相对均匀的分布在4个节点中。

• 基于代理的解决方案

---

    基于一致性hash算法虽然能对redis集群进行数据分片，但是需要具备一定的技术能力才能实现，技术实现门槛较高。推特提供了一种成熟的代理中间件-Twemproxy，应用程序通过直连Twemproxy代理，无需关心redis集群具体细节。Twemproxy提供三种分片算法，包括一致性哈希算法、随机分配、求模取余。(Codis也是一种代理方案，不在单独介绍)

    Twemproxy需要单独部署成一个集群，集群中每台Twemproxy代理机器都连接着redis集群，应用程序访问Twemproxy集群中任意一台机器都可以访问到整个redis集群。由于引入了Twemproxy代理集群，增加了系统的维护成本，同时也对系统的高可用性带来了新的挑战。

• 基于Redis Cluster的解决方案

---

    Redis 3.0之后，Redis官方提供了集群解决方案。Redis-Cluster预设16384哈希槽(solt)，Redis集群中的每台机器维护一部分solt。首先算出solt位置[CRC16(key) % 16384]，然后找到solt所在机器，进行数据读写。

    Redis Cluster采用无中心结构，每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接。理论上连接集群中的任意一台机器，通过moved跳转，能访问到整个集群的数据。当Redis集群扩容或缩容时，客户端通过Ask机制，能够找到数据所在新的solt位置。

    在完成了集群数据分片之后，如何保证集群的高可用性成为了一个新的问题，下一节将会介绍 Redis Sentinel是如何保证Redis集群的高可用性的。