이 기사는 주로 JAVA 분산 트랜잭션에 대한 심층적인 이해를 소개합니다. 편집자는 이것이 꽤 좋다고 생각합니다. 이제 공유하고 참고용으로 제공하겠습니다. 에디터를 따라 살펴보겠습니다
2. 분산 트랜잭션이 발생하는 이유
2.1. 데이터베이스 하위 데이터베이스 및 하위 테이블
2.2 SOA 적용
위의 두 상황은 겉모습은 다르지만 운영할 데이터베이스가 더 많다는 점에서 본질적으로는 동일합니다!
소위 원자성이란 전체 트랜잭션의 모든 작업이 완료되거나 전혀 수행되지 않으며 중간 상태가 없음을 의미합니다. 트랜잭션 실행 중에 오류가 발생하면 모든 작업이 롤백되고 전체 트랜잭션은 한 번도 실행되지 않은 것처럼 됩니다.
거래 실행은 시스템의 일관성을 보장해야 합니다. 예를 들어 A가 B에게 50위안을 성공적으로 이체한 경우. transaction, 동시성이 아무리 많아도 무슨 일이 일어나더라도 거래가 성공적으로 실행된다면 최종 계좌 A는 450위안, 계좌 B는 350위안이 되어야 합니다.
소위 격리란 트랜잭션이 서로 영향을 미치지 않으며 한 트랜잭션의 중간 상태가 다른 트랜잭션에서 인식되지 않음을 의미합니다.
지속성이란 단일 트랜잭션이 완료된 후 정전이 발생하거나 정전이 발생하더라도 트랜잭션으로 인해 변경된 데이터가 데이터베이스에 완전히 저장되는 것을 의미합니다. 이런 식으로 시스템이 다운되었습니다.
결제는 구매자의 계좌에서 돈을 차감하는 동시에 판매자의 계좌에 돈을 추가하는 것입니다. 트랜잭션에서 실행되면 모두 성공하거나 모두 실패합니다. 구매자 센터에 속하는 구매자 계정은 구매자 데이터베이스에 해당하고, 판매자 계정은 판매자 데이터베이스에 해당하는 판매자 센터에 속합니다. 서로 다른 데이터베이스에 대한 작업은 분산 트랜잭션을 도입해야 합니다.
구매자가 전자상거래 플랫폼에서 주문할 때 일반적으로 두 가지 작업이 필요합니다. 하나는 재고를 공제하는 것이고, 두 번째는 일반적으로 주문 상태를 업데이트하는 것입니다. 데이터 일관성을 보장하려면 분산 트랜잭션을 사용해야 합니다.
XA는 Tuxedo에서 제안하는 분산 트랜잭션 프로토콜입니다. XA는 크게 트랜잭션 관리자와 로컬 리소스 관리자의 두 부분으로 나뉩니다. 로컬 리소스 관리자는 종종 데이터베이스에 의해 구현되며 Oracle 및 DB2와 같은 상용 데이터베이스는 모두 XA 인터페이스를 구현하며 트랜잭션 관리자는 전역 스케줄러 역할을 하며 각 로컬 리소스의 제출 및 롤백을 담당합니다. XA가 분산 트랜잭션을 구현하는 원리는 다음과 같습니다.
일반적으로 XA 프로토콜은 비교적 간단하며, 상용 데이터베이스가 XA 프로토콜을 구현하면 분산 트랜잭션을 사용하는 비용도 상대적으로 저렴합니다. 그러나 XA에는 치명적인 단점도 있습니다. 즉, 성능이 이상적이지 않으며, 특히 동시성이 높은 트랜잭션 주문 링크에서 XA는 높은 동시성 시나리오를 충족할 수 없습니다. XA는 현재 상용 데이터베이스에서 이상적으로 지원되지만 mysql 데이터베이스에서는 이상적으로 지원되지 않습니다. MySQL의 XA 구현은 준비 단계 로그를 기록하지 않으며 기본 데이터베이스와 보조 데이터베이스 간에 다시 전환하면 기본 데이터베이스와 보조 데이터베이스 간의 데이터 불일치가 발생합니다. . 또한 많은 nosql은 XA를 지원하지 않으므로 XA의 애플리케이션 시나리오가 매우 좁아집니다.
소위 메시지 트랜잭션은 메시지 미들웨어를 기반으로 하는 2단계 제출입니다. 이는 본질적으로 로컬 트랜잭션과 메시지 전송을 분산화합니다. 트랜잭션이 완료되면 로컬 작업이 성공하고 외부 메시지가 성공하거나 둘 다 실패한다는 것이 보장됩니다. 오픈 소스 RocketMQ는 이 기능을 지원합니다. 구체적인 원칙은 다음과 같습니다.
1, 시스템 A 보내기 message to the message middleware
2. 메시지 미들웨어는 예비 메시지를 저장하고 성공을 반환합니다
3. A는 로컬 트랜잭션을 실행합니다
4. A는 메시지 미들웨어에 커밋 메시지를 보냅니다
위의 4단계를 통해 메시지를 완료합니다. 사무. 위의 4단계에서 각 단계마다 오류가 발생할 수 있습니다. 하나씩 분석해 보겠습니다.
1단계에서 오류가 발생하면 전체 트랜잭션이 실패하고 A의 로컬 작업이 실행되지 않습니다
2단계 오류가 발생하면 전체 트랜잭션이 실패하고 A의 로컬 작업이 실행되지 않습니다.
이 때 3단계에서 오류가 발생하므로 준비 메시지를 롤백해야 합니다. .롤백하는 방법은 무엇입니까? 그 대답은 시스템 A가 메시지 미들웨어를 위한 콜백 인터페이스를 구현한다는 것입니다. 메시지 미들웨어는 트랜잭션 A가 성공적으로 실행되었는지 확인하기 위해 콜백 인터페이스를 지속적으로 실행합니다. 실패하면 준비된 메시지가 롤백됩니다.
4단계에서 오류가 발생했습니다. 이때 A의 로컬 트랜잭션이 성공했습니다. 메시지 미들웨어가 A를 롤백해야 합니까? 대답은 '아니오'입니다. 실제로 메시지 미들웨어는 콜백 인터페이스를 통해 A가 성공적으로 실행되었는지 확인할 수 있습니다. 이때 A는 실제로 메시지를 제출할 필요가 없습니다. , 이로써 전체 메시지 트랜잭션이 완료됩니다
메시지 미들웨어 기반의 2단계 커밋은 분산 트랜잭션을 메시지 트랜잭션(시스템 A의 로컬 작업 + 메시지 전송) + 로컬 작업으로 분할하기 위해 높은 동시성 시나리오에서 자주 사용됩니다. 시스템 B의 작업은 메시지 트랜잭션에 의해 구동되며, A 작업은 성공해야 하며 이때 B는 메시지를 수신하여 수행해야 합니다. 로컬 작업이 실패하면 B 작업이 성공할 때까지 메시지가 다시 전달됩니다. 이러한 방식으로 A와 B 간의 분산 트랜잭션이 구현됩니다. 원칙은 다음과 같습니다.
위의 솔루션은 A와 B의 작업을 완료할 수 있지만 A와 B는 엄격하게 일관성이 없지만 궁극적으로 성능 향상을 위해 일관성을 희생합니다. 물론 이런 종류의 게임 플레이도 위험합니다. B가 계속해서 실행에 실패하면 게임의 일관성이 파괴됩니다.
소위 TCC 프로그래밍 모드도 2단계 제출의 변형입니다. TCC는 전체 비즈니스 로직을 시도, 확인, 취소 작업의 세 부분으로 나누는 프로그래밍 프레임워크를 제공합니다. 온라인 주문을 예로 들면 Try 단계에서는 재고가 차감되고, 확인 단계에서는 주문 상태가 업데이트됩니다. 주문 업데이트에 실패하면 취소 단계로 진입하여 재고가 복원됩니다. 즉, TCC는 코드를 통해 2단계 제출을 인위적으로 구현합니다. 서로 다른 비즈니스 시나리오에서 작성된 코드가 다르며 복잡성도 다릅니다. 따라서 이 모델은 잘 재사용될 수 없습니다.
분산 트랜잭션은 본질적으로 여러 데이터베이스의 트랜잭션을 통합적으로 제어하며 제어 강도에 따라 비통제, 부분 제어 및 완전 제어로 나눌 수 있습니다. 제어 없음은 분산 트랜잭션을 도입하지 않음을 의미하며, 부분 제어는 메시지 트랜잭션 + 최종 일관성을 포함한 다양한 변형의 2단계 커밋을 의미하며, 전체 제어는 위에서 언급한 2단계 커밋을 완전히 구현하는 것을 의미합니다. 부분 제어의 장점은 동시성과 성능이 매우 좋다는 것입니다. 단점은 데이터 일관성이 약해진다는 것입니다. 전체 제어는 성능을 희생하고 일관성을 보장합니다. 어떤 방법을 사용할지는 비즈니스 시나리오에 따라 다릅니다. 기술자로서 기술이 비즈니스에 도움이 된다는 사실을 잊어서는 안됩니다. 기술을 위해 기술을 사용하지 마십시오. 다양한 비즈니스에 대한 기술 선택도 매우 중요한 능력입니다!
위 내용은 JAVA 분산 트랜잭션에 대한 심층적인 이해의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
