友链
导航
These are the good times in your life,
so put on a smile and it'll be alright
友链
导航
柔性事务在阿里内部的几种实现
使用场景:淘宝下单
通过消息队列传输事务,事务消息的特点是在事务 confirm 后再 publish,提交但没有 confirm 时会由队列服务主动查询。
存在问题:
示例如下,其中有个关键是要分解事务,交易的第一步是 扣减库存,库存没了就下不了单:
使用场景:支付宝业务和账务交互
XTS是TCC(Try/Confirm/Cancel)型事务,属于典型的补偿型事务。
XTS给开发人员提供了一个实现分布式事务的事务框架,主要负责事务日志的记录,事务的参与者需要实现XTS提供的接口,以实现XTS框架对事务参与者的事务协调和控制。与消息分布式事务相比,实现了更好的框架,但开发模式不变,也需要人工写补偿机制。
TCC 事务模型:
XTS 架构:
Try 准备阶段:
Confirm 确认阶段:
Cancel 回滚阶段:
定位:
开源版本 Seata:https://github.com/seata/seata (Simple Extensible Autonomous Transaction Architecture)
阿里云版本 GTS:https://help.aliyun.com/product/48444.html
目前只支持 Java
架构图中的RM(Resource Manager)为资源管理器,一般管理多个TXC数据源,负责在TXC客户端进行数据源访问时,与TXC服务器进行事务的注册和状态更新。TXC数据源是在原有的数据源基础上做了一层较薄的封装,因为TXC需要拦截和捕捉到所有TXC客户端对于数据库进行的数据修改,从而为事务的自动回滚提供数据的原始值。
相比于传统的两阶段提交方式,最大的区别在于XA在准备阶段是没有提交本地事务的,而TXC则是立即执行并可见,在隔离性级别上实现的是读未提交(read uncommitted),所以避免了在分布式事务中对于数据的长时间锁占用。也就是说,TXC在允许数据脏读的业务场景中,能充分发挥性能上的优势。比如商品在大促秒杀场景下,允许商品的库存在事务没有提交前给前端应用提供查询,只不过在最后订单扣减库存时进行控制,避免商品超卖现场的发生。如果业务场景不允许数据的脏读,TXC平台也支持select for update以及提供@hint的功能临时提升事务的隔离级别。
同时,TXC服务器端会记录当前处理事务对数据库中进行了修改数据的信息(行信息),当有其他事务也要对这些数据进行修改操作时,TXC服务端会协调两个事务间的执行,避免在第一个事务没有提交前,同样的数据会被另一个事务对该数据进行修改。从本质来说,将原来传统事务场景下,由数据库提供的锁机制提升到了TXC服务端进行了实现,这样相比于数据库锁的实现成本更加轻量,加上TXC本身服务能力的扩展能力,最终在同样实现事务隔离性的前提下,大大提升了整体的数据库处理吞吐率。
TXC两阶段提交实现。TXC也是基于两阶段提交理论实现,由TXC服务器负责整体的事务协调和管理,由部署在TXC客户端上的资源管理器组件实现各客户端与TXC服务器的事务注册、状态更新、提交等操作,一个标准的两阶段提交事务处理时序图如下图所示(Clt 是 Client 本地,HSF 是远程调用)。
回滚的原理: