redis系列(七)：集群

对集群的几个误区

• 集群和主从不是一个概念。
  集群是多主构成集群。集群中的主分别还有自己对应的从。
• 集群和哨兵不是一个概念。
  集群是多主之间的概念。哨兵是主从之间的概念。

为什么要有集群

1. 单台服务器存储能力有限，集群有利于存储。根据槽划分key存储在集群中的哪个服务器中。有点类似mysql的分表。

2. 单台服务器读写能力有限，主服务器主要负责的是写任务，大量的数据进来，要扛qps。集群可以减少单台服务器读写的压力。根据槽判断key再哪个服务器上存着。

什么是集群

一个集群由多个主节点构成。可以通过以下命令来完成集群的构建。

cluster meet  

step1:

step1.png

step2:

step2.png

step3:

step3.png

握手就是发送ping，响应就是发送pong

维持集群状态就是心跳。心跳使用的是gossip协议，简单理解就是让集群中每个人互相认识。gossip协议的原理，就不在这说了（我也不老会的）。

节点的数据结构

每个节点使用clusterNode来保存自己的状态

struct clusterNode {

    // 创建节点的时间
    mstime_t ctime;
    
    // 节点的名字，由40个十六进制字符组成
    char name[REDIS_CLUSTER_MAMELEN]
    
    // 节点标识
    // 记录节点角色（主|从）和节点状态（在线|下线）
    int flags;
    
    // 节点当前的配置纪元，用于故障转移
    uint64_t configEpoch;
    
    // 节点的ip地址
    char ip[REDIS_IP_STR_LEN];
    
    // 节点的端口号
    int port;
    
    // 保存连接点所需的有关信息
    clusterLink *link;
}

typedef struct clusterLink {

    // 连接的创建时间
    mstime_t ctime;
    
    // TCP 套接字描述符
    int fd;
    
    // 输出缓冲区，保存着等待发送给其他节点的消息(message)
    sds sndbuf;
    
    
    // 输入缓冲区，保存着从其他节点收到的消息
    sds rcvbuf;
    
    // 与这个连接相关联的节点，如果没有为null
    struct slusterNode *node;
} clusterLink;

每个节点使用clusterState来保存整个集群的状态

typedef struct clusterState {

    // 指向当前节点的指针
    clusterNode *myself;

    // 集群当前的配置纪元，用于故障转移
    uint64_t currentEpoch;
    
    // 集群当前的状态（在线|下线）
    int state;
    
    // 集群中至少处理着一个槽的节点的数量
    int size;
    
    // 集群节点名单（包括myself节点）
    // 字段的key为节点的名字，value为对应的slusterNode
    dict *nodes;
}

到目前为止，集群长这个样子

集群.png

• 纪元全是0
• 没有分配槽，所以size是0
  整个集群处于下线状态（16384个槽都有节点管理的时候，集群处于上线状态）
• 三个节点都是主节点

集群的高可用

和中从一样
集群也有自己的高可用（HA）方案。

集群.png

比如，集群有三个节点，每个节点管理5千多个槽。当集群中有主挂了的时候。集群模式也会选重新选一个主出来。

集群的选主逻辑是通过选举产生的：

1. 集群的配置纪元是一个自增计数器，他的初始值为0

2. 当集群里的某一个节点开始一次故障转移操作时，集群配置纪元的值会被增一

3. 对于每个配置纪元，集群里每个负责处理槽的主节点都有一次投票的机会，而第一个向主节点要求投票的“从节点”（集群模式的从，是他自己主从模式的主）将获得主节点的投票

4. 当“从节点”发现自己正在复制的主节点进入已下线状态时，“从节点”会向集群广播一条clustermsg_type_fallover_auth_request消息，要求所有收到这条消息并具有投票权的主节点向这个从节点投票

5. 如果一个节点具有投票权（它负责处理槽），并且这个主节点尚未投票给其他节点，那么主节点将向要求投票的从节点返回一条clustermsg_type_fallover_auth_ack消息，表示这个主节点支持从节点成为新的主节点

6. 每个参与选举的从节点都会接收clustermsg_type_fallover_auth_ack消息，并根据收到消息的个数来统计获得了多少主节点的支持

7. 如果集群里有N个具有投票权的主节点，那么当一个从节点收集到 >= N/2+1张支持票时，这个从节点会当选为新的主节点

8. 因为在每个纪元里面，每个具有投票权的主节点只能投一次票，所以，超过半数的从节点只能有一个

9. 如果没有超过半数的从节点，那么集群进入下一个纪元，并再次投票，直到有半数从节点成为新的主节点为止

故障转移

1. 复制下线主节点的所有从节点，会有一个被选中
2. 被选中的从节点会执行slaveof no one命令，成为新的主节点
3. 新的主节点会撤销所有对已下线主节点的槽指派，并将这些槽指派给自己
4. 新的主节点向集群广播一条pong消息，这条pong消息可以让集群中的其他节点立即知道这个节点已经从从节点变成主节点了
5. 新的主节点开始接受和自己负责处理的槽有关的请求命令，故障转移完成。

tps:故障转移期间，redis集群拒绝客户端连接。大概是因为槽内数据需要复制到新主中，这个期间，需要保持数据一致性。

集群模式和哨兵模式

• 集群模式主要负责的是分片分槽这种多主的高可用
• 哨兵模式主要负责的是一主多从这种架构的高可用

原理类似，都是故障检测 -> 选主 -> 故障迁移。

分片

分片其实是有两种方式的

1. 服务器分片
2. 客户端分片

服务器分片就是槽指派。槽那一张会详细介绍。

客户端分片就是，redis服务端并不做分片和分槽。客户端自己做hash，判断key放在哪个redis中。可以自己写hash算法，也可以用中间件。

客户端分片的缺点是，加机器需要重新hash来判断在那个redis中，对扩展不友好。

其实和mysql分表一。都是通过hash找到key所在的存储位置。减少单节点读写和存储的压力。