Redis集群研究和实践（基于redis 3.0.5）-1

look_w

前言redis 是我们目前大规模使用的缓存中间件，由于它强大高效而又便捷的功能，得到了广泛的使用。现在的2.x的稳定版本是2.8.19,也是我们项目中普遍用到的版本。
redis在年初发布了3.0.0,官方支持了redis cluster,也就是集群。至此结束了redis 没有官方集群的时代，之前我们用redis cluster用的最多的应该是twitter 发布的Twemproxy( )
还有就是豌豆荚开发的codis ( )
这2个我会在后续去使用它们。下面的文字，我尽量用通熟易懂的方式来阐述。

redis cluster 理论知识截止写这篇文章前，redis 3.x的最新版本是3.0.5。今天的学习和实践就是用这个版本。

Redis Cluster设计要点redis cluster在设计的时候，就考虑到了去中心化，去中间件，也就是说，集群中的每个节点都是平等的关系，都是对等的，每个节点都保存各自的数据和整个集群的状态。每个节点都和其他所有节点连接，而且这些连接保持活跃，这样就保证了我们只需要连接集群中的任意一个节点，就可以获取到其他节点的数据。
那么redis 是如何合理分配这些节点和数据的呢？
Redis 集群没有并使用传统的一致性哈希来分配数据，而是采用另外一种叫做哈希槽 (hash slot)的方式来分配的。redis cluster 默认分配了 16384 个slot，当我们set一个key 时，会用CRC16算法来取模得到所属的slot，然后将这个key 分到哈希槽区间的节点上，具体算法就是：CRC16(key) % 16384。
注意的是：必须要3个以后的主节点，否则在创建集群时会失败，我们在后续会实践到。
所以，我们假设现在有3个节点已经组成了集群，分别是：A, B, C 三个节点，它们可以是一台机器上的三个端口，也可以是三台不同的服务器。那么，采用哈希槽 (hash slot)的方式来分配16384个slot 的话，它们三个节点分别承担的slot 区间是：

• 节点A覆盖0－5460;
• 节点B覆盖5461－10922;
• 节点C覆盖10923－16383.

如下图所示：

那么，现在我想设置一个key ,比如叫my_name:
set my_name yangyi按照redis cluster的哈希槽算法：CRC16('my_name')%16384 = 2412。 那么就会把这个key 的存储分配到 A 上了。
同样，当我连接(A,B,C)任何一个节点想获取my_name这个key时，也会这样的算法，然后内部跳转到B节点上获取数据。
这种哈希槽的分配方式有好也有坏，好处就是很清晰，比如我想新增一个节点D，redis cluster的这种做法是从各个节点的前面各拿取一部分slot到D上，我会在接下来的实践中实验。大致就会变成这样：

• 节点A覆盖1365-5460
• 节点B覆盖6827-10922
• 节点C覆盖12288-16383
• 节点D覆盖0-1364,5461-6826,10923-12287

同样删除一个节点也是类似，移动完成后就可以删除这个节点了。
所以redis cluster 就是这样的一个形状：