pong|Redis高可用架构—Redis集群（Redis Cluster）详细介绍客户端|VMware

文章图片

文章图片

文章图片

文章图片

文章图片

文章图片

文章图片

文章图片

文章图片

文章图片

前面文章Redis高可用方案—主从（masterslave）架构?中我们了解了redis主从复制架构，知道了该模式的工作模式为提供多台redis服务，选择其中的一台作为master节点向外提供读写服务，剩下的作为slave节点从master节点复制数据，只向外提供读服务。并且在Redis高可用架构—哨兵（sentinel）机制详细介绍?中引入了Redis哨兵，实现了对所有redis节点的监控和master的自动故障转移。一般情况下来说，上面两种方式结合起来使用已经可以满足大部分的redis高可用场景，但它有一个很明显的缺点：只有一台master节点向外提供写服务，其他的slave节点只能提供读服务。所以，当写操作并发量很大的，无法缓解写操作的压力。针对这种场景， Redis在3.0版本中引入了Redis集群的部署架构。
什么是Redis集群Redis集群是一个提供在多个Redis节点之间共享数据的程序集。它并不像Redis主从复制模式那样只提供一个master节点提供写服务，而是会提供多个master节点提供写服务，每个master节点中存储的数据都不一样，这些数据通过数据分片的方式被自动分割到不同的master节点上。
为了保证集群的高可用，每个master节点下面还需要添加至少1个slave节点，这样当某个master节点发生故障后，可以从它的slave节点中选举一个作为新的master节点继续提供服务。不过当某个master节点和它下面所有的slave节点都发生故障时，整个集群就不可用了。这样就组成了下图中的结构模式：

Redis集群中的哈希槽Redis集群中引入了哈希槽的概念， Redis集群有16384个哈希槽，进行set操作时，每个key会通过CRC16校验后再对16384取模来决定放置在哪个槽，搭建Redis集群时会先给集群中每个master节点分配一部分哈希槽。比如当前集群有3个master节点， master1节点包含0~5500号哈希槽， master2节点包含5501~11000号哈希槽， master3节点包含11001~16384号哈希槽，当我们执行“set key value”时，假如 CRC16(key) % 16384 = 777 ，那么这个key就会被分配到master1节点上，如下图：

Redis集群中节点的通信既然Redis集群中的数据是通过哈希槽的方式分开存储的，那么集群中每个节点都需要知道其他所有节点的状态信息，包括当前集群状态、集群中各节点负责的哈希槽、集群中各节点的master-slave状态、集群中各节点的存活状态等。 Redis集群中，节点之间通过建立TCP连接，使用gossip协议来传播集群的信息。如下图：

所谓gossip协议，指的是一种消息传播的机制，类似人们传递八卦消息似的，一传十，十传百，直至所有人都知道这条八卦内容。 Redis集群中各节点之间传递消息就是基于gossip协议，最终达到所有节点都会知道整个集群完整的信息。 gossip协议有4种常用的消息类型：PING、PONG、MEET、FAIL 。