Redis篇-集群与核心原理

集群方案

哨兵模式

在redis3.0以前的版本要实现集群一般是借助哨兵sentinel工具来监控master节点的状态，如果master节点异常，则会做主从切换，将某一台slave作为master，哨兵的配置略微复杂，并且性能和高可用性等各方面表现一般，特别是在主从切换的瞬间存在访问瞬断的情况，而且哨兵模式只有一个主节点对外提供服务，没法支持很高的并发，且单个主节点内存也不宜设置得过大，否则会导致持久化文件过大，影响数据恢复或主从同步的效率。

leader选举流程

与下文集群选举类似。

高可用集群模式

由多个主从节点群组成的分布式服务器群，它具有复制、高可用和分片特性。Redis集群不需要sentinel哨兵也能完成节点移除和故障转移的功能。需要将每个节点设置成集群模式，这种集群模式没有中心节点，可水平扩展，据官方文档称可以线性扩展到上万个节点(官方推荐不超过1000个节点)。redis集群的性能和高可用性均优于之前版本的哨兵模式，且集群配置非常简单。

注意: 当某个key确定存储在哪个集群节点且此节点不可用时，必须等待此节点新的master产生后才能写入，而不能写入其它节点。但是并不影响其它集群节点的存储。

集群选举流程

1. slave发现自己的master变为FAIL。
2. 将自己记录的集群currentEpoch（选举周期）加1，并广播FAILOVER_AUTH_REQUEST 信息。
3. 其他节点收到该信息，只有master响应，判断请求者的合法性，并发送FAILOVER_AUTH_ACK，对每一个epoch只发送一次ack（确认字符，只会响应第一个，后续的salve不再响应）。
4. 尝试failover的slave收集master返回的FAILOVER_AUTH_ACK。
5. slave收到超过半数master的ack后（若所有salve的ack都未超过半数，将重新进行选举，且currentEpoch++），将自己切换为Master(这里解释了集群为什么至少需要三个主节点，如果只有两个，当其中一个挂了，只剩一个主节点是不能选举成功的)。
6. 广播Pong消息通知其他集群节点，这个集群其它的salve会将自己原来的master切换为新的master。

集群与哨兵模式的比较

• 哨兵模式为单master模式，性能有限，最高QPS只能达到10万（redis单节点QPS为5-10万）。而集群模式不受此限制
• 哨兵模式下，若master出现故障时，其它命令必须等待新的master产生才可继续进行。而集群模式下，当某个key确定存储在哪个集群节点且此节点不可用时，必须等待此节点新的master产生后才能写入，而不能写入其它节点，但是并不影响其它key在其它集群节点的存储。

高可用集群数据分片原理

Redis Cluster 将所有数据划分为 16384 个 slots(槽位)，每个节点负责其中一部分槽位。槽位的信息存储于每个节点中。

当 Redis Cluster 的客户端来连接集群时，它也会得到一份集群的槽位配置信息并将其缓存在客户端本地。这样当客户端要查找某个 key 时，可以直接定位到目标节点。

同时因为槽位的信息可能会存在客户端与服务器不一致的情况，还需要纠正机制来实现槽位信息的校验调整。

槽位定位算法

Cluster 默认会对 key 值使用 crc16 算法进行 hash 得到一个整数值，然后用这个整数值对 16384 进行取模来得到具体槽位。

跳转重定位

当客户端向一个错误的节点发出了指令，该节点会发现指令的 key 所在的槽位并不归自己管理，这时它会向客户端发送一个特殊的跳转指令携带目标操作的节点地址，告诉客户端去连这个节点去获取数据。客户端收到指令后除了跳转到正确的节点上去操作，还会同步更新纠正本地的槽位映射表缓存，后续所有 key 将使用新的槽位映射表。

Jedis数据分片源码分析

每个redis节点的slot信息在JedisCluster实例化的时候就会从服务端获取，并缓存到客户端。源码位于redis.clients.jedis.JedisClusterConnectionHandler#initializeSlotsCache方法中。

关于槽点的计算源码，以redis.clients.jedis.JedisCluster#set(java.lang.String, java.lang.String)为例。

	public String set(final String key, final String value) {
        return (String)(new JedisClusterCommand<String>(this.connectionHandler, this.maxAttempts) {
            public String execute(Jedis connection) {
                return connection.set(key, value);
            }
        }).run(key);
    }

JedisClusterCommand

	public JedisClusterCommand(JedisClusterConnectionHandler connectionHandler, int maxAttempts) {
        this.connectionHandler = connectionHandler;
        this.maxAttempts = maxAttempts;
    }

    public abstract T execute(Jedis var1);

    public T run(String key) {
        return this.runWithRetries(JedisClusterCRC16.getSlot(key), this.maxAttempts, false, (JedisRedirectionException)null);
    }

JedisClusterCRC16

	public static int getSlot(String key) {
        if (key == null) {
            throw new JedisClusterOperationException("Slot calculation of null is impossible");
        } else {
            key = JedisClusterHashTagUtil.getHashTag(key);
            //对16383取模运算
            return getCRC16(key) & 16383;
        }
    }

Redis集群节点间的通信机制

redis cluster节点间采取gossip协议进行通信。

维护集群的元数据有两种方式：集中式和gossip

集中式

优点在于元数据的更新和读取，时效性非常好，一旦元数据出现变更立即就会更新到集中式的存储中，其他节点读取的时候立即就可以立即感知到；不足在于所有的元数据的更新压力全部集中在一个地方，可能导致元数据的存储压力。

应用：

zookeeper集群，redis哨兵模式，redis主从模式。

gossip

去中心化，redis集群没有中心节点。

gossip协议包含多种消息，包括ping，pong，meet，fail等等。

• ping：每个节点都会频繁给其他节点发送ping，其中包含自己的状态还有自己维护的集群元数据，互相通过ping交换元数据；
• pong: 返回ping和meet，包含自己的状态和其他信息，也可以用于信息广播和更新；
• fail: 某个节点判断另一个节点fail之后，就发送fail给其他节点，通知其他节点，指定的节点宕机了。
• meet：某个节点发送meet给新加入的节点，让新节点加入集群中，然后新节点就会开始与其他节点进行通信，不需要发送形成网络的所需的所有CLUSTER MEET命令。发送CLUSTER MEET消息以便每个节点能够达到其他每个节点只需通过一条已知的节点链就够了。由于在心跳包中会交换gossip信息，将会创建节点间缺失的链接。

gossip优点

元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新，有一定的延时，降低了压力；缺点在于元数据更新有延时可能导致集群的一些操作会有一些滞后。