Skip to content

Latest commit

 

History

History
89 lines (49 loc) · 2.62 KB

8一致性协议.md

File metadata and controls

89 lines (49 loc) · 2.62 KB

一致性协议

一致性协议

分布式的好处

  1. 提高系统的可用性,避免单点故障
  2. 通过负载均衡不同的副本,提高性能

分布式带来的问题

  1. 不同副本间数据同步需要时间,数据一致性 可用性的问题,也就是CAP理论

分布式一致性级别

如何保证数据的一致性,同时不影响性能,是分布式系统需要权衡的,进而提出:

  1. 强一致性(读写一致)
  2. 弱一致性(不承诺读写一致时间,但尽快读写一致,时间未定)
  3. 最终一致性(是弱一致性的特例,保证在一定的时间内,达到数据一致,业界推荐)

分布式环境的问题

  1. 通信异常(数据传输,路由过程中,硬件和系统不可用导致)
  2. 网络分区(分布式系统中部分节点之间不能通信)
  3. 三态(成功,失败,超时)
  4. 节点故障

2PC和3PC

参考

角色如下 协调者:全局事务 参与者:本地事务

2PC(two-phase commit)

一阶段:
  1. 协调者向所有参与者发送提交请求
  2. 参与者执行本地事务
  3. 参与者反馈执行是否成功,或者超时(失败)
二阶段:
  1. 协调者根据一阶段的反馈,向所有参与者发送commit或者rollback
  2. 参与者对本地事务执行commit或者rollback,释放资源
  3. 反馈回滚结果
缺点:
  1. 单点问题(协调者挂了,参与者没接到通知,处于阻塞)
  2. 同步阻塞(参与者听从协调者统一调度,不能从事其他操作)
  3. 数据不一致(网络问题,只有部分参与者收到commit操作,其他参与者阻塞,产生数据不一致)
一阶段(can_commit)

协调者向参与者发送是否可以执行事务,并收到反馈

二阶段(pre_commit)

协调者向参与者发送执行事务,并收到反馈,如果参与者等待超时,中断事务

三阶段(commit)

根据事务执行情况,commit或者rollback

2PC和3PC比较

3PC引入了参与者超时机制,假设协调者挂掉,不会一直阻塞等待协调者的通知,但仍然无法避免数据的不一致性 所以一般分布式系统最求最终一致性

MQ事务

利用消息中间件来异步完成事务的后一半更新,实现系统的最终一致性

TCC事务

TCC事务是Try、Commit、Cancel三种指令的缩写,其逻辑模式类似于XA两阶段提交,但是实现方式是在代码层面来人为实现