2024年最全zk分布式实现理论，Paxos算法，ZAB协议，CAP定理，面试题分享

写在最后

可能有人会问我为什么愿意去花时间帮助大家实现求职梦想，因为我一直坚信时间是可以复制的。我牺牲了自己的大概十个小时写了这片文章，换来的是成千上万的求职者节约几天甚至几周时间浪费在无用的资源上。

上面的这些（算法与数据结构）+（Java多线程学习手册）+（计算机网络顶级教程）等学习资源

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

Paxos算法：一种基于消息传递且具有高度容错特性的一致性算法。

Paxos算法解决的问题：就是如何快速正确的在一个分布式系统中对某个数据值达成一致，并且保证不论发生任何异常， 都不会破坏整个系统的一致性

在一个Paxos系统中，首先将所有节点划分为Proposer（提议者），Acceptor（接受者），和 Learner（学习者）。（注意：每个节点都可以身兼数职）

• 一个完整的Paxos算法流程分为三个阶段：

• Prepare准备阶段 • Proposer向多个Acceptor发出Propose请求Promise（承诺） • Acceptor针对收到的Propose请求进行Promise（承诺）

• Accept接受阶段 • Proposer收到多数Acceptor承诺的Promise后，向Acceptor发出Propose请求 • Acceptor针对收到的Propose请求进行Accept处理

• Learn学习阶段：Proposer将形成的决议发送给所有Learner

Paxos算法流程

（1）Prepare: Proposer生成全局唯一且递增的Proposal ID，向所有Acceptor发送Propose请求，这里无需携带提案内容，只携 带Proposal ID即可。

（2）Promise: Acceptor收到Propose请求后，做出“两个承诺，一个应答”。

➢ 不再接受Proposal ID小于等于（注意：这里是<= ）当前请求的Propose请求。

➢ 不再接受Proposal ID小于（注意：这里是< ）当前请求的Accept请求。

➢ 不违背以前做出的承诺下，回复已经Accept过的提案中Proposal ID最大的那个提案的Value和Proposal ID，没有则 返回空值。

（3）Propose: Proposer收到多数Acceptor的Promise应答后，从应答中选择Proposal ID最大的提案的Value，作为本次要发起的 提案。如果所有应答的提案Value均为空值，则可以自己随意决定提案Value。然后携带当前Proposal ID，向所有Acceptor发送 Propose请求。

（4）Accept: Acceptor收到Propose请求后，在不违背自己之前做出的承诺下，接受并持久化当前Proposal ID和提案Value。

（5）Learn: Proposer收到多数Acceptor的Accept后，决议形成，将形成的决议发送给所有Learner。

案例讲解

有ABCDE五人对公司问题进行决议

第一种情况：

A对其他人发起提议，问能不能接受自己的意见，没说具体内容

BCDE回应A表示同意

A在收到2份回复时就会告知其他人自己提议的具体内容

BCDE在回应A表示同意

此时A的提议就会通过

第二种情况：

A与E同时发起提议，问能不能接受自己的意见，没说具体内容，AE的序号分别为1,2

B回应A，D回应E，这时C成为关键

(1)C先收到A的消息，回应A

此时A就会表明具体意见

BC接受

之后C又收到E的消息，回应E

此时E也会表明具体意见

CD接受

这个时候AE会同时广播决议，因为E的id大，所以E会覆盖A的提议

第三种情况：

AE发起提议

B回应A，D回应E，这时C成为关键

C收到A的消息回复A，这时立刻收到E的消息，又回复E

这时A表明具体意见，C不会回复，没有足够响应

这时候A会从新发起提议，此时A的id会变为3，C又回复A

此时E表明具体意见，C不会回复，又会重新发起提议

这时候就会出现问题

ZAB协议

借鉴了Paxos算法，在Paxos基础上，zookeeper设计只有一台客户端(Leader)负责处理外部写事务的请求，在同步到其他节点，即只有一个Leader可以发起提案

消息广播

（1）客户端发起一个写操作请求。

（2）Leader服务器将客户端的请求转化为事务Proposal 提案，同时为每个Proposal 分配一个全局的ID，即zxid。

（3）Leader服务器为每个Follower服务器分配一个单独的队列，然后将需要广播的 Proposal依次放到队列中去，并且根据FIFO策略进行消息发送。

（4）Follower接收到Proposal后，会首先将其以事务日志的方式写入本地磁盘中，写入成功后向Leader反馈一个Ack响应消息。

最后

既已说到spring cloud alibaba，那对于整个微服务架构，如果想要进一步地向上提升自己，到底应该掌握哪些核心技能呢？

就个人而言，对于整个微服务架构，像RPC、Dubbo、Spring Boot、Spring Cloud Alibaba、Docker、kubernetes、Spring Cloud Netflix、Service Mesh等这些都是最最核心的知识，架构师必经之路！下图，是自绘的微服务架构路线体系大纲，如果有还不知道自己该掌握些啥技术的朋友，可根据小编手绘的大纲进行一个参考。

如果觉得图片不够清晰，也可来找小编分享原件的xmind文档！

且除此份微服务体系大纲外，我也有整理与其每个专题核心知识点对应的最强学习笔记：

• 出神入化——SpringCloudAlibaba.pdf

• SpringCloud微服务架构笔记（一）.pdf

• SpringCloud微服务架构笔记（二）.pdf

• SpringCloud微服务架构笔记（三）.pdf

• SpringCloud微服务架构笔记（四）.pdf

• Dubbo框架RPC实现原理.pdf

• Dubbo最新全面深度解读.pdf

• Spring Boot学习教程.pdf

• SpringBoo核心宝典.pdf

• 第一本Docker书-完整版.pdf

• 使用SpringCloud和Docker实战微服务.pdf

• K8S(kubernetes)学习指南.pdf

另外，如果不知道从何下手开始学习呢，小编这边也有对每个微服务的核心知识点手绘了其对应的知识架构体系大纲，不过全是导出的xmind文件，全部的源文件也都在此！

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

片转存中…(img-4p8F0aKo-1715093937907)]

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取