校招后端面经——分布式

1. 分布式系统保证事务的一致性

0.cap定理

consistency: 一致性，所有数据节点上的数据一致性和正确性

availability:可用性，每个操作总能在一定的时间内返回结果

partition tolerance：分区容错，是否可以对数据进行分区

强一致性：一修改，马上更新，用户拿到永远是最新的消息

弱一致性：不保证用户会马上拿到最新的消息

最终一致性：弱一致性的一种特例，系统保证在没有后续更新的前提下，返回上一次更新的结果。

1.主从复制

一台机器负责数据的更新，其他机器负责从主机器上同步数据。

2.两阶段提交

过程

（1）协调者向所有参与者发送事务执行的请求，并等待所有参与者反馈事务的执行结果。事务参与者收到请求后，执行事务，并记录到事务日志里面，但不真正提交。参与者将自己事务的执行情况反馈给协调者，同时阻塞等待协调者的后续指令

（2）当所有参与者都能够正常执行事务后，协调者向各个参与者发送commit通知，请求提交事务。参与者收到事务提交通知之后，执行commit的操作，然后释放占有的资源。参与者向协调者返回事务提交的结果。

（3）当一个或者多个参与者回复事务执行失败或者协调者等待超时，协调者向各个参与者发送事务回滚的请求。参与者收到事务回滚通知后，执行回滚操作，并释放占有的资源。参与者向协调者反馈回滚的信息。

缺点

（1）同步阻塞：当参与者占用第三方资源等待协调者的通知时，其他第三方节点不能访问当前的资源

（2）单点故障：一旦协调者发生故障，参与者会一直阻塞下去，尤其是第二阶段，所有的参与者还处在锁定事务资源的状态，无法继续完成事务操作。

（3）数据的不一致性：在第二阶段中，当局部网络异常或者协调者在发送commit请求的时候出现故障，会导致一部分参与者没有收到commit请求，一部分收到，这样会导致数据的部分一致性

3.三阶段提交

过程

将原本两阶段提交的第一阶段一分为二；对参与者引入超时机制

（1）协调者询问参与者是否能正常执行事务，如果协调者接收到所有参与者返回的确定信息，则再向所有参与者发送执行事务的请求

（2）参与者执行事务，并将事务记录在日志中，但不真正提交，并将事务的执行情况返回给协调者，协调者收到所有参与者的确认消息后向所有参与者发送提交通知，若收到一个或者多个异常的消息&