ORACLE分散式事務鎖各種場景下的處理詳解
分散式事務概念
資料庫分散式事務是指同一事務中DML 語句對兩個或多個資料庫進行修改，為確保事務原子性，事務內的所有操作只能一起提交或一起回滾。ORACLE 使用DATABASE LINK 實現分散式事務。
insert into dept@remote_db values (41,'SUPPORT','BRUSSELS'); -- 遠端資料庫插入
insert into emp values (1041,'MULDER',10); -- 本地資料庫插入
commit;
1.Global Coordinator ：分佈事務的發起者，負責協調這個分佈事務。
2.Commit Point Site ：在分佈事務中，首先執行 COMMIT 或 ROLLBACK 操作的站點。一般可以把業務中的關鍵資料庫作為 Commit Point Site 。 Commit Point Site 與其它站點不同，事務不會進入 prepared 狀態，不會存在 IN-DOUBT （懸疑）事務，也不會因為分散式事務的失敗而導致相關表被阻塞。
資料庫相關引數：
COMMIT_POINT_STRENGTH ，預設為 1 ，數值大的為 Commit Point Site 。兩值相同時一般遠端資料庫為 Commit Point Site 。
Doc ID 126069.1
STAGES PHASE CRASH-TEST-NR's
------------ -------- ---------------
(02) -> (06) PREPARE 1, 2, 3, 4
(07) -> (13) COMMIT 5, 6, 7, 8, 9
(14) -> (16) FORGET 10
1 ．準備階段（ PREPARE PHASE ）
(01) The global coordinator initiates and commits the distributed transaction.During execution of the SQL statements within the transaction, the definition of the session tree is completed (-> dba_2pc_neighbors).
全域性協調器發起分散式事務提交
(02) The commit point site is determined (commit_point_strength) and the SCNs (System Change Number) of the communicating nodes are oordinated.The highest SCN at all nodes is determined. This will be the commit SCN at the commit point site later on (-> highest global SCN -> global integrity).
確認 commit point site ，取得所有節點中 SCN 最大的節點值，將最高的 SCN 號作為分佈事物的全域性 SCN 號，保證全域性完整性。
(03) The global coordinator asks participating 參與節點 nodes other than the commit point site to promise to commit or roll back (-> prepare message) the transaction, even if there is a failure. If any node cannot prepare,the transaction is rolled back.
等待其它參與節點返回資訊確認是否提交或回滾事務，如果有節點不能 prepare ，那事務進行回滾
(04) Every participating node allocates resources it needs to commit or rollback the transaction if data is changed.
It saves redo records corresponding to changes made by the transaction to its online redo log. This makes it possible to recover the database back to the prepare state in case of an instance failure.
The node guarantees that locks held for the transaction are able to survive a failure.
重新整理日誌到日誌檔案
(05) All participating nodes place a distributed lock on modified tables preventing reads/writes.
對分佈事物修改的表加分散式鎖，防止被 讀寫
(06) All participating nodes respond with a prepared message to their global/local coordinator and wait until a commit or rollback request is received from the global/local coordinator.
After the nodes are prepared, the distributed transaction is said to be in-doubt.
Note that all participating nodes need to be prepared for the two phase commit to continue to the next phase (-> commit phase).
所有參與節點通知並等待協調器的提交或者回滾請求，並將事務切換成 in-doubt 存疑狀態。
2 ．提交階段（ COMMIT PHASE ）
(07) The global coordinator instructs the commit point site to commit.
全域性協調器發起提交點站點提交
(08) The commit point site commits with the highest SCN (see step 02).
提交點站點提交
(09) The commit point site informs the global coordinator of the commit.
提交點站點返回提交資訊
(10) The global/local coordinator instructs all the participating nodes to commit.
其它參與者進行提交
(11) Every node commits the local portion of the distributed transaction and releases locks.
提交本地事務並釋放鎖
(12) Every node records an additional redo entry in the local redo log indicating that the transaction has commited.
寫日誌
(13) The participating nodes notify the global coordinator that they have committed.
On completion of the commit phase, the data on all nodes of the distributed system is consistent with one another.
所有參與節點返回提交完成資訊，完成提交
3 ．登出階段（ FORGET PHASE ）
(14) After receiving notice from the global coordinator that all nodes have committed, the commit point site erases status information about this transaction.
接收到提交資訊後，提交點站點清理事務資訊
(15) The commit point site informs the global coordinator that it has erased the status information.
commit point site 返回訊息
(16) The global coordinator erases its own information about the transaction.
global coordinator 清理本次事務的相關資訊。
此時分佈事物的兩階段提交全部完成。
如果兩階段提交完成之前，資料庫或網路出現異常，分佈事物處於 IN_DOUBT 狀態。相關狀態會記錄到 dba_2pc_pending 檢視中。一旦資料庫或網路恢復正常， RECO 程式會自動處理 IN_DOUBT 狀態的分佈事物。少數情況需要 DBA 手工處理 IN_DOUBT 狀態的分佈事物。
ORACLE 提供的用於模擬分散式事務各階段異常的COMMIT COMMENT
參見： Doc ID 126069.
COMMIT COMMENT 'ORA-2PC-CRASH-TEST-n';
where n is one of the following integers:
n Effect
1 Crash commit point site after collect
2 Crash non-commit point site after collect
3 Crash before prepare (non-commit point site)
4 Crash after prepare (non-commit point site)
5 Crash commit point site before commit
6 Crash commit point site after commit
7 Crash non-commit point site before commit
8 Crash non-commit point site after commit
9 Crash commit point site before forget
10 Crash non-commit point site before forget
測試指令碼
|
-->>>>>>>>>> Begin of setup_rem.sql <<<<<<<<<<-- /* Execute at the remote site */
connect sys/change_on_install@v817
create user <USER> identified by tiger default tablespace users temporary tablespace temp;
grant dba to <USER>; grant force transaction,force any transaction to <USER>; /* To be able to crash a distributed transaction with COMMIT COMMENT 'ORA-2PC-CRASH-n'; */ grant alter system to <USER>; /* To be able to do ALTER SYSTEM DISABLE/ENABLE DISTRIBUTED RECOVERY; */ grant delete on sys.pending_trans$ to <USER>; grant delete on sys.pending_sessions$ to <USER>; grant delete on sys.pending_sub_sessions$ to <USER>; /* To be able to use DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY */
connect <USER>/tiger@v817
create database link v817rep.be.oracle.com connect to <USER> identified by tiger using 'v817rep.be.oracle.com';
SET TERMOUT OFF SET ECHO OFF CREATE TABLE DEPT (DEPTNO NUMBER(2) CONSTRAINT PK_DEPT PRIMARY KEY, DNAME VARCHAR2(14) , LOC VARCHAR2(13) ) ; CREATE TABLE EMP (EMPNO NUMBER(4) CONSTRAINT PK_EMP PRIMARY KEY, ENAME VARCHAR2(10), DEPTNO NUMBER(2) CONSTRAINT FK_DEPTNO REFERENCES DEPT); INSERT INTO DEPT VALUES (10,'ACCOUNTING','CITY1'); INSERT INTO DEPT VALUES (20,'RESEARCH','CITY2'); INSERT INTO DEPT VALUES (30,'SALES','CITY3'); INSERT INTO DEPT VALUES (40,'OPERATIONS','CITY4'); INSERT INTO EMP VALUES (1000,'NAME1',20); INSERT INTO EMP VALUES (1001,'NAME2',30); INSERT INTO EMP VALUES (1002,'NAME3',30); INSERT INTO EMP VALUES (1003,'NAME4',20); COMMIT; CREATE SYNONYM S_DEPT FOR DEPT@v817rep.be.oracle.com; CREATE SYNONYM S_EMP FOR EMP@v817rep.be.oracle.com; SET TERMOUT ON SET ECHO ON
-->>>>>>>>>> End of setup_rem.sql <<<<<<<<<<--
-->>>>>>>>>> Begin of setup_loc.sql <<<<<<<<<<--
/* Execute at the local site */
connect sys/change_on_install@v817rep
create user <USER> identified by tiger default tablespace users temporary tablespace temp;
grant dba to <USER>; grant force transaction,force any transaction to <USER>; /* To be able to crash a distributed transaction with COMMIT COMMENT 'ORA-2PC-CRASH-n'; */ grant alter system to <USER>; /* To be able to do ALTER SYSTEM DISABLE/ENABLE DISTRIBUTED RECOVERY; */ grant delete on sys.pending_trans$ to <USER>; grant delete on sys.pending_sessions$ to <USER>; grant delete on sys.pending_sub_sessions$ to <USER>; /* To be able to use DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY */
connect <USER>/tiger@v817rep
create database link v817.be.oracle.com connect to <USER> identified by tiger using 'v817.be.oracle.com';
SET TERMOUT OFF SET ECHO OFF CREATE TABLE DEPT (DEPTNO NUMBER(2) CONSTRAINT PK_DEPT PRIMARY KEY, DNAME VARCHAR2(14) , LOC VARCHAR2(13) ) ; CREATE TABLE EMP (EMPNO NUMBER(4) CONSTRAINT PK_EMP PRIMARY KEY, ENAME VARCHAR2(10), DEPTNO NUMBER(2) CONSTRAINT FK_DEPTNO REFERENCES DEPT); INSERT INTO DEPT VALUES (10,'ACCOUNTING','CITY1'); INSERT INTO DEPT VALUES (20,'RESEARCH','CITY2'); INSERT INTO DEPT VALUES (30,'SALES','CITY3'); INSERT INTO DEPT VALUES (40,'OPERATIONS','CITY4'); INSERT INTO EMP VALUES (1000,'NAME1',20); INSERT INTO EMP VALUES (1001,'NAME2',30); INSERT INTO EMP VALUES (1002,'NAME3',30); INSERT INTO EMP VALUES (1003,'NAME4',20); COMMIT; CREATE SYNONYM S_DEPT FOR DEPT@v817.be.oracle.com; CREATE SYNONYM S_EMP FOR EMP@v817.be.oracle.com; SET TERMOUT ON SET ECHO ON
-->>>>>>>>>> End of setup_loc.sql <<<<<<<<<<--
-->>>>>>>>>> Begin of crash_1.sql <<<<<<<<<<--
/* Crash Scenario 1 */ /* Crash commit point site after collect */
connect <USER>/tiger@v817rep alter system disable distributed recovery;
/* DML remote */ /* object s_dept is a synonym for table dept@v817.be.oracle.com */ insert into s_dept values (41,'SUPPORT','BRUSSELS');
/* DML local */ insert into emp values (1041,'MULDER',10); commit comment 'ORA-2PC-CRASH-TEST-1';
|
commit comment 'ORA-2PC-CRASH-TEST-1';
-> after step (06) above
step (06) ：All participating nodes respond with a prepared message to their global/local coordinator and wait until a commit or rollback request is received from the global/local coordinator.
After the nodes are prepared, the distributed transaction is said to be in-doubt.
Note that all participating nodes need to be prepared for the two phase commit to continue to the next phase (-> commit phase).
SQL> connect local/local
Connected.
SQL> alter system disable distributed recovery;
System altered.
SQL> insert into s_dept values (42,'SUPPORT','BRUSSELS');
1 row created.
SQL> insert into emp values (1041,'MULDER',10);
1 row created.
SQL> commit comment 'ORA-2PC-CRASH-TEST-1';
commit comment 'ORA-2PC-CRASH-TEST-1'
*
ERROR at line 1:
ORA-02054: transaction 1.8.664 in-doubt
ORA-02059: ORA-2PC-CRASH-TEST-1 in commit comment
ORA-02063: preceding line from TONODE2
本地資料庫alert 日誌
Error 2059 trapped in 2PC on transaction 1.8.664. Cleaning up.
Error stack returned to user:
ORA-02054: transaction 1.8.664 in-doubt
ORA-02059: ORA-2PC-CRASH-TEST-1 in commit comment
ORA-02063: preceding line from TONODE2
Mon Jan 03 13:52:54 2022
DISTRIB TRAN ORCL.6c28f3e5.1.8.664
is local tran 1.8.664 (hex=01.08.298)
insert pending prepared tran, scn=1002823 (hex=0.000f4d47)
遠端資料庫alert 日誌
Mon Jan 03 13:52:54 2022
Error 2059 trapped in 2PC on transaction 1.11.660. Cleaning up.
Error stack returned to user:
ORA-02059: ORA-2PC-CRASH-TEST-1 in commit comment
遠端節點
SQL> select LOCAL_TRAN_ID,GLOBAL_TRAN_ID,STATE,COMMIT# from dba_2pc_pending;
no rows selected
本地節點
col GLOBAL_TRAN_ID for a40
select LOCAL_TRAN_ID,GLOBAL_TRAN_ID,STATE,COMMIT# from dba_2pc_pending;
LOCAL_TRAN_ID GLOBAL_TRAN_ID STATE COMMIT#
---------------------- ---------------------------------------- ---------------- ----------------
1.8.664 ORCL.6c28f3e5.1.8.664 prepared 1002823
SQL> ROLLBACK FORCE '1.8.664';
Rollback complete.
SQL> COMMIT FORCE '1.8.664';
SQL> select LOCAL_TRAN_ID,GLOBAL_TRAN_ID,STATE,COMMIT# from dba_2pc_pending;
LOCAL_TRAN_ID GLOBAL_TRAN_ID STATE COMMIT#
---------------------- ---------------------------------------- ---------------- ----------------
1.8.664 ORCL.6c28f3e5.1.8.664 forced rollback 1002823
SQL> execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('1.8.664');
PL/SQL procedure successfully completed.
SQL> commit;
Commit complete.
COMMIT COMMENT 'ORA-2PC-CRASH-TEST-5'
Crash commit point site before commit
-> after step (07) above
(07) The global coordinator instructs the commit point site to commit.
SQL> connect local/local
Connected.
SQL> alter system disable distributed recovery;
System altered.
SQL> insert into s_dept values (43,'SUPPORT','BRUSSELS');
1 row created.
SQL> insert into emp values (1043,'MULDER',10);
1 row created.
SQL> commit comment 'ORA-2PC-CRASH-TEST-5';
commit comment 'ORA-2PC-CRASH-TEST-5'
*
ERROR at line 1:
ORA-02054: transaction 5.9.879 in-doubt
ORA-02059: ORA-2PC-CRASH-TEST-5 in commit comment
ORA-02063: preceding line from TONODE2
本地alert 日誌
Mon Jan 03 14:14:56 2022
Error 2059 trapped in 2PC on transaction 5.9.879. Cleaning up.
Mon Jan 03 14:14:56 2022
DISTRIB TRAN ORCL.6c28f3e5.5.9.879
is local tran 5.9.879 (hex=05.09.36f)
insert pending prepared tran, scn=1003725 (hex=0.000f50cd)
Error stack returned to user:
ORA-02054: transaction 5.9.879 in-doubt
ORA-02059: ORA-2PC-CRASH-TEST-5 in commit comment
ORA-02063: preceding line from TONODE2
遠端alert 日誌
Mon Jan 03 14:14:56 2022
Error 2059 trapped in 2PC on transaction 1.14.661. Cleaning up.
Error stack returned to user:
ORA-02059: ORA-2PC-CRASH-TEST-5 in commit comment
遠端節點
SQL> select LOCAL_TRAN_ID,GLOBAL_TRAN_ID,STATE,COMMIT# from dba_2pc_pending;
no rows selected
本地節點
SQL> select LOCAL_TRAN_ID,GLOBAL_TRAN_ID,STATE,COMMIT# from dba_2pc_pending;
LOCAL_TRAN_ID GLOBAL_TRAN_ID STATE COMMIT#
---------------------- ---------------------------------------- ---------------- ----------------
5.9.879 ORCL.6c28f3e5.5.9.879 prepared 1003725
SQL> ROLLBACK FORCE '5.9.879';
Rollback complete.
SQL> select LOCAL_TRAN_ID,GLOBAL_TRAN_ID,STATE,COMMIT# from dba_2pc_pending;
LOCAL_TRAN_ID GLOBAL_TRAN_ID STATE COMMIT#
---------------------- ---------------------------------------- ---------------- ----------------
5.9.879 ORCL.6c28f3e5.5.9.879 forced rollback 1003725
SQL> execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('5.9.879');
PL/SQL procedure successfully completed.
SQL> commit;
Commit complete.
偽行構造
SQL> connect local/local
Connected.
SQL> alter system disable distributed recovery;
System altered.
SQL> insert into s_dept values (46,'SUPPORT','BRUSSELS');
1 row created.
SQL> insert into emp values (1046,'MULDER',10);
1 row created.
SQL> commit comment 'ORA-2PC-CRASH-TEST-4';
commit comment 'ORA-2PC-CRASH-TEST-4'
*
ERROR at line 1:
ORA-02054: transaction 5.26.883 in-doubt
ORA-02059: ORA-2PC-CRASH-TEST-4 in commit comment
本地alert 日誌
Mon Jan 03 18:51:33 2022
Error 2059 trapped in 2PC on transaction 5.26.883. Cleaning up.
Mon Jan 03 18:51:33 2022
DISTRIB TRAN ORCL.6c28f3e5.5.26.883
is local tran 5.26.883 (hex=05.1a.373)
insert pending prepared tran, scn=1045010 (hex=0.000ff212)
Error stack returned to user:
ORA-02054: transaction 5.26.883 in-doubt
ORA-02059: ORA-2PC-CRASH-TEST-4 in commit comment
遠端alert 日誌
無輸出
遠端節點
SQL> select LOCAL_TRAN_ID,GLOBAL_TRAN_ID,STATE,COMMIT# from dba_2pc_pending;
no rows selected
本地節點
SQL> select LOCAL_TRAN_ID,GLOBAL_TRAN_ID,STATE,COMMIT# from dba_2pc_pending;
LOCAL_TRAN_ID GLOBAL_TRAN_ID STATE
---------------------- ---------------------------------------- ----------------
COMMIT#
----------------
5.26.883 ORCL.6c28f3e5.5.26.883 prepared
1045010
SQL> ROLLBACK FORCE '5.26.883 ';
模擬 hang 住
SQL> select * from emp;
ERROR:
ORA-01591: lock held by in-doubt distributed transaction 5.26.883
刪除基表資訊
SQL> set transaction use rollback segment SYSTEM;
SQL> delete from sys.pending_trans$ where local_tran_id = '5.26.883';
SQL> delete from sys.pending_sessions$ where local_tran_id = '5.26.883';
SQL> delete from sys.pending_sub_sessions$ where local_tran_id = '5.26.883';
SQL> commit;
SQL> select * from emp;
ERROR:
ORA-01591: lock held by in-doubt distributed transaction 5.26.883
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 400846848 bytes
Fixed Size 2253664 bytes
Variable Size 176164000 bytes
Database Buffers 218103808 bytes
Redo Buffers 4325376 bytes
Database mounted.
Database opened.
SQL> conn local/local
Connected.
重啟資料庫後事務未釋放
SQL> select * from emp;
ERROR:
ORA-01591: lock held by in-doubt distributed transaction 5.26.883
SQL> select LOCAL_TRAN_ID,GLOBAL_TRAN_ID,STATE,COMMIT# from dba_2pc_pending;
no rows selected
SQL> SELECT KTUXEUSN, KTUXESLT, KTUXESQN, /* Transaction ID */ KTUXESTA Status,KTUXECFL Flags FROM x$ktuxe WHERE ktuxesta!='INACTIVE' AND ktuxeusn= 5;
KTUXEUSN KTUXESLT KTUXESQN STATUS FLAGS
---------- ---------- ---------- ---------------- ------------------------
5 26 883 PREPARED SCO|COL|REV|DEAD
SQL> commit force '5.26.883';
commit force '5.26.883'
*
ERROR at line 1:
ORA-02058: no prepared transaction found with ID 5.26.883
SQL> rollback force '5.26.883';
rollback force '5.26.883'
*
ERROR at line 1:
ORA-02058: no prepared transaction found with ID 5.26.883
raises ORA-02058 since dba_2pc views are empty. In order to use commit force or rollback force a dummy record should be inserted into pending_trans$ as follows:
insert into pending_trans$ (
LOCAL_TRAN_ID,
GLOBAL_TRAN_FMT,
GLOBAL_ORACLE_ID,
STATE,
STATUS,
SESSION_VECTOR,
RECO_VECTOR,
TYPE#,
FAIL_TIME,
RECO_TIME)
values( '5.26.883', /* <== Replace this with your local tran id */
306206, /* */
'XXXXXXX.12345.1.2.3', /* These values can be used without any */
'prepared','P', /* modification. Most of the values are */
hextoraw( '00000001' ), /* constant. */
hextoraw( '00000000' ), /* */
0, sysdate, sysdate );
insert into pending_sessions$
values( '5.26.883',/* <==Replace only this with your local tran id */
1, hextoraw('05004F003A1500000104'),
'C', 0, 30258592, '',
146
);
commit;
在插入模擬事務資料後，可查詢到事務資訊，強制提交後，事務完成
SQL> select LOCAL_TRAN_ID,GLOBAL_TRAN_ID,STATE,COMMIT# from dba_2pc_pending;
LOCAL_TRAN_ID
----------------------
GLOBAL_TRAN_ID
--------------------------------------------------------------------------------
STATE COMMIT#
---------------- ----------------
5.26.883
XXXXXXX.12345.1.2.3
prepared
commit force '5.26.883';
SQL> execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('5.26.883');
PL/SQL procedure successfully completed.
SQL> commit;
Commit complete.
SQL> select LOCAL_TRAN_ID,GLOBAL_TRAN_ID,STATE,COMMIT# from dba_2pc_pending;
no rows selected
分散式事務的手工處理主要按dba_2pc_pending 的結果來靈活對應。
當 dba_2pc_pending 中的資料時，主要看 state 欄位，
1） 如果state 狀態是prepared ，表示事務未提交或回滾，此時需要手工進行強制回滾或提交。
ROLLBACK FORCE 'transaction_id';
-OR-
COMMIT FORCE 'transaction_id','commit#';
2 ）如果state 狀態是committed, rollback forced 或者commit forced 狀態，表示事務已經完成了，但是在FORGET 階段處理時，資料庫字典的資訊沒能及時清除。此時，我們呼叫oracle 的清理丟失事務資訊的語句就可以完成處理：
execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('5.26.883');
Commit;
當 dba_2pc_pending 中無資料時
有可能基表pending_trans$ ，pending_sessions$ 被執行過刪除操作，此時需要向表中重新插回偽造的資料後再進行強制回滾或提交。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23732248/viewspace-2887277/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 各種分散式事務的實現方式適用的場景分散式
- 一次ORACLE分散式事務鎖異常處理分析Oracle分散式
- Oracle分散式事務典型案例處理Oracle分散式
- oracle分散式事務異常處理方法Oracle分散式
- ORACLE懸疑分散式事務問題處理Oracle分散式
- 分散式事務處理方案，微服事務處理方案分散式
- 一文弄懂分散式場景中各種鎖的原理及使用分散式
- Laravel 分散式事務處理Laravel分散式
- springcloud分散式事務處理 LCNSpringGCCloud分散式
- 阿里是如何處理分散式事務的阿里分散式
- .NET開源的處理分散式事務的解決方案分散式
- 詳解 Redis 分散式鎖的 5 種方案Redis分散式
- 分散式事務解決方案與適用場景分析分散式
- 13.SpringCloudSeata處理分散式事務SpringGCCloud分散式
- SpringCloud Alibaba Seata處理分散式事務SpringGCCloud分散式
- 【分散式鎖的演化】“超賣場景”，MySQL分散式鎖篇分散式MySql
- 分散式場景之剛性事務-2PC詳解分散式
- Oracle Gateway for SQL Server時2PC分散式事務異常處理OracleGatewaySQLServer分散式
- MySQL樂觀鎖在分散式場景下的實踐MySql分散式
- etcd分散式鎖及事務分散式
- 淺談ORACLE的分散式事務Oracle分散式
- 開源架構治理平臺 ArchGuard，專治分散式場景下各種不服架構分散式
- 深度分析Redis分散式鎖在電商超賣業務場景下的使用Redis分散式
- T-SQL:事務鎖下的併發處理（十五）SQL
- 詳解Redis分散式鎖Redis分散式
- 分散式系列七: 分散式事務理論分散式
- 分散式鎖和spring事務管理分散式Spring
- TCC和兩階段分散式事務處理的區別分散式
- 使用強大的DBPack處理分散式事務（PHP使用教程）分散式PHP
- 分散式事務（一）—分散式事務的概念分散式
- 微服務分散式事務4種解決方案實戰微服務分散式
- SpringCloud Alibaba(六) - Seata 分散式事務鎖SpringGCCloud分散式
- 分散式事務對於兩階段提交的錯誤處理分散式
- 微服務架構中的分散式事務全面詳解 -DZone微服務微服務架構分散式
- mysql事務處理與鎖機制MySql
- 分散式事務(2）---TCC理論分散式
- Oracle TX鎖的處理Oracle
- 分散式事務的幾種實現方式分散式