本文最后更新于300 天前,其中的信息可能已经过时,如有错误请发送邮件到big_fw@foxmail.com
CAP理论
任何分布式系统架构方案都不可能同时满足这3个目标,这个结论就叫做 CAP 定理
- Consistency(一致性)
- Availability(可用性)
- Partition tolerance (分区容错性)
BASE理论
- Basically Available ( 基本可用 ) :分布式系统在出现故障时,允许损失部分可用性,即保证核心可用。
- Soft State ( 软状态 ): 在一定时间内,允许出现中间状态,比如临时的不一致状态。
- Eventually Consistent ( 最终一致性 ):虽然无法保证强一致性,但是在软状态结束后,最终达到数据一致。
解决分布式事务的思想也是这样,有两个方向:
- AP思想:各个子事务分别执行和提交,无需锁定数据。允许出现结果不一致,然后采用弥补措施恢复,实现最终一致即可。例如
AT
模式就是如此 - CP思想:各个子事务执行后不要提交,而是等待彼此结果,然后同时提交或回滚。在这个过程中锁定资源,不允许其它人访问,数据处于不可用状态,但能保证一致性。例如
XA
模式
AT模式的脏写问题
解决思路就是引入了全局锁的概念。在释放DB锁之前,先拿到全局锁。避免同一时刻有另外一个事务来操作当前数据。
TCC模式
TCC模式与AT模式非常相似,每阶段都是独立事务,不同的是TCC通过人工编码来实现数据恢复。
TCC模式的每个阶段是做什么的?
- Try:资源检查和预留
- Confirm:业务执行和提交
- Cancel:预留资源的释放
TCC的优点是什么?
- 一阶段完成直接提交事务,释放数据库资源,性能好
- 相比AT模型,无需生成快照,无需使用全局锁,性能最强
- 不依赖数据库事务,而是依赖补偿操作,可以用于非事务型数据库
TCC的缺点是什么?
- 有代码侵入,需要人为编写try、Confirm和Cancel接口,太麻烦
- 软状态,事务是最终一致
- 需要考虑Confirm和Cancel的失败情况,做好幂等处理、事务悬挂和空回滚处理