分布式应用有一个比较明显的问题就是,一个业务流程通常需要几个服务来完成,业务的一致性很难保证。为了保障业务一致性,每一步都要在 catch 里去处理前面所有的“回滚”操作,可读性及维护性差,开发效率低下。
分布式事务解决方案中的2PC、3PC、TCC等,大多是提供了事务协调器这一角色,协调业务中的各个事务要么全部成功,要么全部失败,不用在业务中嵌套处理“回滚事务”,更好的解决分布式事务中一致性问题。
Seata 是一款开源的分布式事务解决方案,致力于提供高性能和简单易用的分布式事务服务。为用户提供了 AT、TCC、SAGA 和 XA 事务模式,打造一站式的分布式解决方案。其定义了3个角色完成分布式事务的工作。
其协调流程如下
AT模式是Seata默认的分布式解决方案
AT模式属于两阶段提交协议的演变:
以一个示例来说明整个 AT 分支的工作过程。
业务表:
stock
Field | Type | Key |
---|---|---|
id | bigint(20) | PRI |
goods_id | bigint(20) | |
count | bigint(20) |
业务逻辑:
update stock set count = 20 where goods_id = 100001;
执行过程:
select id,goods_id,count from stock where goods_id = 100001;
得到前镜像
id | goods_id | count |
---|---|---|
1 | 100001 | 0 |
select id, goods_id,count from stock where id = 1;
得到后镜像
id | goods_id | count |
---|---|---|
1 | 100001 | 20 |
{
"branchId": xxxxxxxx,
"undoItems": [{
"afterImage": {
"rows": [{
"fields": [{
"name": "id",
"type": 4,
"value": 1
}, {
"name": "goods_id",
"type": 4,
"value": 100001
}, {
"name": "count",
"type": 4,
"value": 0
}]
}],
"tableName": "stock"
},
"beforeImage": {
"rows": [{
"fields": [{
"name": "id",
"type": 4,
"value": 1
}, {
"name": "goods_id",
"type": 4,
"value": 100001
}, {
"name": "count",
"type": 4,
"value": 20
}]
}],
"tableName": "stock"
},
"sqlType": "UPDATE"
}],
"xid": "xid:xxx"
}
收到 TC 的分支回滚请求,开启一个本地事务,执行如下操作。
update stock set count = 0 where id = 1;
回顾TCC解决方案,其 Try、Confirm、Cancel 3 个方法均由业务编码实现。
以传统的订单、库存、账户服务为例
在 try 阶段尝试预留资源,插入订单、扣减库存、扣减金额,这三个服务都是要提交本地事务的,这里可以把资源转入中间表。
在 commit 阶段,再把 try 阶段预留的资源转入最终表。
而在 cancel 阶段,把 try 阶段预留的资源进行释放,比如把账户金额返回给客户的账户。
TCC 模式在 try 阶段的锁定资源并不是真正意义上的锁定,而是真实提交了本地事务,将资源预留到中间态,并不需要阻塞等待,因此效率比其他模式要高。
Seata中所谓 TCC 模式,是指支持把自定义的分支事务纳入到全局事务的管理中,不依赖于底层数据资源的事务支持,其工作流程如下:
在自定义的逻辑中,可以操作redis完成数据的一致性以提升业务性能。
Saga模式是SEATA提供的长事务解决方案,在Saga模式中,业务流程中每个参与者都提交本地事务,当出现某一个参与者失败则补偿前面已经成功的参与者,一阶段正向服务和二阶段补偿服务都由业务开发实现。
目前SEATA提供的Saga模式是基于状态机引擎来实现的,机制是:
示例状态图:
在 Seata 定义的分布式事务框架内,利用事务资源(数据库、消息服务等)对 XA 协议的支持,以 XA 协议的机制来管理分支事务的一种事务模式。
在当前的技术发展阶段,不存一个分布式事务处理机制可以完美满足所有场景的需求。
一致性、可靠性、易用性、性能等诸多方面的系统设计约束,需要用不同的事务处理机制去满足。
Seata 项目最核心的价值在于:构建一个全面解决分布式事务问题的 标准化 平台。
基于 Seata,上层应用架构可以根据实际场景的需求,灵活选择合适的分布式事务解决方案。
AT是无侵入的分布式事务解决方案,满足大部分分布式事务场景。
TCC 模式是高性能分布式事务解决方案,适用于核心系统等对性能有很高要求的场景。
Saga 模式是长事务解决方案,适用于业务流程长且需要保证事务最终一致性的业务系统。
XA模式也是无侵入的分布式事务解决方案,适用于对一致性要求高的场景。
AT、TCC、Saga 都是补偿型的,补偿型分布式事务机制因为不要求事务资源本身(如数据库)的机制参与,所以无法保证从事务框架之外的全局视角的数据一致性。
比如,一条库存记录,处在补偿型事务处理过程中,由 100 扣减为 50。此时,仓库管理员连接数据库,查询统计库存,就看到当前的 50。之后,事务因为异常回滚,库存会被补偿回滚为100。显然,仓库管理员查询统计到的50就是脏数据。
XA 模式的加入,补齐了 Seata 在全局一致性场景下的缺口,形成 AT、TCC、Saga、XA 四大事务模式的版图,基本可以满足所有场景的分布式事务处理诉求。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。