redis-cluster 集群原理介绍

参考文章：http://shift-alt-ctrl.iteye.com/blog/2285470
https://www.cnblogs.com/liyasong/p/redis_jiqun.html?utm_source=itdadao&utm_medium=referral#_label1

redis-cluster 集群发展史

3.0版本之前的redis是不支持集群的，那个时候，我们的redis如果想要集群的话，就需要一个中间件，然后这个中间件负责将我们需要存入redis中的数据的key通过一套算法计算得出一个值。然后根据这个值找到对应的redis节点，将这些数据存在这个redis的节点中。在取值的时候，同样先将key进行计算，得到对应的值，然后就去找对应的redis节点，从对应的节点中取出对应的值。这样做有很多不好的地方，比如说我们的这些计算都需要在系统中去进行，所以会增加系统的负担。还有就是这种集群模式下，某个节点挂掉，其他的节点无法知道。而且也不容易对每个节点进行负载均衡。

3.0版本之后的redis是支持集群的，官方推荐的集群方案为redis-cluster，即集群中有多个redis服务器节点，它们任何两个节点之间都是相互连通的。客户端可以与任何一个节点相连接，然后就可以访问集群中的任何一个节点。对其进行存取和其他操作。下面为redis-cluster架构图:

redis-cluster集群的工作方式

redis-cluster集群有16384个哈希槽（slot），其分布在该集群的所有节点中，哈希槽的作用是存储数据（即key和value）。当redis接受到key时，redis会根据crc16的算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。下图能直观的给出其操作的流程：

计算哈希槽时的特殊情况
我们都知道redis不像传统的关系型数据一样，有事务的回滚策略，redis为了保证性能，不提供事务的回滚，但是提供了事务的处理机制，即将多个redis命令放入到队列中，然后统一的进行原子性提交并执行，但是该事务处理机制有一个问题，就是得保证该事务中的命令处于同一个哈希槽中，如果按照原有的通过key值计算得到对应的哈希槽的方式，并不能保证不同的key处于同一个哈希槽中，这样事务的处理机制就将失效，针对此种情况，官方也给出了对应的方法，即当处理事务时，同一个事务机制中的命令生成的哈希槽不用key值来计算，而是分配一个tags标签来来计算哈希槽，这样就能保证同一事务中的命令处于同一个哈希槽中。

redis-cluster 节点间的通信

集群中的每个节点都有唯一的名字，称之为node ID,一个160位随机数字的16进制表示，在每个节点首次启动时创建。每个节点都将各自的ID保存在实例的配置文件中，此后将一直使用此ID，或者说只要配置文件不被删除，或者没有使用“CLUSTER RESET”指令重置集群，那么此ID将永不会修改。

集群通过node ID来标识节点，而不是使用IP + port，因为node可以修改它的IP和port，不过如果ID不变，我们仍然认定它是集群中合法一员。集群可以在cluster Bus中通过gossip协议来探测IP、port的变更，并重新配置。

node ID并不是与node相关的唯一信息，不过是唯一一个全局一致的。每个node还持有如下相关的信息，有些信息是关系集群配置的，其他的信息比如最后ping时间等。每个node也保存其他节点的IP、Port、flags（比如flags表示它是master还是slave）、最近ping的时间、最近pong接收时间、当前配置的epoch、链接的状态，最重要的是还包含此node上持有的hash slots。这些信息均可通过“CLUSTER NODES”指令开查看。

优点

redis-cluster是三个里性能最强大的 因为他使用去中心化的思想 使用hash slot方式 将16348个hash slot 覆盖到所有节点上 对于存储的每个key值 使用CRC16(KEY)&16348=slot 得到他对应的hash slot 并在访问key时就去找他的hash slot在哪一个节点上 然后由当前访问节点从实际被分配了这个hash slot的节点去取数据 节点之间使用轻量协议通信 减少带宽占用 性能很高 自动实现负载均衡与高可用 自动实现failover 并且支持动态扩展 官方已经玩到可以1000个节点 实现的复杂度低 总之个人比较喜欢这个架构 因为他的去中心化思想免去了proxy的消耗 是全新的思路
将数据自动切分split到多个节点的能力。
当集群中的一部分节点失效或者无法进行通讯时， 仍然可以继续处理命令请求的能力。

缺点

但是它也有一些不足 例如官方没有提供图形化管理工具 运维体验差 全手工数据迁移 并且自己对自己本身的redis命令支持也不完全等 但是这些问题 我觉得不能掩盖他关键的新思想所带来的的优势 随着官方的推进 这些问题应该都能在一定时间内得到解决 那么这时候去中心化思想带来的高性能就会表现出他巨大的优势
Redis 集群不支持那些需要同时处理多个键的 Redis 命令， 因为执行这些命令需要在多个 Redis 节点之间移动数据， 并且在高负载的情况下， 这些命令将降低Redis集群的性能， 并导致不可预测的行为。