浅谈集群版Redis和Gossip协议，mybatis底层原理面试

业内Codis配合LVS等多种做法实现Redis集群的方案有很多都应用到生成环境中，表现都还不错，主要是官方集群版本在Redis3.0才出现，对其稳定性如何，很多公司都不愿做小白鼠，不过事实上经过迭代目前已经到了Redis5.x版本，官方集群版本还是很不错的，至少笔者这么认为。

• 服务端分片的官方集群版本

官方版本区别于上面的Codis和Twemproxy，实现了服务器层的Sharding分片技术，换句话说官方没有中间层，而是多个服务结点本身实现了分片，当然也可以认为实现sharding的这部分功能被融合到了Redis服务本身中，并没有单独的Sharding模块。

之前的文章也提到了官方集群引入slot的概念进行数据分片，之后将数据slot分配到多个Master结点，Master结点再配置N个从结点，从而组成了多实例sharding版本的官方集群架构。

Redis Cluster 是一个可以在多个 Redis 节点之间进行数据共享的分布式集群，在服务端，通过节点之间的特殊协议进行通讯，这个特殊协议就充当了中间层的管理部分的通信协议，这个协议称作Gossip流言协议。

分布式系统一致性协议的目的就是为了解决集群中多结点状态通知的问题，是管理集群的基础。

如图展示了基于Gossip协议的官方集群架构图：

注:图片来自网络

2.Redis Cluster的基本运行原理

• 结点状态信息结构

Cluster中的每个节点都维护一份在自己看来当前整个集群的状态，主要包括：

1. 当前集群状态

2. 集群中各节点所负责的slots信息，及其migrate状态

3. 集群中各节点的master-slave状态

4. 集群中各节点的存活状态及不可达投票

也就是说上面的信息，就是集群中Node相互八卦传播流言蜚语的内容主题，而且比较全面，既有自己的更有别人的，这么一来大家都相互传