分布式事物解决方案

目前采用的三种解决方案:
1、定期校队
2、TCC

Try: 尝试执行业务
完成所有业务检查(一致性)
预留必须业务资源(准隔离性)

Confirm: 确认执行业务
真正执行业务
不作任何业务检查
只使用Try阶段预留的业务资源
Confirm操作满足幂等性

Cancel: 取消执行业务
释放Try阶段预留的业务资源
Cancel操作满足幂等生

3、基于可靠消息
可靠消息
实现:

业务活动的主动方,在完成业务处理的同一个本地事务中,记录消息数据
业务处理事务提交后、通过实时消息通知业务被动方,实时通知成功后删除消息数据
消息恢复系统定期找到未成功发送的消息,交给实时消息服务补发送
约束:

被动方的处理结果不影响主动方的处理
被动方的消息处理操作是幂等操作
成本:

可靠消息系统建设成本
消息数据CRUD成本
适用范围

对最终一致性时间敏感度较高
降低业务被动方实现成本

实现方式2:

业务处理在业务事务提交前,向实时消息服务请求发送消息,实时消息服务只记录消息数据,而不真正发送
业务处理服务在业务事务提交后,向实时消息服务确认发送。只有在得到确认发送指令后,实时消息服务才真正发送消息
业务处理在业务事务回滚后,向实时消息服务取消发送
消息状态确认系统定期找到未确认发送或回溯的消息,向业务处理服务询问消息状态,业务处理服务根据消息ID或消息内容确定该消息是否有效。
成本

一次消息发送需要两次请求
业务处理服务需实现消息状态回查接口
优点:
消息数据独立存储、独立伸缩
降低业务系统与消息系统间的耦合


CAP定理
对于共享数据系统,只能同时拥有以下三项中的两个:
Consistency(一致性): 所有 用户看到一致的数据
Availability(可用性): 对数据更新具备高可用性
Tolerance to Network Partition(分区容忍性): 以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择


分布式事务,本质上是对多个数据库的事务进行统一控制,按照控制力度可以分为:不控制、部分控制和完全控制。不控制就是不引入分布式事务,部分控制就是各种变种的两阶段提交,包括上面提到的消息事务+最终一致性、TCC模式,而完全控制就是完全实现两阶段提交。部分控制的好处是并发量和性能很好,缺点是数据一致性减弱了,完全控制则是牺牲了性能,保障了一致性,具体用哪种方式,最终还是取决于业务场景。作为技术人员,一定不能忘了技术是为业务服务的,不要为了技术而技术,针对不同业务进行技术选型也是一种很重要的能力!

你可能感兴趣的:(事物,数据库)