- 提高系统的可用性,避免单点故障
- 通过负载均衡不同的副本,提高性能
- 不同副本间数据同步需要时间,数据一致性 可用性的问题,也就是CAP理论
如何保证数据的一致性,同时不影响性能,是分布式系统需要权衡的,进而提出:
- 强一致性(读写一致)
- 弱一致性(不承诺读写一致时间,但尽快读写一致,时间未定)
- 最终一致性(是弱一致性的特例,保证在一定的时间内,达到数据一致,业界推荐)
- 通信异常(数据传输,路由过程中,硬件和系统不可用导致)
- 网络分区(分布式系统中部分节点之间不能通信)
- 三态(成功,失败,超时)
- 节点故障
角色如下 协调者:全局事务 参与者:本地事务
2PC(two-phase commit)
- 协调者向所有参与者发送提交请求
- 参与者执行本地事务
- 参与者反馈执行是否成功,或者超时(失败)
- 协调者根据一阶段的反馈,向所有参与者发送commit或者rollback
- 参与者对本地事务执行commit或者rollback,释放资源
- 反馈回滚结果
- 单点问题(协调者挂了,参与者没接到通知,处于阻塞)
- 同步阻塞(参与者听从协调者统一调度,不能从事其他操作)
- 数据不一致(网络问题,只有部分参与者收到commit操作,其他参与者阻塞,产生数据不一致)
协调者向参与者发送是否可以执行事务,并收到反馈
协调者向参与者发送执行事务,并收到反馈,如果参与者等待超时,中断事务
根据事务执行情况,commit或者rollback
3PC引入了参与者超时机制,假设协调者挂掉,不会一直阻塞等待协调者的通知,但仍然无法避免数据的不一致性 所以一般分布式系统最求最终一致性
利用消息中间件来异步完成事务的后一半更新,实现系统的最终一致性
TCC事务是Try、Commit、Cancel三种指令的缩写,其逻辑模式类似于XA两阶段提交,但是实现方式是在代码层面来人为实现