分布式事務 seata框架AT模式實現原理

seata at 模式

接下來會解析整個執行流程中每乙個階段的具體實現原來。同時為了更好的理解at模式的工作機制，我們以產品表za_product來描述整個流程，表結構如下：

at模式第一階段

@bean
public datasourceproxy datasourceproxy
(druiddatasource druiddatasource)

-- 注意此處0.7.0+ 增加字段 context
create
table
`undo_log`
(`id`
bigint(20
)not
null
auto_increment
,`branch_id`
bigint(20
)not
null
,`xid`
varchar
(100
)not
null
,`context`
varchar
(128
)not
null
,`rollback_info`
longblob
notnull
,`log_status`
int(11)
notnull
,`log_created`
datetime
notnull
,`log_modified`
datetime
notnull
,primary
key(
`id`),
unique
key`ux_undo_log`
(`xid`
,`branch_id`))
engine
=innodb
auto_increment=1
default
charset
=utf8;

update za_product set count = count-
1where product_code =
"gp202103221029"

select id,product_code,count name from za_product where product_code = "gp202103221029"

select id,product_code,count name from za_product where id=

1

,,
]}],
"tablename"
:"product"},
"beforeimage":,
,]}]
,"tablename"
:"product"},
"sqltype"
:"update"}]
,"xid"
:"xid:***"
}

at模式第二階段

事務提交

第乙個步驟中tc並不需要同步知道分支事務的處理結果，所以分支事務才會採用非同步的方式來執行，因為對於提交操作來說，分支事務只需要清理undo_log中的日誌即可，而即使清理失敗，也不會對整個分布式事務產生任何影響。

事務回滾

1關於事務隔離性保證

寫隔離

讀隔離

在資料庫本地事務隔離級別為read committed或者以上時候，seata at事務模式的預設全域性隔離級別是read uncommitted，在該隔離級別，所有事務都可以看到其他未提交事務的執行結果，產生髒讀。這在最終一致性事務模型中是允許存在的，並且在大部分分布式事務場景中可以接受髒讀。

在某些特定場景中要求事務隔離級別必須read committed，目前seata是通過selectforupdateexecutor執行器對select for update語句進行**的，select for update 語句在執行時候回申請全域性鎖。如果全域性鎖已經被其他分支事務持有，則釋放本地鎖（回滾select for update 語句的本地執行）並重試。在這個過程中，查詢請求會被「blocking」，直到全域性鎖被拿到，也就是讀取的相關資料已經提交時候才返回。

分布式事務 seata框架AT模式實現原理

分布式事務框架seata

分布式事務框架 seata初識

seata分布式事務

分布式事務 seata框架AT模式實現原理

分布式事務框架seata

分布式事務框架 seata初識

seata分布式事務

相關推薦