사전 처리 시도: 비즈니스 검사 및 리소스 예약을 수행합니다.
확인: 업무 확인을 합니다.
취소 실행 취소: 롤백 작업을 수행합니다.
TM 은 먼저 모든 spoke 트랜잭션의 try 작업을 시작합니다. Spoke 트랜잭션의 try 작업이 실패하면 TM 은 모든 spoke 트랜잭션의 Cancel 작업을 시작합니다. 시도가 모두 성공하면 TM 은 모든 spoke 트랜잭션에 대한 확인 작업을 시작합니다. 여기서 확인 및 취소 작업이 실패하면 TM 은 다시 시도합니다.
1)try 단계는 비즈니스 검사 (일관성) 및 리소스 예약 (격리) 을 수행하는 것입니다.
2)2) 확인 단계는 확인 제출이며 Try 단계의 모든 분기 트랜잭션이 성공적으로 실행되어 확인이 시작됩니다.
일반적으로 TCC 를 사용할 때 확인 단계에서 오류가 발생하지 않을 것으로 예상됩니다. 성공만 시도하면 확인이 성공합니다. 확인 중에 오류가 발생하면 다시 시도하거나 수동으로 하십시오.
3) 취소 단계는 업무 실행 오류에 롤백이 필요할 때 실패하지 않은 다른 분기 거래를 취소하는 것입니다. 즉, 예약된 자원을 해제합니다.
일반적으로 TCC 의 취소 단계도 성공한 것으로 간주되며 오류가 있을 경우 재시도 또는 수동 처리가 도입됩니다.
다음 프레임워크는 모두 TCC 글로벌 트랜잭션을 지원합니다. 현재 아리세타는 엄청난 사용자 기반을 보유하고 있으며, github 의 star 수도 훨씬 앞서고 있으며, seata 의 실제 소스 코드도 점차 증가할 것이다.
Try 단계에서 네트워크 시간 초과로 인해 서비스 A 에 Try 요청이 전송되었다고 가정합니다. 이 시점에서 조정자는 네트워크 시간 초과에 대한 응답을 수신하므로 두 번째 단계에서 취소해야 합니다. 그러나 서비스 A 는 시도 단계에서 전혀 성공하지 못하여 데이터 불일치를 야기했습니다.
문제 해결의 관건은 Try 단계에서 서비스 A 가 성공적으로 실행되었는지, 성공하면 commit, 실패하면 빈 롤백을 수행하는 방법입니다. 분기 트랜잭션 로그 테이블을 추가하여 분기 트랜잭션과 글로벌 트랜잭션 id 를 기록할 수 있습니다. 요청이 시간 초과될 때 이 테이블을 통해 분기 트랜잭션을 볼 수 있으며 Try 를 수행한 경우 기록할 수 있습니다. 하지 않으면 빈 되감기.
주로 시도 단계에 있습니다. 거래 상태 테이블을 추가하여 이전 질의를 확인하거나 취소합니다.
보다 엄격한 요구 사항은 분산 잠금을 추가하는 것입니다.
시간 초과 등으로 인해 try 전에 cancel 을 실행하는 것은 일시 중지 문제입니다.
해결책은 지점거래 기록표를 하나 추가하여 먼저 문의하는 것이다. Cancel 이 이미 실행된 경우 try 가 실행되지 않습니다.