Java工程师该何去何从,oppoJava面试

语言: CN / TW / HK

背景知识

CAP定理

CAP定理,又被叫作布鲁尔定理。对于设计分布式系统来说(不仅仅是分布式事务)的架构师来说,CAP就是你的入门理论。

? C (一致性):对某个指定的客户端来说,读操作能返回最新的写操作。对于数据分布在不同节点上的数据上来说,如果在某个节点更新了数据,那么在其他节点如果都能读取到这个最新的数据,那么就称为强一致,如果有某个节点没有读取到,那就是分布式不一致。

? A (可用性):非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)。可用性的两个关键一个是合理的时间,一个是合理的响应。合理的时间指的是请求不能无限被阻塞,应该在合理的时间给出返回。合理的响应指的是系统应该明确返回结果并且结果是正确的,这里的正确指的是比如应该返回50,而不是返回40。

? P (分区容错性):当出现网络分区后,系统能够继续工作。打个比方,这里个集群有多台机器,有台机器网络出现了问题,但是这个集群仍然可以正常工作。

BASE理论

BASE 理论指的是基本可用 Basically Available,软状态 Soft State,最终一致性 Eventual Consistency,核心思想是即便无法做到强一致性,但应该采用适合的方式保证最终一致性,是对CAP中AP的一个扩展。

BASE,Basically Available Soft State Eventual Consistency 的简写:

BA:Basically Available 基本可用,分布式系统在出现故障的时候,允许损失部分可用性,即保证核心可用。

S:Soft State 软状态,允许系统存在中间状态,而该中间状态不会影响系统整体可用性。

E:Consistency 最终一致性,系统中的所有数据副本经过一定时间后,最终能够达到一致的状态。

BASE 理论本质上是对 CAP 理论的延伸,是对 CAP 中 AP 方案的一个补充。

柔性事务

不同于 ACID 的刚性事务,在分布式场景下基于 BASE 理论,就出现了柔性事务的概念。要想通过柔性事务来达到最终的一致性,就需要依赖于一些特性,这些特性在具体的方案中不一定都要满足,因为不同的方案要求不一样;但是都不满足的话,是不可能做柔性事务的。

幂等操作

在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数,或幂等方法,是指可以使用相同参数重复执行,并能获得相同结果的函数。这些函数不会影响系统状态,也不用担心重复执行会对系统造成改变。例如,支付流程中第三方支付系统告知系统中某个订单支付成功,接收该支付回调接口在网络正常的情况下无论操作多少次都应该返回成功。

为什么需要分布式事务

随着业务的发展及服务的SOA化,一些大的操作往往由不同的小操作组成,而这些小的操作分布在不同的服务器上,分布式事务需要保证这些小操作要么全部成功,要么全部失败。从本质上来说,分布式事务是为了保证不同数据库的数据一致性。可能应用分布式事务的场景有:

  1. 数据库分库分表

当数据库单表数据达到千万级别,就要考虑分库分表,那么就会从原来的一个数据库变成多个数据库。例如如果一个操作即操作了01库,又操作了02库,而且又要保证数据的一致性,那么就要用到分布式事务。

  1. 应用SOA化

所谓的SOA化,就是业务的服务化。例如电商平台下单操作就会产生调用库存服务扣减库存和订单服务更新订单数据,那么就会设计到订单数据库和库存数据库,为了保证数据的一致性,就需要用到分布式事务。

两套协议、四类常见方案

两套协议是指两阶段提交协议2PC和三阶段提交协议3PC

四类常见方案这里我们介绍以下分布式事务解决方案:Tcc、可靠消息最终一致性、最大努力通知、Saga

两套协议

两阶段提交协议2PC

两阶段提交(2PC) 是 Oracle Tuxedo 系统提出的 XA 分布式事务协议的其中一种实现方式。

XA协议中有两个重要角色:事务协调者事务参与者

漫话图解

2PC协议有两个阶段:Propose和Commit. 在无failure情况下的2PC协议流程的画风是这样的:

? Propose阶段:

? coordinator: “昨夜验人有惊喜, 今天都投票出六娃”

? voter1/voter2/voter3: “好的女王大人!”

? Commit阶段

? coordinator: “投六娃”

? voter1/voter2/voter3: “投了女王大人!” (画外音: 六娃扑街)

四面楚歌的Java工程师该何去何从,oppoJava面试_后端

图1: 2PC, coordinator提议通过, voter{1,2,3}达成新的共识

如果有至少一个voter (比如voter3)在Propose阶段投了反对票, 那么propose通过失败. coordinator就会在Commit(or abort)阶段跟所有voter说, 放弃这个propose.

四面楚歌的Java工程师该何去何从,oppoJava面试_后端_02

图2: 2PC, coordinator提议没有通过, voter{1,2,3}保持旧有的共识

具体流程

分布式事务中2PC的具体流程是这样的:

第一阶段

? 顺利的情况

  1. 事务协调者的节点会首先向所有的参与者节点发送 Prepare(预备) 请求。

  2. 在接到 Prepare(预备) 请求之后,每一个参与者节点会各自执行与事务有关的数据更新,写入Undo Log和Redo Log。

  3. 参与者执行成功,暂时不提交事务,向事务协调节点返回done(完成)消息。

  4. 进入第二阶段

? 出错时

在XA的第一阶段,如果某个事务参与者反馈失败消息,说明该节点的本地事务执行不成功,必须回滚。

  1. 事务协调者的节点会首先向所有的参与者节点发送 Prepare(预备) 请求。

  2. 在接到 Prepare(预备) 请求之后,每一个参与者节点会各自执行与事务有关的数据更新,写入Undo Log和Redo Log。

  3. 参与者执行失败,返回失败消息。

  4. 协调者中断事务

中断事务

任何一个参与者向协调者反馈了 No 响应,或者在等待超时之后,协调者尚无法接收到所有参与者的反馈响应,那么就会中断事物。

  1. 发送回滚请求。协调者向所有参与者节点发出 Rollback 请求。

  2. 事物回滚。参与者收到Rollback请求之后,会利用其在阶段一种记录的 Undo 信息来执行事务回滚操作,并在完成回滚之后释放在整个事物执行期间占用的资源。

  3. 反馈事物回滚结果。参与者在完成事物回滚之后,向协调者发送 Ack 消息。

  4. 中断事务

第二阶段

在XA分布式事务的第二阶段,如果事务协调节点在之前所收到都是正向返回,那么它将会向所有事务参与者发出Commit请求。

接到Commit请求之后,事务参与者节点会各自进行本地的事务提交,并释放锁资源。当本地事务完成提交后,将会向事务协调者返回“完成”消息。

当事务协调者接收到所有事务参与者的“完成”反馈,整个分布式事务完成。郑州人流医院哪家好http://www.ytsg029.com /

优缺点

优点

2PC是强一致(要打个问号)协议:

  1. 预备、提交两个阶段保证了事务是原子的

  2. 2PC是允许读-写隔离的,这意味着某个字段的变更在事务协调者提交之前是不可见的。

缺点

  1. 同步阻塞:当参与事务者存在占用公共资源的情况,其中一个占用了资源,其他事务参与者就只能阻塞等待资源释放,处于阻塞状态。

  2. 单点故障:一旦事务管理器出现故障,整个系统不可用

  3. 数据不一致:在阶段二,如果事务管理器只发送了部分 commit 消息,此时网络发生异常,那么只有部分参与者接收到 commit 消息,也就是说只有部分参与者提交了事务,使得系统数据不一致。

  4. 不确定性:当协事务管理器发送 commit 之后,并且此时只有一个参与者收到了 commit,那么当该参与者与事务管理器同时宕机之后,重新选举的事务管理器无法确定该条消息是否提交成功。