校招后端面经--分布式
1. 分布式系统保证事务的一致性
0.cap定理
consistency: 一致性,所有数据节点上的数据一致性和正确性
availability:可用性,每个操作总能在一定的时间内返回结果
partition tolerance:分区容错,是否可以对数据进行分区
强一致性:一修改,马上更新,用户拿到永远是最新的消息
弱一致性:不保证用户会马上拿到最新的消息
最终一致性:弱一致性的一种特例,系统保证在没有后续更新的前提下,返回上一次更新的结果。
1.主从复制
一台机器负责数据的更新,其他机器负责从主机器上同步数据。
2.两阶段提交
过程
(1)协调者向所有参与者发送事务执行的请求,并等待所有参与者反馈事务的执行结果。事务参与者收到请求后,执行事务,并记录到事务日志里面,但不真正提交。参与者将自己事务的执行情况反馈给协调者,同时阻塞等待协调者的后续指令
(2)当所有参与者都能够正常执行事务后,协调者向各个参与者发送commit通知,请求提交事务。参与者收到事务提交通知之后,执行commit的操作,然后释放占有的资源。参与者向协调者返回事务提交的结果。
(3)当一个或者多个参与者回复事务执行失败或者协调者等待超时,协调者向各个参与者发送事务回滚的请求。参与者收到事务回滚通知后,执行回滚操作,并释放占有的资源。参与者向协调者反馈回滚的信息。
缺点
(1)同步阻塞:当参与者占用第三方资源等待协调者的通知时,其他第三方节点不能访问当前的资源
(2)单点故障:一旦协调者发生故障,参与者会一直阻塞下去,尤其是第二阶段,所有的参与者还处在锁定事务资源的状态,无法继续完成事务操作。
(3)数据的不一致性:在第二阶段中,当局部网络异常或者协调者在发送commit请求的时候出现故障,会导致一部分参与者没有收到commit请求,一部分收到,这样会导致数据的部分一致性
3.三阶段提交
过程
将原本两阶段提交的第一阶段一分为二;对参与者引入超时机制
(1)协调者询问参与者是否能正常执行事务,如果协调者接收到所有参与者返回的确定信息,则再向所有参与者发送执行事务的请求
(2)参与者执行事务,并将事务记录在日志中,但不真正提交,并将事务的执行情况返回给协调者,协调者收到所有参与者的确认消息后向所有参与者发送提交通知,若收到一个或者多个异常的消息&