redis集群的相关问题

Redis主从模式

也称为主备模式。是一种高可用的方案。

一个主服务器可以有多个从服务器。
Redis的自身支持主从复制，只要更改下启动配置即可。从节点可以自动从主节点同步数据，主节点可以自动把读请求转给从节点从而实现读写分离减轻自身压力。但是，主节点如果完蛋了，从节点无法升级为主节点，client也无法自动切换，所以没有高可用的能力。

redis配置从服务器的过程
在这里插入图片描述

脑裂问题

如果只有master和slave两个角色，为防止主服务器假死后又复活，但是主从服务器通信又相互中断，这样彼此都不知道对方在提供服务，所以都自己提供服务。这种情况下需要引入哨兵。用户应用连接哨兵，并从哨兵获取提供服务的服务器链接。每个redis服务器，都访问哨兵来确定自己的状态。

不过引入哨兵的同时就要保证哨兵的高可用。即使不用哨兵，其实我们也能解决问题。那就是在设置一个lease。slave颁发的lease比master的lease+1。如果master复活，且他没有检测到从服务器，他就使用原有lease。应用服务永远向lease最大的服务器发送请求，并触发报警让人工介入。

Redis哨兵

Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)都没有实现自动进行主备切换。Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自动切换。

监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。
提醒(Notification):当被监控的某个 Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移(Automatic failover):当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master。

在这里插入图片描述
在Redis高可用架构中，Sentinel往往不是只有一个，而是有3个或者以上。目的是为了让其更加可靠，毕竟主和从切换角色这个过程还是蛮复杂的。

哨兵模式的配置如下，需要配置若个哨兵

<bean id="sentinelConfiguration" class="org.springframework.data.redis.connection.RedisSentinelConfiguration">  
        <property name="master">  
            <bean class="org.springframework.data.redis.connection.RedisNode"> 
                <!-- 这里填写主reids的机器名 -->
                <property name="name" value="${redis.host1.hostname}" /> 
            </bean>  
        </property>
        <property name="sentinels">  
            <!-- 这里配置哨兵 -->
            <set>  
                <bean class="org.springframework.data.redis.connection.RedisNode">  
                    <!-- 哨兵的服务器地址IP -->
                    <constructor-arg   value="${redis.host1.sentinels.host1}"></constructor-arg>  
                    <!-- 哨兵的服务器地址端口 默认是26379  -->
                    <constructor-arg   value="${redis.host1.sentinels.port1}"></constructor-arg>
                </bean>  
            </set> 
            <!-- 可以重复循环上面的节点，设置多个哨兵 --> 
        </property>  
    </bean>

redis cluster

Redis3.0版本之后支持Cluster。Redis集群至少要三主三丛，主从不需要配置，系统自动选择。
每个Redis集群中的节点都需要打开两个TCP连接。一个连接用于正常的给Client提供服务，比如6379，还有一个额外的端口（通过在这个端口号上加10000）作为数据端口，比如16379。第二个端口（本例中就是16379）用于集群总线，

(1)领着选举过程是集群中所有master参与,如果半数以上master节点与master节点通信超过(cluster-node-timeout),认为当前master节点挂掉.

(2)下列情况下整个集群不可用(cluster_state:fail),当集群不可用时,所有对集群的操作做都不可用，收到((error) CLUSTERDOWN The cluster is down)错误

如果集群任意master挂掉,且当前master没有slave，集群进入fail状。
如果进群超过半数以上master挂掉，无论是否有slave，集群进入fail状态.

客户端会可以对任意一个redis实例去发送命令，每个redis实例接收到命令，都会计算key对应的hash slot。然后告诉客户端。如果使用下面的指令登陆redis的shell，会实现自动的重定向。

#查看key对应的hash slot
cluster keyslot key
 
#连接客户端时加-c参数可以自动重定向
redis-cli -c

gossip协议

Gossip 算法又被称为反熵（Anti-Entropy），熵是物理学上的一个概念，代表杂乱无章，而反熵就是在杂乱无章中寻求一致，这充分说明了 Gossip 的特点：在一个有界网络中，每个节点都随机地与其他节点通信，经过一番杂乱无章的通信，最终所有节点的状态都会达成一致。每个节点可能知道所有其他节点，也可能仅知道几个邻居节点，只要这些节可以通过网络连通，最终他们的状态都是一致的，当然这也是疫情传播的特点。
简单的描述下这个协议，首先要传播谣言就要有种子节点。种子节点每秒都会随机向其他节点发送自己所拥有的节点列表，以及需要传播的消息。任何新加入的节点，就在这种传播方式下很快地被全网所知道。这个协议的神奇就在于它从设计开始就没想到信息一定要传递给所有的节点，但是随着时间的增长，在最终的某一时刻，全网会得到相同的信息。当然这个时刻可能仅仅存在于理论，永远不可达。

gossip需要很大的网络代价，而且达成最终一致性的速度很慢。但是对redis集群这种场景则正好适合。