最后：学习总结——MyBtis知识脑图（纯手绘xmind文档）
学完之后，若是想验收效果如何，其实最好的方法就是可自己去总结一下。比如我就会在学习完一个东西之后自己去手绘一份xmind文件的知识梳理大纲脑图，这样也可方便后续的复习，且都是自己的理解，相信随便瞟几眼就能迅速过完整个知识，脑补回来。下方即为我手绘的MyBtis知识脑图，由于是xmind文件，不好上传，所以小编将其以图片形式导出来传在此处，细节方面不是特别清晰。但可给感兴趣的朋友提供完整的MyBtis知识脑图原件（包括上方的面试解析xmind文档）
除此之外，前文所提及的Alibaba珍藏版mybatis手写文档以及一本小小的MyBatis源码分析文档——《MyBatis源码分析》等等相关的学习笔记文档，也皆可分享给认可的朋友！
但是，要做到这些，首要做的是能明白分布式系统到底是个什么东西。
分布式系统大家从网络上看到的学术定义简单来说就是一套由一组计算机协同工作，让用户感觉像是一个统一的整体的系统。
但是，由于这个定义定的过于简练，很多初入门的人会毫无感知的潜意识就会混淆了分布式系统的概念。
什么意思？我这里问下，当我们用 keepalived 做高可用集群的时候，我们是在搞分布式系统吗？当我们并发不够，搞了一堆机器做负载均衡，我们是在搞分布式系统吗？
当你心里默默回答是，或者不清楚是不是的时候，你本身对分布式系统这个概念就已经糊涂了。
这里，就需要为分布式系统画出一个边界来，并以此告知大家，并不是多台机器堆在一起了就是分布式系统了。对于刚才那两个问题，正确的答案就是 keepalived 做的高可用集群，用 Nginx 或者 lvs 后面跟着一堆应用集群配合搞的负载均衡，他们都不是分布式系统，他们就仅仅是个集群而已。
类似的，数据库比如 MySQL 的主从，双主什么的当然也不是分布式系统。因为这些集群少了分布式系统最核心的东西：
应用所在服务器之间的相互协作
为了说清集群和分布式，我再给大家举一个通俗易懂的例子：
假设有一天我开了个软件公司，公司就我一个程序员，前端、后端、测试的活儿，都是我干，一个月我能做完一个项目。
后来项目多了，我忙不过来了，为了多赚钱，怎么办呢，我想了两条路
1.再招一个和我一样强的全栈工程师，我俩每个人独立做项目，这样我们一个月能做完两个项目。我俩就组成了一个集群。
2.招一个前端、一个测试配合我，前端、后端、测试分头干。通过协作，我们半个月能干完一个项目。这时候我们的关系就是分布式。
从上面例子你就能看出:
-
集群中的多个服务器都在做相同的事情，并不能缩短处理一件事情的时间。
-
而分布式呢，是把事情拆开，多个服务器分头做事，可以缩短时间。
知道了什么是分布式系统之后，一个最简单的分布式系统应该是什么样的？
假设我们做了一套系统，这套系统仅有两个功能：1. 注册、2. 登录
如果我们想让这套系统变成分布式系统该怎么做？最简单的是，把注册功能和登录功能分别做成两套子服务，然后部署到两台服务器上，让他们互相协作，这就变成了一套最简单的分布式系统。
你看到这里可能会非常震惊：
这就是一套分布式系统了？
我想学习的分布式系统的那么多技术栈呢？
那些高大上的算法呢？
能瞬间闪回的容错机制呢？
无缝热升级的功能呢？
问题到底出现在哪里？
我们搭建的这套简单的系统真的是我们日常谈论的分布式系统吗？
为什么要搞分布式系统？答案很简单：形势所迫！一套分布式系统往往是由于业务发展后采取的终极方案。
假如公司新开展了一项在线业务，而我们因此要为这套业务搭建开发一套业务系统。往往这时候，由于项目前景未知，又由于要快速上线进入市场做试错，此时，我们可能会优先搞一套单体架构，先上线。
随着业务的开展和运营，我们往往面临的第一个问题是系统的崩溃和服务器的宕机。
这时候，大家就搞一套高可用架构来解决问题。把相同的项目部署在多台机器上，一台机器出问题了，直接换到另外一台提供服务即可。
随后，由于业务进一步的发展和壮大，此时，出现瓶颈的往往就是系统的响应时间了。响应时间的增加直接影响了用户体验，而这本身也反映了吞吐量出现了瓶颈。
对于这种问题，架构师们就会祭出集群大法好的思路来搞定。这时候，系统架构开始复杂了起来，因为别忘了，我们在保证负载均衡的同时，还需要保证服务的高可用。
到目前为止，貌似没什么问题了。我们通过高可用保证了系统的可靠性，通过负载均衡，分散了系统的压力。
但是，以上这些方案都不是分布式，系统也不是分布式系统，依然是 Monoliths 这种被一些技术疯子们嘲笑的笨重架构。
我们还需要分布式吗？
上图是某大厂的支付平台一小部分架构图。
从这张图可以看出，业务发展到后面会有多么复杂。面对如此复杂的业务，我们发现我们之前搞的那种集群怎么也说不过去了。
这时候，就需要进行业务的拆分。
虽然业务拆分了，但是这些业务终究是要对外合作提供一个整体的服务的，这时候，才是真正需要分布式系统的时候了。我们需要一组在不同的服务器上相互协作的系统。
所以我们说，分布式系统是由于业务发展后的终极解决方案。最终，业务复杂到拆分的地步，那么分布式系统就是天然的需求了。
在这里，我们也可以解答下上节我们面临的问题了。我们需要的不是简单的直接把模块分散部署的无意义分布式，不是简单的模块分解。我们需要的是系统在被迫搞成分布式的情况下依然能够：
-
保持出色的性能
-
拥有着无比可靠的可用性
-
以及非常优秀的弹性
而为了保证以上这三个指标，就出现了分布式系统那繁杂艰深的技术栈。
上面我们说了，分布式系统的出现完全是形式所迫，完全是业务发展导致的最终结果。而由于业务的拆分，我们又被迫会衍生出更多的分布式需求来，以及应对这些需求的技术：
-
因为业务拆分的多，业务对应的模块之间就需要通信，为了保证通信的快速可靠，我们需要掌握分布式通信技术。
-
业务拆分的过多，每个模块可能还需要搞集群，那么多服务器资源，为了能够保证资源的精准分配，我们还需要考虑分布式资源管理和负载调度技术。
-
业务拆分之后，模块与模块之间又需要对很多共享数据做访问，为了保证安全完整的数据状态，我们也要用到分布式协调与同步技术。
-
到了业务拆分的阶段，数据必然庞大，为了数据存储的可靠，为了保证优秀的数据读写性能，我们需要分布式存储技术。
-
业务如此复杂，为了公司的发展，业务能继续扩大，就需要能更加精准的营销和运营，我们还需要对数据进行实时、离线处理分析，此时，我们又得考虑分布式计算技术。
-
在业务拆分后，整体架构出现了巨变，不可能再用以前集群方式的思维去考虑高可用，那么分布式的可靠性技术又要纳入我们的掌握范畴。
你看分布式系统的技术栈这么多、这么复杂对吧，别慌。
我写这篇文章不是为了劝退你们的，我们要学习必须分步骤分主题的学习，对整体的分布式技术栈分而克之，逐步掌握。
在分布式技术栈中我们可以看到，其实分布式技术是有分类的，我们可以根据不同的分类去掌握每种类别的分布式技术背后的概念和思想。无论分布式技术有多少实现，这些实现永远都是以其所在分类的分布式技术原理作为核心底层来实现的。
同时呢，我们在学习当中，还必须理论联系实际，根据我们的实际开发和架构需要学习。
而且，业务是逐步发展的，项目也不会一下就发展的特别庞大。这就给与了我们分步学习，逐步掌握的时间和机会。
那具体到底如何做呢？
首先，分布式中的根基是什么？就我自己的经历而言，我认为是通信，最重要的其实分布式系统中那些模块中的通信机制。
而通信机制该怎么学习？我认为首先要了解我们可用的各通信机制的区别。其中尤为重要的是了解各通信机制的缺点。对，你没看错，就是缺点。
为什么缺点最重要呢？因为架构师在架构的时候，一项尤为重要的工作就是做技术选型。而技术选型的目标很多时候的应用场景往往非常模糊，如果能了解到各选型的缺点，则对选型的结果是否准确就起到了极其重要的作用。
比如，我们现在想搞模块间通信，那么到底是用 RPC 还是用 MQ ？此时，我们知道 RPC 的缺点和 MQ 的缺点的话，就能很容易做出更准确的选型。
RPC 的缺点:
-
不能搞流量削锋
-
不能广播给多个模块
-
消息投递没有保证
-
模块和模块之间没法解耦
MQ 的缺点：
-
不能保证延迟时间
-
不适合搞强一致性的事务
-
增加了系统的复杂度
读者福利
由于篇幅过长，就不展示所有面试题了，感兴趣的小伙伴
更多笔记分享
转存中…(img-vZCW9QBM-1714892311555)]
[外链图片转存中…(img-DvlSwcV0-1714892311556)]
更多笔记分享
[外链图片转存中…(img-lVEtGjDM-1714892311556)]
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
