分布式系统的一些基础理论，java技术面试题目，算法面试书

2PC 的4个缺点：不存在容错机制

=================

这个协调者需要收到所有的节点反馈准备完成才会下达 commit 的指示，任意一个参与者的响应没有收到，协调者就会进行等待，而且只要存在一个宕机的节点，都会使得整个事务失败回滚。

2.2 3PC 是个啥东西

=============

在 2PC 的前提下进行了一个改良，将 2PC 中的准备阶段进行拆分，形成 can commit，pre commit，do commit 三个阶段。

并且引入超时机制，一旦事务参与者在指定时间内没有收到协调者的 commit or rollback 指令，就会自动进行本地 commit，解决协调者的单点故障问题

3PC 第一阶段 cancommit

==================

协调者先询问：哎你们这帮人到底能不能行？参与者就根据自身的实际情况回答yes or no。

3PC 第二阶段 precommit

==================

如果参与者都是返回同意，协调者则向所有参与者发送预提交请求，并进入准备阶段，这里的准备阶段其实就是让参与者锁定资源，等待指令的意思，然后就是事务的执行，此时也像 2PC 一样，执行但不提交。然后等待协调者的指令，此时如果迟迟等不到指令，一段时间后就会自行本地提交

但是这样也会存在弊端，比如协调者成功给1，2参与者都发送回滚，然后3刚好就没收到，那么3就自动提交了，所以超时机制其实并不能完全保证数据的一致性

三、分布式一致性算法

==========

3.1 Paxos 算法

============

不知道大家有没有看到我上一年的那篇 从零开始的高并发（三）— Zookeeper集群的搭建和leader选举 如果需要详细了解，推荐跳转到那篇哦。

Paxos 算法是一个名字叫 Lesile Lamport 提出的一种基于消息传递且具有高度容错特性的一致性算法

是不是觉得绕口？没事，我们只需要知道，分布式系统中不可避免的会发生进程被kill，消息延迟，重复，丢失···一系列问题，Paxos 算法就是在这些异常情况下的仍然保证数据一致性的东西。那这东西和 Zookeeper 有啥关系呢？Zookeeper 是存在一个 ZAB 协议的，但是这个 ZAB 协议底层就是封装了 Paxos 算法的。

3.2 Paxos 中存在的角色及与 Zookeeper 集群的关系

==================================

Proposer 提议者：顾名思义就是发起提案的人

Acceptor 接受者：它们是可以表决的，可以接受或者否决提案

Learner 学习者：提案被超过半数的 Acceptor 接受的话，就学习这个提案

映射到 Zookeeper 集群中，就分别是 leader，follower，observer，它们有点像是主席，人大代表，和全国老百姓的关系，主席提出一个提案，人大代表参与投票，全国老百姓被动接受，大概就是这么个感觉。相比于之前的 2PC，3PC，它只需要半数通过即可提交。所以这种属于弱一致性，2PC，3PC这些就属于强一致性

3.3 Raft 算法

===========

请点击这个链接，相信你一定能够很快掌握。

http://thesecretlivesofdata.com/raft/ 我这里还是小小的说明一下吧，这个是一个PPT的形式，告诉你，Raft 到底是个什么东西，非常好懂，我这里跳过前面的一些东西，直奔主题

这里说到了，Raft 是实现分布式共识算法的一个协议

这里假设一个节点有3种不同的状态

第一种，follower state（无线条）

第二种，candidate state（虚线）

第三种，leader state（实线） 记住leader是从 candidate 候选人那里选出来的

首先我们一上来，所有的节点都是 follower state

接下来，所有的 follower 节点都寻找 leader ，当他们找不到的时候，就会自发成为候选人发起投票（问其它人是否赞成我成为 leader），什么情况才会找不到呢？那肯定就是 leader 挂了嘛

此时它就发送给其它节点投票的提案，然后其它节点也会给予它反馈，当它接收到超过半数的节点的反馈的时候，它就可以顺理成章的成为 leader 了。

之后写数据的请求就会直接发给leader，由 leader 广播给其它的 follower，此时也是只要超过半数节点返回正反馈，那这个写数据的事务就会被执行，然后 leader 再给它们发送提交命令，事务就算执行成功了。

3.4 ZAB 协议

==========

内容在 从零开始的高并发（四）— Zookeeper的分布式队列

Zookeeper 的底层实现就是 ZAB 协议，它实现了崩溃恢复（leader崩溃）和消息广播（客户端写数据Zookeeper要保证多节点都成功写入）功能。主要就是保证在leader服务器上提交的事务最终让所有服务器都提交，并确保丢弃掉只在leader服务器上所提出的事务

3.5 Quorum NWR 机制

=================

Quorum NWR：Quorum 机制是分布式场景中常用的，用来保证数据安全，并且在分布式环境中实现最终一致性的投票算法。这种算法的主要原理来源于鸽巢原理。它最大的优势，既能实现强一致性，而且还能自定义一致性级别。

鸽巢原理，又名狄利克雷抽屉原理、鸽笼原理。

其中一种简单的表述法为： 若有n个笼子和n+1只鸽子，所有的鸽子都被关在鸽笼里，那么至少有一个笼子有至少2只鸽子。

另一种为：若有n个笼子和kn+1只鸽子，所有的鸽子都被关在鸽笼里，那么至少有一个笼子有至少k+1只鸽子。

为什么从抽屉原理说起？一来大家对这个比较熟悉，也容易理解，二来它与 Quorum 机制有异曲同工的地方。抽屉原理，2个抽屉每个抽屉最多容纳2个苹果，现在有3个苹果无论怎么放，其中的一个抽屉里面肯定会有2个苹果。那么我们把抽屉原理变变型，2个抽屉一个放了2个红苹果，另一个放了2个青苹果，我们取出3个苹果，无论怎么取至少有1个是红苹果，这个理解起来也很简单。我们把红苹果看成更新了的有效数据，青苹果看成未更新的无效数据。便可以看出来，不需要更新全部数据（并非全部是红苹果）我们就可以得到有效数据，当然我们需要读取多个副本（取出多个苹果）。

回到 Quorum NWR 机制 的 NWR 到底指什么

N：复制的节点数，即一份数据被保存的副本数。 W：写操作成功的节点数，即每次数据写入写成功的副本数。W 肯定是小于等于 N 的。 R：读操作获取最新版本数据所需的最小节点数，即每次读取成功至少需要读取的副本数。

总结：这三个因素决定了可用性，一致性 和 分区容错性。只要保证（W + R > N）就一定能读取到最新的数据，数据一致性级别完全可以根据读写副本数的约束来达到强一致性！

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）

总结

其他的内容都可以按照路线图里面整理出来的知识点逐一去熟悉，学习，消化，不建议你去看书学习，最好是多看一些视频，把不懂地方反复看，学习了一节视频内容第二天一定要去复习，并总结成思维导图，形成树状知识网络结构，方便日后复习。

这里还有一份很不错的《Java基础核心总结笔记》，特意跟大家分享出来

目录：

部分内容截图：

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

截图：**

[外链图片转存中…(img-2t77tNUr-1712971698605)]

[外链图片转存中…(img-RbKh7mmy-1712971698606)]

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
[外链图片转存中…(img-qWbbPAqe-1712971698606)]