Raft共识算法入门教程


1 分布式基础概念

    1.1  数据副本与一致性问题

    1.2  分布式系统的进化史

    1.3  全面解读CAP定理

    1.4  CAP理论为什么不能同时满足?

    1.5  BASE原则

2 全面解读Raft共识算法

    2.1  全面解读Raft共识算法

    2.2  Raft日志的作用

    2.3  Raft日志复制

    2.4  Raft共识算法是否属于二阶段提交?

    2.5  Raft算法中的三种超时时间

    2.6  Raft算法动图展示

3 实战操练Raft共识算法

分布式系统的进化史:主备->主从->领导者-学习者

1、主备模式介绍

主即主机,备即备机。顾名思义,主机当然是以它为主了,读写都是主机上,而备机只用作备用,默默的在背后同步主机的数据,时刻待命着等待主机挂了之后取而代之。因此在主机还活着的情况下,备机的唯一使命就是同步主机的数据,不对外提供服务。


master-backup.png

优点:简单,主备之间只有数据同步,不需要考虑别的情况。很简单的配置一下,再搞一台服务器就能组成主备架构了。

缺点:备机等于就拿来备份,浪费了备机这台服务器的资源。

2、主从模式介绍

主即主机,从即从机。从机和备机的区别在于:从机得除了同步数据之外还得干活,对外提供读的操作。


master-slave.png

优点:充分利用了资源,从机不想备机这么爽了,还得出来干活,对外提供读操作。而且在主机挂了的时候,如果没任命新机主之前,读操作还是能用的。

缺点:

(1)客户端需要多个判断,也就是不同操作需要发放给不同服务器,上图主机提供读写,有时候读写分离了,主机就只提供写。

(2)主从延迟,读操作分配给从库,就会存在数据同步的延迟问题,比如某个人下单之后,再次访问走的是从机,这时候数据还未从主机同步过来,那可不让人很难受了。

3、主备和主从模式的致命缺点

通常情况下无法做到RPO=0,即主节点发生故障或者灾难时有交易数据的损失。

可能有人会说:主备/主从复制技术也能实现 RPO=0!是的,从理论上讲主备/主从复制技术是可以利用强同步模式做到RPO=0,但实际应用中,像银行核心系统这样的关键业务里却不会采用。为什么呢?以主从模式为例,因为这种模式将主节点和从节点以及主从节点之间的网络环境紧紧地绑在了一起,主节点的稳定性将不再由它自己决定,而要同时看从节点和网络环境的脸色:一旦从节点或者网络环境稍微抖动一下,主节点的性能就会受到直接影响。

如果主节点和从节点之间是跨机房甚至跨城市部署,发生这种问题的概率会更大,影响也会变得更加显著。从某种程度上讲,和单节点模式相比,这种模式下主节点的稳定性不但没有增加,反而是降低了。

4、领导者-学习者

ZooKeeper 中没有选择传统的 Master/Slave 概念,而是引入了Leader、Follower 和 Observer 三种角色。

其主要的特点是:全局数据一致: 集群中每个服务器保存一份相同的数据副本,Client无论连接到哪个服务器,展示的数据都是一致的。