tidb 系列一：Raft与主从

Posted 2021-04-27 数据与技术

概述

    这阵子公司准备上tidb集群，组内同事研究的热火朝天，tidb官网说到，比起传统主从 (M-S) 复制，基于Raft协议可以提供更好的一致性和auto-failover保证，而且Raft比paxos更好，我一下子就来了兴趣。本文主要围绕简单理解Raft协议展开。

导读

    Raft角色

    角色切换

    日志同步

    Raft与主从复制区别

Raft角色

    在Raft中，任何时候一个服务器可以扮演下面三个角色：

1. Leader：对接所有客户端交互，日志复制等，同一时刻系统中最多存在1个Leader

2. Follower：所有节点的初始状态，被动接受各种请求

3. Candidate：Leader候选人，由Follower向Leader转换的中间状态

角色切换

    Raft角色的切换主要是靠超时和term：

• Election Timeout

    Follower或者Candidate初始会随机分配Election Time，一旦超时，往其它节点发送vote请求

• Heartbeats Timeout

    确定Leader之后，Follower随机分配HeartBeats Time，一旦超时，往其它节点发送vote请求。如果Follower收到Leader心跳，则HeartBeats Time重新分配

• term

    在网络抖动或者延迟情况下，Raft会出现多个Candidate或者leader，如果多个Candidate互相发送vote请求，如何权衡选主？每次Candidate发送vote请求，带上term数，并且term加一，term大为主。

    

    切换流程如下（可耻的盗图）：

• time out,starts election(Follower->Candidate)：

    Election Timeout，往其它节点发送vote 请求，并且切换为Candidate

• discovers current leader or new term(Candidate->Follower)：

    接受到leader的心跳或者接受到vote请求，并且term数大于自身，则切换为Follower

• time out,new election(Candidate->Candidate)：

    Election Timeout，继续发送vote请求，角色不变

• receives voites from majority of servers(Candidate->Leader)：

    接收到绝大多数vote响应

• discovers server with higher term(Leader->Follower)：

    接收到其它vote请求，并且term数大于自身，则切换为Follower

    角色的切换也提现了Raft协议的高可用，Leader宕机，Raft都能快速的选主，提供服务。

日志同步

    日志同步是由心跳驱动完成的，Leader收到其它节点的reply，包括committed log offset和落地的log offset，与Leader的committed log offset与落地 log offset进行比较，并且同步差异log

Raft与主从复制区别

    Raft

    优点：属于去中心化分布式协议，自动化程度高，运维部署简单

    缺点：落地实现困难（分布式一致性协议通病）

    主从复制

    优点：落地实现加单

    缺点：缺乏自动化运维，需要人工处理故障，也可以引入第三方服务，但会增加系统复杂性。

总结

    比起paxos的抽象难懂，Raft是我看过最易理解的分布式协议，流程清晰，落地实现简单。

    分布式协议涉及点较多，本文尽可能简单的阐述了Raft的角色切换，选主，日志同步等关键流程，只描述了大概的轮廓，没有涉及到底层深入，适合新手快速了解Raft协议。

    现在kafka与redis的一致性同步流程基本与tidb类似，自动选主，日志同步，auto-failover等等，不同的是协议实现方式。