架构设计：系统存储（26）——数据一致性与Paxos算法（终）

作者简介：大家好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO

联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬

学习必须往深处挖，挖的越深，基础越扎实！

阶段1、深入多线程

阶段2、深入多线程设计模式

阶段3、深入juc源码解析

阶段4、深入jdk其余源码解析

阶段5、深入jvm源码解析

码哥源码部分

码哥讲源码-原理源码篇【2024年最新大厂关于线程池使用的场景题】

码哥讲源码【炸雷啦！炸雷啦！黄光头他终于跑路啦！】

码哥讲源码-【jvm课程前置知识及c/c++调试环境搭建】

​​​​​​码哥讲源码-原理源码篇【揭秘join方法的唤醒本质上决定于jvm的底层析构函数】

码哥源码-原理源码篇【Doug Lea为什么要将成员变量赋值给局部变量后再操作？】

码哥讲源码【你水不是你的错,但是你胡说八道就是你不对了！】

码哥讲源码【谁再说Spring不支持多线程事务，你给我抽他！】

终结B站没人能讲清楚红黑树的历史，不服等你来踢馆！

打脸系列【020-3小时讲解MESI协议和volatile之间的关系，那些将x86下的验证结果当作最终结果的水货们请闭嘴】

如上图所示，Server 2在宕机前正在对log7 、log8 、log9 进行Paxos，并且自身已经完成赋值过程（但是其它节点都还没有完成赋值过程，没有形成多数派）。这时Server 2由于某些原因下线了。Server 3通过选主过程拿到了Proposer Leader，但是它能获取到的最大log id为log6（因为现在存活的各个节点上最大的log id都是log6嘛），所以自己start working的log id 位置就是log7。就在这个时候，Server 2节点又恢复了工作，且技术人员人工命令从新授予Server 2 节点Proposer Leader身份。

这时在其上原有的log7、log8、log9虽然有值，但是也不能再使用了，需要重新进行恢复。那么Server 2依据什么来判断存储在自身节点的log7、log8、log9的值已经失效必须进行恢复的呢？那就是在start working的时候，记录了一个创建时间T1，在随后的工作中，节点每写入一条日志信息就要写入同时写入这个T1。当进行数据恢复时，如果发现某一条数据所记录的T1和其最近的start working标记点所记录的T1不一致，就认为这是一条记录时效的数据，需要进行恢复。

按照如上图所示的极端示例中，log7的值应该恢复成11，而log8、log9的值应该记为一个空值或者是恢复成一个NOP标记。

3. 其它说明

Paxos算法并不是所有最终一致性算法，Multi-Paxos也并不是唯一一种Paxos算法的变种，例如还有Fast-Paxos、Egalitarian-Paxos。Fast-Paxos进一步强调了Leaner角色在整个Paxos算法中的作用，进一步优化了多个Proposer的协作工作过程。在后续的文章中会适时回过头来介绍Fast-Paxos，这里确实不能在耽误时间向后推进了（本来计划3月下旬开始分布式文件系统Ceph的使用和原理介绍）

最终一致性算法除了Paxos外，还有ZAB算法、RAFT算法、GOSSIP算法和PacificA算法。其中ZAB算法应用在一个非常著名的软件Zookeeper中，而PacificA的思想则被用在Apache Kafka进行Partition Leader的选举过程中。关于Zookeeper的基本选举算法（FastLeaderELection）在笔者很早之前就向大家介绍过。

后续的文章，我们将开始介绍分布式文件系统Ceph的使用和工作原理。从Ceph文件系统的介绍继续讲解