先自我介绍一下,小编浙江大学毕业,去过华为、字节跳动等大厂,目前阿里P7
深知大多数程序员,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年最新Java开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上Java开发知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
如果你需要这些资料,可以添加V获取:vip1024b (备注Java)
正文
============
-
强一致性:写操作完成之后,读操作一定能读到最新数据,在分布式场景中这样是非常难实现的,比如 Paxos算法,Quorum机制,ZAB协议都是干这个事的。
-
弱一致性:不承诺可以立即读到写入的值,也不承诺多久之后数据能够达到一致,但会尽可能的保证到某个时间级别(比如XX时,XX分,XX秒后),数据可达到一致性状态。
它还有一个特例叫做最终一致性,就是尽可能快的保证数据的一致。但是这个快到底是多快,就没有准确定义了。好比女票想要吃到炸鸡,你给点了份外卖,可是美团骑手,饿了吗骑手也说不准什么时候送到,他只能说保证尽快送到。就这么个意思。
因为最终一致性实在是太弱了所以我们还有一些特例情况会出现读写一致性,它是指用户读取自己写入的结果永远可以第一时间看到自己更新的内容,这个就像微信朋友圈一样的,我们发出来的东西,微信是一定会让我们看到的,可是朋友们是不是你发了立刻就能看到,那可就说不准了。
还有一些单调读一致性,因果一致性就不展开说明了,有兴趣的小伙伴可以自行搜索。
总而言之,为了保证系统的高可用,防止单点故障引发的问题,并能够让分布在不同节点上的副本都能正常为用户提供服务,这时,我们的 Zookeeper 就应运而生了。它就能帮助我们解决这个分布式系统中数据一致性的问题
需要解决这个问题我们需要了解分布式事务,分布式一致性算法,Quorum 机制,CAP 和 BASE 理论,接下来我们慢慢去展开
二、分布式事务
=======
事务:单机存储系统中用来保证存储系统的数据状态一致性,这是不是读起来有点拗口,没事,我们换个说法,广义上的事务,就是指一个事情的所有操作,要不全部成功,要不全部失败,没有中间状态。狭义一点,那就是数据库做的那些操作。特征也很简单,就是耳熟能详的 ACID 。
分布式系统中每个节点都仅仅知道自己的操作是否成功,但是不知道其它节点是个啥情况,这就有可能导致各节点的状态可能是不一致的,所以为了实现跨越多节点且保证事务的 ACID 时,需要引入一个协调者,然后参与事务的各个节点都叫做参与者
典型的套路就是 2PC 和 3PC,接下来我们慢慢展开
2.1 2PC是个什么东西
=============
在事务的参与过程中会产生多个角色,暂时我们先这么理解,协调者负责事务的发起,而参与者负责执行事务。
假定存在上面的3个角色,分别是一个协调和两个参与,此时我们需要 A ,B 执行一个事务,并且要求这个事务,要么同时成功,要么同时失败。
2PC 阶段一:执行事务
============
此时协调者会 先发出一个命令,要求参与者A,参与者B都都去执行这个事务,但是不提交
说的再详细一点,就会产生写 redo,undo 的日志,锁定资源,执行事务。但是执行完了之后,直接向协调者打报告,询问一下,大哥我能提交吗?
这个在日常写Java的过程中应该经常遇到,就是前面写了一大堆操作,但是等到最后一定会写一个 conn.commit() 这样的东西,这就是所谓的 执行但不提交
2PC 阶段二:提交事务
============
当协调者收到第一阶段中的所有事务参与者(图中的A,B)的反馈(这个反馈简单理解为,告诉协调者前面的第一阶段执行成功了)时,就发送命令让所有参与者提交事务。
如果要说的再细一点,那就是协调者收到反馈,且所有参与者均响应可以提交,则通知参与者进行 commit,否则 rollback
所以 2PC 也叫做二阶段提交,其实就是这么简单分成了两步,一步执行,一步提交。
2PC 的4个缺点:性能
============
整个流程看下来就知道这明显产生了同步阻塞,各个需要操作数据库的节点都占用了数据库的资源。只有当协调者收到所有节点都准备完毕的反馈,事务协调者才会通知 commit or rollback,而参与者执行完这个 commit or rollback 的操作后,才会去释放资源。
2PC 的4个缺点:单点故障
==============
那我们刚刚也知道了,协调者才是这个事务的核心。假如此时协调者故障宕机,会导致通知无法传达到参与者的问题,比如收不到那个 commit or rollback ,整一个事务便会停滞。
2PC 的4个缺点:数据不一致
===============
协调者在第二阶段会发送 commit or rollback。可是这并不能保证每一个节点都正常收到这个命令,所以会可能窜在,参与者A收到了命令,提交了事务,但是参与者B没有。所以网络波动是永恒的病因,你永远无法躲开这个因素。
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)就一定能读取到最新的数据,数据一致性级别完全可以根据读写副本数的约束来达到强一致性!
分以下三种情况讨论:前提,当 N 已经固定了。
W = 1, R = N,Write Once Read All
复制代码
写在最后
学习技术是一条慢长而艰苦的道路,不能靠一时激情,也不是熬几天几夜就能学好的,必须养成平时努力学习的习惯。所以:贵在坚持!
最后再分享的一些BATJ等大厂20、21年的面试题,把这些技术点整理成了视频和PDF(实际上比预期多花了不少精力),包含知识脉络 + 诸多细节,由于篇幅有限,上面只是以图片的形式给大家展示一部分。
Mybatis面试专题
MySQL面试专题
并发编程面试专题
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
需要这份系统化的资料的朋友,可以添加V获取:vip1024b (备注Java)
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
的形式给大家展示一部分。
[外链图片转存中…(img-Pm5M2pi8-1713685168080)]
Mybatis面试专题
[外链图片转存中…(img-TMa9E72E-1713685168081)]
MySQL面试专题
[外链图片转存中…(img-Oip1tOS1-1713685168082)]
并发编程面试专题
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
需要这份系统化的资料的朋友,可以添加V获取:vip1024b (备注Java)
[外链图片转存中…(img-wpsbVajH-1713685168082)]
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!