redis 集群模式原理

一、Redis分布式扩展之Redis Cluster方案

主从切换的过程中会丢失数据，因为只有一个master，只能单点写，没有解决水平扩容的问题。而且每个节点都保存了所有数据，一个是内存的占用率较高，另外就是如果进行数据恢复时，非常慢。而且数据量过大对数据IO操作的性能也会有影响。所以我们同样也有对Redis数据分片的需求，所谓分片就是把一份大数据拆分成多份小数据，在3.0之前，我们只能通过构建多个redis主从节点集群，把不同业务数据拆分到不冉的集群中，这种方式在业务层需要有大量的代码来完成数据分片、路由等工作，导致维护成本高、增加、移除节点比较繁琐。Redis3.0之后引入了Redis Cluster集群方案，它用来解决分布式扩展的需求，同时也实现了高可用机制。

1.Redis Cluster架构

一个Redis Cluster由多个Redis节点构成，不同节点组服务的数据没有交集，也就是每个一节点组对应数据sharding的一个分片。节点组内部分为主备两类节点，对应master和slave节点。两者数据准实时一致，通过异步化订的主备复制机制来保证。一个节点组有且只有一个master节点，同时可以有0到多个slave节点，在这个节点组中只有master节点对用户提供些服务，读服务可以由master或者slave提供。
如图中，包含三个master节点以及三个master对应的slave节点，一般一组集群至少要6个节点才能保证完整的高可用。其中三个master会分配不同的slot（表示数据分片区间），当master出现故障时，slave会自动选举成为master顶替主节点继续提供服务。

2.关于gossip协议

在整个redis cluster架构中，如果出现以下情况

新加入节点
slot迁移
节点宕机
slave选举成为master

我们希望这些变化能够让整个集群中的每个节点都能够尽快发现，传播到整个集群并且集群中所有节点达成一致，那么各个节点之间就需要相互连通并且携带相关状态数据进行传播，按照正常的逻辑是采用广播的方式向集群中的所有节点发送消息，有点是集群中的数据同步较快，但是每条消息都需要发送给所有节点，对CPU和带宽的消耗过大，所以这里采用了gossip协议。Gossip protocol 也叫 Epidemic Protocol （流行病协议），别名很多比如：“流言算法”、“疫情传播算法”等。它的特点是，在节点数量有限的网络中，每个节点都会“随机”（不是真正随机，而是根据规则选择通信节点）与部分节点通信，经过一番杂乱无章的通信后，每个节点的状态在一定时间内会达成一致，如图所示。
假设我们提前设置如下规则：

Gossip 是周期性的散播消息，把周期限定为 1 秒
被感染节点随机选择 k 个邻接节点（fan-out）散播消息，这里把 fan-out 设置为 3，每次最多往 3个节点散播。
每次散播消息都选择尚未发送过的节点进行散播
收到消息的节点不再往发送节点散播，比如 A -> B，那么 B 进行散播的时候，不再发给 A。这里一共有 16 个节点，节点 1 为初始被感染节点，通过 Gossip 过程，最终所有节点都被感染：

3.gossip协议消息

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

4.gossip的优缺点

优点： gossip协议的优点在于元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新有一定的延时，降低了压力；去中心化、可扩展、容错、一致性收敛、简单。由于不能保证某个时刻所有节点都收到消息，但是理论上最终所有节点都会收到消息，因此它是一个最终一致性协议。
缺点：元数据更新有延时可能导致集群的一些操作会有一些滞后。消息的延迟，消息冗余。

5.数据分布

Redis Cluster中，Sharding采用slot(槽)的概念，一共分成16384个槽，这有点儿类似pre sharding思路。对于每个进入Redis的键值对，根据key进行散列，分配到这16384个slot中的某一个中。使用的hash算法也比较简单，就是CRC16后16384取模[crc16(key)%16384]。Redis集群中的每个node(节点)负责分摊这16384个slot中的一部分，也就是说，每个slot都对应一个node负责处理。
如图5所示，假设现在我们是三个主节点分别是：A, B, C 三个节点，它们可以是一台机器上的三个端口，也可以是三台不同的服务器。那么，采用哈希槽 (hash slot)的方式来分配16384个slot 的话，它们三个节点分别承担的slot 区间是

6.客户端重定向

如图5-6所示，假设k这个key应该存储在node3上，而此时用户在node1或者node2上调用 set k v 指令，这个时候redis cluster怎么处理呢？

127.0.0.1:7291> set qs 1
(error) MOVED 13724 127.0.0.1:7293

服务端返回MOVED，也就是根据key计算出来的slot不归当前节点管理，服务端返回MOVED告诉客户端去7293端口操作。
这个时候更换端口，用redis-cli –p 7293操作，才会返回OK。或者用./redis-cli -c -p port的命令。但是导致的问题是，客户端需要连接两次才能完成操作。所以大部分的redis客户端都会在本地维护一份slot和node的对应关系，在执行指令之前先计算当前key应该存储的目标节点，然后再连接到目标节点进行数据操作。在redis集群中提供了下面的命令来计算当前key应该属于哪个slot

redis> cluster keyslot key1

6.高可用主从切换原理

如果主节点没有从节点，那么当它发生故障时，集群就将处于不可用状态。
一旦某个master节点进入到FAIL状态，那么整个集群都会变成FAIL状态，同时触发failover机制，failover的目的是从slave节点中选举出新的主节点，使得集群可以恢复正常，这个过程实现如下：

当slave发现自己的master变为FAIL状态时，便尝试进行Failover，以期成为新的master。由于挂掉的、master可能会有多个slave，从而存在多个slave竞争成为master节点的过程，其过程如下：

slave发现自己的master变为FAIL
将自己记录的集群currentEpoch加1，并广播FAILOVER_AUTH_REQUEST 信息
其他节点收到该信息，只有master响应，判断请求者的合法性，并发送FAILOVER_AUTH_ACK，对每一个epoch只发送一次ack
尝试failover的slave收集master返回的FAILOVER_AUTH_ACK
slave收到超过半数master的ack后变成新Master (这里解释了集群为什么至少需要三个主节点，如果只有两个，当其中一个挂了，只剩一个主节点是不能选举成功的)
广播Pong消息通知其他集群节点。
从节点并不是在主节点一进入 FAIL 状态就马上尝试发起选举，而是有一定延迟，一定的延迟确保我们等待FAIL状态在集群中传播，slave如果立即尝试选举，其它masters或许尚未意识到FAIL状态，可能会拒绝投票。
延迟计算公式： DELAY = 500ms + random(0 ~ 500ms) + SLAVE_RANK * 1000ms
SLAVE_RANK表示此slave已经从master复制数据的总量的rank。Rank越小代表已复制的数据越新。这种方式下，持有最新数据的slave将会首先发起选举

7.集群什么时候不可用

无主从备份,某一节点宕机
某一节点主从全部宕机
超半数主节点宕机

二、codis的架构

如图5-7所示，表示Codis的整体架构图。
Codis Proxy：客户端连接的 Redis 代理服务, 实现了 Redis 协议。除部分命令不支持以外(不支持的命令列表)，表现的和原生的 Redis 没有区别（就像 Twemproxy）。
对于同一个业务集群而言，可以同时部署多个 codis-proxy 实例；不同 codis-proxy 之间由 codis-dashboard 保证状态同
codis-redisgroup: 代表一个redis服务集群节点，一个RedisGroup里有一个Master，和多个Slave
Zookeeper：Codis 依赖 ZooKeeper 来存放数据路由表和 codis-proxy 节点的元信息, codis-config 发起的命令都会通过 ZooKeeper 同步到各个存活的 codis-proxy.