（慕K体系）Java高级工程师学习技术分享
xia讠果☛
www lexuecode com
Java高级技术必学 - 前后端分离开发模式
在当今互联网时代，移动应用和网页应用的发展极大地推动了前后端分离开发模式的兴起。传统的后端渲染方式已经不能满足用户对高性能和优质用户体验的需求，于是前后端分离逐渐成为了一种主流的开发模式。
前后端分离开发模式通过将前端和后端的开发分离，极大地提高了开发效率和团队协作。前端开发人员专注于用户界面和交互逻辑的开发，后端开发人员则专注于数据处理和业务逻辑实现，极大地减少了彼此的依赖和开发时间。
前后端分离开发模式的优势在于能够提高前端性能和用户体验、降低系统的耦合度、支持跨平台开发等。然而，也要面对一些挑战，如跨域问题、对前后端开发人员需求的不同等。因此，团队需要充分了解开发模式的特点和挑战，做好相应的准备和规划。
传统的MVC开发模式痛点
运行存在效率问题：JSP必须在Servlet容器中运行（如Tomcat）。在请求JSP时也需要进行一次编译过程,最后被编译成Java类和class文件,这些都会占用JVM的内存空间。JSP和Java语言关联,在解耦上无法与HTML页面相媲美。
开发人员分工不明确：MVC开发模式工作流程通常是前端工程师编写HTML页面，后端工程师再将HTML页面转换为JSP页面进行逻辑处理和数据展示。在某些紧急情况下,会出现前端工程师调试后端代码，后端工程师调试前端代码现象，分工不明确且沟通成本大，需要前后端一起协调工作。
不利于项目推进：前后端代码耦合度高,模块优化空间小，修改任何前端或后端代码都需要重新发布。前后端开发工程师只能串行工作，无法并行推进项目,项目开发效率低。
无法满足业务需求：前端仅限于浏览器的web应用，无法满足公司业务发展的需要（如Android原生APP、iOS原生APP、微信小程序等）。
什么是前后端分离开发模式
前后端分离开发模式是一种软件开发方法，其中前端和后端的开发是相互独立的，各自负责不同的功能和逻辑。在这种模式下，前端和后端的代码分别处于不同的项目或代码库中，并通过网络接口进行通信。
在前后端分离开发模式中，前端通常是指用户界面和用户交互相关的部分，如网页或移动应用的界面和用户输入验证。前端开发使用的技术栈通常包括HTML、CSS、JavaScript等。而后端则负责处理数据逻辑、业务逻辑和数据库操作等功能。后端开发使用的技术栈通常包括编程语言（如Java、Python、Node.js等）、框架（如Spring Boot、Django、Express等）以及数据库（如MySQL、MongoDB等）。
通过前后端分离开发模式，可以实现前后端开发的并行进行，提高开发效率。而且，前后端分离也有利于团队协作，不同团队可以专注于各自的开发领域，减少开发的耦合性。此外，通过接口的方式进行通信，可以使前端和后端灵活独立地进行部署和扩展。前后端分离开发模式提供了一种灵活、高效、可扩展的方式来构建现代化的Web应用程序。
慕课Java高级工程师课学习-分布式事务与数据一致性
我们追求的技术目标是确保数据的一致性。为此，系统设计必须在任何环境下都能保证数据写入的准确性和可靠性。具体来说，我们关注以下几个核心要求：
- 数据准确性：数据不能有遗漏，不能有错误写入，对于需要顺序的数据，其顺序也不能混乱。
- 时效性：处理时间应尽可能短，以提高系统的响应速度。
- 性能：数据库操作的吞吐量（QPS）应控制在合理范围内，避免过高。
如果这些要求没有得到满足，可能会引发一系列问题，如数据不可追溯、出现脏数据、严重影响业务准确性、问题发现周期长、数据刷新时间长以及系统行为的不可预知性。
分布式事务的定义与理解
在深入探讨如何实现上述技术目标之前，我们首先需要明确分布式事务的概念。在此之前，理解事务的基本概念也是非常重要的。
事务的概念
事务是将应用程序中的多个读、写操作捆绑在一起，形成一个逻辑操作单元。这意味着事务中的所有读写操作要么全部成功（提交），要么全部失败（回滚）。这种机制大大简化了应用层的错误处理。
分布式事务主要分为两大类：
慕课体系数据库内部的分布式事务
某些分布式数据库支持跨数据库节点的内部事务，所有参与节点都运行相同的数据库软件。国内外的软件系统，如TiDB、Oracle和MySQL，都声称支持分布式事务。
异构分布式事务
在异构分布式事务中，涉及两种或两种以上不同的技术实现，例如来自不同供应商的数据库，或者消息中间件等非数据库系统。异构分布式事务要求即使是完全不同的系统，跨系统的分布式事务也必须确保原子提交。
经典理论与模型
经典理论为我们提供了后续实践的理论基础，有助于更好地指导系统设计。
ACID理论
ACID理论是事务处理中最广为人知的经典理论，它指出数据库管理系统（DBMS）在写入或更新数据时，为保证事务的正确可靠性，必须具备的四个特性：
- 原子性（Atomicity）：事务是不可分割的，要么完全执行，要么完全不执行。
- 一致性（Consistency）：事务执行的结果必须使数据库从一个一致的状态转移到另一个一致的状态。
- 隔离性（Isolation）：并发执行的事务之间互相隔离，一个事务的中间状态不能被其他事务看到。
- 持久性（Durability）：一旦事务提交，它对数据库的改变就是永久性的，即使系统故障也不会丢失。
不同的DBMS对ACID特性的实现各有侧重，但都在努力满足这些要求。
CAP原则
CAP原则最初是作为一个经验法则提出的，目的是帮助大家在数据库设计时进行权衡。它指出分布式系统不可能同时满足以下三个条件：
- 一致性（Consistency）：在所有节点上看到的数据是一致的。
- 可用性（Availability）：每个请求都能接收到一个及时响应。
- 分区容忍性（Partition Tolerance）：系统能够继续运行，即使网络分区发生。
在实际应用中，我们通常需要在一致性和可用性之间做出权衡。
BASE理论
BASE理论是对那些无法完全满足ACID标准系统的描述。它强调以下三个关键点：
- 基本可用（Basically Available）：系统保证核心功能可用，但可能响应部分错误。
- 软状态（Soft State）：系统的状态可能会随时间变化，即使没有输入。
- 最终一致性（Eventually Consistent）：系统不需要立即一致，但最终会达到数据一致的状态。
BASE理论是CAP理论的延伸，特别适用于大型分布式系统，它提倡通过牺牲强一致性来获得高可用性。
可线性化
可线性化是一个不常被提及但在实践中非常重要的概念。它指的是在分布式系统中，允许将并发执行的操作以某种顺序线性化，使得它们看起来像是在某个单一的处理器上按顺序执行。
一致性算法的探讨
两阶段提交（2PC）
两阶段提交是一种用于多节点间实现事务原子性提交的算法。它通过一个协调者来协调参与者的行为，并最终决定是否提交事务。算法分为两个阶段：
- 准备阶段：协调者询问所有参与者事务是否执行成功，参与者将执行结果反馈给协调者。
- 提交阶段：如果所有参与者都报告事务执行成功，协调者将通知所有参与者提交事务；否则，协调者将通知参与者回滚事务。
两阶段提交虽然能够保证事务的原子性，但也存在一些问题，如同步阻塞、单点故障问题、数据不一致的风险以及容错能力的不完善。
容错共识算法
共识算法是分布式系统中让多个节点就某项提议达成一致的算法。共识算法需要满足以下性质：
- 协商一致性：所有节点接受相同的决议。
- 诚实性：节点一旦做出决定，就不能更改。
- 合法性：任何决议都是由某个节点提出的。
- 可终止性：只要节点没有崩溃，最终都能达成决议。
著名的容错共识算法包括VSR、Paxos、Raft、Zab和Gossip等。这些算法除了满足共识算法的基本性质外，还叠加了全序关系广播算法，确保消息按照相同的顺序发送到所有节点，并且只发送一次。
