분산 트랜잭션에 대한 자세한 그래픽 설명

이 글의 내용은 사진과 텍스트로 자세한 설명을 담고 있으니 도움이 필요한 친구들이 참고하시면 좋겠습니다.

이번에는 분산 트랜잭션 프레임워크를 사용하는 과정에서 분산 트랜잭션 지식을 배웠으므로 이번 글에서는 분산 트랜잭션에 대해 이야기해보겠습니다. 먼저 거래가 무엇인지 살펴보겠습니다.

사건

거래란 무엇인가요? 이것은 백엔드 개발입니다. 일상적인 개발에서 데이터베이스와 상호 작용하는 한 트랜잭션은 반드시 사용됩니다. 이제 트랜잭션이 무엇인지 설명하기 위해 Wiki에서 설명을 발췌합니다.

은 데이터베이스 관리 시스템의 실행 과정에서 논리적 단위로, 제한된 데이터베이스 작업 순서로 구성됩니다.

데이터베이스 시스템은 데이터베이스 시스템과 다른 트랜잭션 특성을 가지고 있습니다. 파일 시스템 중요한 기능. 기존 파일 시스템에서는 파일을 작성하는 중에 운영 체제가 갑자기 충돌하면 파일이 손상될 수 있습니다. 데이터베이스 시스템은 데이터베이스가 한 상태에서 다른 상태로 변경되도록 하는 트랜잭션 기능을 도입합니다. 작업을 제출할 때 모든 변경 사항이 저장되거나 아무것도 저장되지 않는지 확인할 수 있습니다.

일반적으로 트랜잭션은 여러 개의 읽기 및 쓰기 작업으로 구성됩니다.

거래에는 일반적으로 ACID라고 알려진 네 가지 기본 특성이 있습니다.

A(원자성): 원자성. 트랜잭션은 전체적으로 처리됩니다. 모든 문이 성공하거나 모두 실패합니다. 일부 문은 성공하고 일부 문은 실패할 수 없습니다.

C(일관성): 일관성. 데이터베이스 상태가 한 상태에서 다른 상태로 변경되면 트랜잭션이 시작되기 전과 트랜잭션이 끝난 후에도 데이터베이스 무결성 제약 조건은 변경되지 않은 상태로 유지됩니다. 데이터베이스 무결성 제약조건은 무엇을 의미합니까? 예를 들어, 테이블의 이름 필드가 고유 제약 조건인 경우 트랜잭션이 커밋되거나 롤백된 후 이름 필드가 고유하지 않게 되면 데이터베이스의 무결성 제약 조건이 파괴됩니다.

나(격리) : 격리. 여러 동시 트랜잭션이 서로 영향을 주지 않고 실행됩니다.

D(내구성): 내구성. 트랜잭션이 커밋된 후 데이터베이스에 대한 수정 사항이 데이터베이스에 영구적으로 저장될 수 있습니다. 따라서 이 기능을 사용하려면 데이터베이스 시스템이 충돌 시 복원해야 할 때 데이터 손실 없이 데이터를 제출할 수 있어야 합니다.

따라서 초기에는 우리 시스템에 데이터 소스가 하나뿐이었습니다. 현재로서는 비즈니스의 정확성을 보장하기 위해 데이터베이스 시스템 트랜잭션에 의존할 수 있었습니다.

그러나 비즈니스가 계속 확장됨에 따라 비즈니스의 단일 테이블에 수천만 개의 데이터가 포함될 수 있으며, 다른 데이터베이스 인스턴스를 사용할 경우 성능 문제가 발생할 수 있습니다. 이번에는 하위 데이터베이스와 테이블을 고려하겠습니다. 그러나 이로 인해 단일 애플리케이션이 여러 데이터 소스에 연결될 수 있습니다. 아래 예를 참조하세요.

위 구매 프로세스 사진에서 판매자 잔액 테이블과 사용자 잔액 테이블이 두 개로 분리되어 있습니다. 데이터베이스 인스턴스 이러한 별도의 거래는 판매자 잔액 또는 사용자 잔액 공제의 성공 여부를 보장할 수 있습니다. 그러나 두 거래가 동시에 성공하거나 실패할 것이라고 보장할 수는 없습니다.

또 다른 상황에서는 시스템이 점점 더 커지면서 시스템 애플리케이션을 여러 마이크로서비스로 분할하여 단일 애플리케이션이 하나의 데이터 소스만 운영할 수 있도록 할 것입니다. 이때 아래와 같이 하나의 비즈니스 호출이 여러 애플리케이션을 호출하고 각 애플리케이션이 독립적으로 데이터 소스를 운영하는 상황에 직면하게 됩니다.

이 경우 모든 통화가 성공할 것이라고 보장할 수 없습니다.

위의 예에서 비즈니스가 발전함에 따라 기존의 독립형 트랜잭션은 더 이상 비즈니스 요구 사항을 충족할 수 없음을 알 수 있습니다. 이때 이를 보장하려면 분산 트랜잭션이 필요합니다.

분산거래

위키 설명에서 발췌.

분산 트랜잭션은 둘 이상의 네트워크 호스트가 관련된 데이터베이스 트랜잭션입니다.

먼저 분산 트랜잭션을 구현하기 위한 몇 가지 이론적 근거에 대해 이야기해 보겠습니다.

분산거래기술이론

CAP정리. 분산 시스템(서로 연결되어 데이터를 공유하는 노드의 집합)에서는 읽기 및 쓰기 작업에 있어 일관성, 가용성 및 파티션 허용성 중 하나만 보장할 수 있습니다. .

0의 Geek Time Learning Architecture 22장에서 발췌 설명

CAP의 이론적 정의는 세 가지 요소 중 두 가지만 취할 수 있다는 것이지만, 분산 환경에서 생각해보면 네트워크가 복잡하기 때문에 P(파티션 허용 오차) 요소를 선택해야 한다는 것을 알 수 있습니다. 그 자체로는 100%를 달성할 수 없다. 신뢰성이 높고 실패할 수도 있으므로 파티셔닝은 불가피한 현상입니다. CA를 선택하고 P를 포기하면 파티셔닝이 발생할 때 보장하기 위해 C, 시스템은 쓰기를 금지해야 합니다. 쓰기 요청이 있는 경우 시스템은 오류를 반환합니다(예: 현재 시스템에서는 쓰기를 허용하지 않습니다). 이는 A가 오류 반환을 요구하지 않기 때문에 A와 충돌합니다. 시간 초과가 없습니다. 따라서 분산 시스템에서는 CA 아키텍처를 선택하는 것이 이론적으로 불가능하며 CP 또는 AP 아키텍처만 선택할 수 있습니다.

BASE 이론은 다음 세 단어의 약어입니다.

기본적으로 사용 가능: 분산 시스템에 오류가 발생하면 핵심 기능을 사용할 수 있도록 일부 사용 가능한 기능의 손실을 허용합니다.

소프트 상태(소프트 상태): 시스템에 중간 상태가 존재하도록 허용합니다. 이 상태는 시스템 가용성에 영향을 주지 않습니다. 이는 CAP의 불일치를 나타냅니다.

최종 일관성: 최종 일관성은 일정 기간이 지난 후에도 모든 노드 데이터가 일관성을 유지한다는 의미입니다.

BASE는 CAP의 AP 솔루션을 보완한 것입니다. 지연된 일관성을 보장하려면 BASE의 소프트 상태와 최종 일관성을 사용하세요. BASE와 ACID는 반대입니다. ACID는 강력한 일관성 모델이지만 BASE는 이러한 강력한 일관성을 희생하여 짧은 시간 내에 데이터가 일관성을 잃게 됩니다.

다음으로 분산 트랜잭션 구현 옵션을 살펴보겠습니다.

분산 트랜잭션 구현 계획

1. 데이터베이스 리소스 수준 기준

• # 🎜🎜#2PC 2단계 제출 프로토콜

• 3PC 3단계 제출 프로토콜

#🎜 🎜#비즈니스 수준 기준

TCC

기준 데이터베이스 자원 수준 구현 계획은 여러 개의 트랜잭션이 있으므로 각 트랜잭션의 상태를 관리하는 역할이 필요합니다. 우리는 이 역할을 코디네이터라고 부르며, 거래 참여자를 참가자라고 부릅니다. 참가자와 코디네이터는 일반적으로 특정 프로토콜을 기반으로 하며 현재 가장 유명한 프로토콜은 XA 인터페이스 프로토콜입니다. 코디네이터와 참가자의 이념적 설정을 바탕으로 XA 분산 트랜잭션을 구현하기 위해 2PC와 3PC가 제안되었습니다.

2PC 2단계 제출 프로토콜

이름에서 알 수 있듯이 이 프로세스는 주로 두 단계로 나뉩니다.

첫 번째 단계에서는 코디네이터(거래 관리자)가 관련 거래를 미리 제출합니다. 이때 데이터베이스 리소스는

잠기기

시작됩니다. 참가자는 트랜잭션 로그에 실행 취소 및 다시 실행을 기록합니다. 두 번째 단계에서는 참여자(리소스 관리자)가 트랜잭션을 커밋하거나 실행 취소 로그를 사용하여 트랜잭션을 롤백하고 리소스를 해제합니다.
전체 과정은 아래와 같습니다.

분산 트랜잭션 제출 성공 시나리오:

분산 트랜잭션 롤백 시나리오: #🎜🎜 #

이 솔루션의 장점은 구현이 상대적으로 간단하고 모든 주류 데이터베이스에서 지원되며 강력한 일관성을 갖는다는 것입니다. MySQL 5.5 이상은 XA 프로토콜을 기반으로 구현됩니다.

해당 솔루션에도 단점이 있습니다:

코디네이터의 단일 지점 문제. 제출 단계에서 코디네이터가 다운되고 참가자가 기다리고 있는 경우 리소스가 잠기고 차단됩니다. 코디네이터를 재선하는 것은 가능하지만, 이것만으로는 문제가 해결되지 않습니다.

1. 동기화 차단 시간이 너무 깁니다. 제출이 완료되고 리소스가 해제되는 경우 전체 실행 프로세스 트랜잭션이 차단됩니다. 프로세스가 진행되는 동안 네트워크 지연으로 인해 참가자가 지시를 받지 못하여 참가자가 차단되었습니다.

2. 데이터가 일치하지 않습니다. 두 번째 단계에서는 코디네이터가 첫 번째 커밋 신호를 보낸 후 충돌이 발생합니다. 첫 번째 참가자는 트랜잭션을 커밋하고 두 번째 참가자는 코디네이터 신호를 받지 못해 트랜잭션을 커밋할 수 없습니다.

3. 그래서 2PC의 단점을 바탕으로 개선 방안을 제안한 것이 바로 3PC입니다.

3PC 3단계 제출 프로토콜

3단계 제출은 2단계 제출을 기반으로 2단계를 개선합니다. 3단계 단계는 다음과 같습니다.

CanCommit, 코디네이터는 참가자에게 트랜잭션을 커밋할 수 있는지 묻습니다.

1. PreCommit, 모든 참가자가 트랜잭션을 커밋할 수 있으면 코디네이터는 PreCommit 명령을 실행하고 참가자는 리소스를 잠그고 최종 명령을 기다립니다.
모든 참가자는 확인 정보를 반환하고 코디네이터는 각 트랜잭션에 대해 트랜잭션 실행 알림을 발행하고 리소스를 잠근 후 실행 상태를 반환합니다.

• 일부 참가자가 거부 정보를 반환했거나 코디네이터가 시간 초과되었습니다. 이 경우 코디네이터는 트랜잭션이 정상적으로 실행될 수 없다고 판단하여 인터럽트 명령을 내리고 각 참가자는 준비 상태를 종료합니다

Do Commit, 두 번째 단계에서 ack에 대한 모든 응답이 발행되면 트랜잭션의 최종 제출을 위해 Do Commit이 발행되고, 그렇지 않으면 인터럽트 트랜잭션 명령이 발행되고 모든 참가자는 트랜잭션을 롤백합니다.

• 모든 참가자는 정상적으로 트랜잭션을 실행하고 코디네이터는 최종 커밋 명령을 내려 잠긴 리소스를 해제합니다.

• 일부 참가자가 트랜잭션을 실행하지 못했고 코디네이터가 시간 초과되어 잠긴 리소스를 해제하기 위해 롤백 명령을 실행했습니다.

자세한 내용은 아래 사진을 참고해주세요.

2단계 제출에 비해 3단계 제출은 시간 제한 메커니즘을 도입하여 트랜잭션 차단을 줄이고 단일 실패 지점을 해결합니다. 세 번째 단계에서는 참가자가 코디네이터 신호 수신에 실패하면 시간 초과를 기다린 후 참가자는 기본적으로 커밋을 실행하고 리소스를 해제합니다.

세 단계로는 여전히 데이터 일관성 문제를 해결할 수 없습니다. 코디네이터가 롤백 명령을 내렸으나 네트워크 문제로 인해 참여자들이 대기 시간 내에 이를 수신하지 못하는 경우, 이때 참여자들은 기본적으로 트랜잭션을 커밋하고 다른 트랜잭션들은 롤백되어 트랜잭션 불일치가 발생하게 된다.

TCC

TCC Transaction

트랜잭션 실행 중 대규모 리소스 잠금 문제를 해결하기 위해 업계에서는 비즈니스 수준 트랜잭션 정의를 기반으로 하는 새로운 트랜잭션 모델을 제안합니다. 잠금 세분성은 비즈니스 자체에서 완전히 제어됩니다. 본질적으로 보상 아이디어입니다. 트랜잭션 실행 프로세스를 Try 및 확인/취소의 두 단계로 나눕니다. 각 단계의 논리는 비즈니스 코드에 의해 제어됩니다. 이러한 방식으로 트랜잭션의 잠금 단위를 완전히 자유롭게 제어할 수 있습니다. 기업은 격리를 희생하여 더 높은 성능을 달성할 수 있습니다.

TCC는 각각 시도(Trying), 확인(Confirm), 취소(Cancel)의 약어입니다. 데이터베이스 수준을 기반으로 하는 2PC, 3PC와 달리 TCC는 애플리케이션 수준을 기반으로 합니다.
TCC의 세 가지 조치는 다음과 같습니다.

노력:

• 모든 비즈니스 점검 완료(일관성)

• 필요한 비즈니스 자원 확보(준격리)

확인:

• 실제 실행 비즈니스

• 확인 작업은 멱등성을 충족해야 합니다.

취소:

• Try 단계에서 예약된 비즈니스 리소스를 해제합니다.

• 취소 작업은 멱등성을 충족해야 합니다.

위의 설명을 들어보세요. 다소 어색하게 들릴 수 있습니다. 이해하기 어렵지만 실제 사례를 사용하여 설명하겠습니다.

아래에서는 쇼핑몰의 일회성 결제 프로세스를 시뮬레이션합니다. 사용자는 주문 시 결합 결제, 즉 잔액과 빨간 봉투 결제를 사용합니다. 일반적인 프로세스는 다음과 같습니다.

1. 주문 생성

2. 주문하기

• 잔액 시스템을 호출하여 잔액 공제

• 빨간 봉투 시스템을 호출하여 빨간 봉투 잔액 공제

• 결제 후 주문 상태를 결제 완료

• 로 수정하세요.

실제 과정은 아래와 같습니다.

그러나 이러한 결제 프로세스는 여러 하위 서비스를 호출하므로 모든 서비스가 성공할 수 있다고 보장할 수 없습니다. 예를 들어 빨간 봉투 시스템을 호출하여 빨간 봉투 시스템을 공제하면 실패합니다. 이때 빨간봉투 서비스 장애로 인해 메소드가 비정상적으로 종료되는 황당한 상황이 발생하였습니다. 이때 주문상태는 초기상태인데 사용자 잔액이 차감된 상태였습니다. 이는 사용자 경험에 매우 비우호적입니다. 따라서 이 결제 프로세스 중에 우리는 이 프로세스를 전체 동작으로 처리하는 메커니즘을 가져야 하며 이 프로세스의 모든 서비스 호출이 성공하거나 실패하고 전체 거래가 되도록 보장해야 합니다.

이제 전체 주문 프로세스를 전체적으로 처리하기 위해 TCC 트랜잭션을 도입할 수 있습니다. 도입 이후 잔액제 차감 실패로 인해 주문제와 레드엔벨로프 시스템을 이번에 롤백하였습니다. 전체 과정은 아래와 같습니다.

밸런스 시스템 장애로 인해 이 과정에서 모든 변경 사항을 취소해야 하므로 주문 시스템에는 취소 공지를, 레드엔벨로프 시스템에는 취소 공지를 보냅니다.

따라서 시스템에 TCC 거래가 도입된 후에는 통화 프로세스를 혁신해야 합니다.

TCC 거래를 시스템에 도입하는 방법

TCC 거래의 3단계에 따르면, 이때 각 서비스는 TryConfirm Cancle,

TCC TRY:

의 3단계로 변환되어야 합니다.

위 비즈니스를 기반으로 주문 시스템에 주문 상태를 PAYING으로 수정하는 try 메소드가 추가되었습니다. 잔액 시스템은 잔액이 충분한지 먼저 확인한 후 잔액을 차감한 다음 차감된 잔액을 동결 금액에 추가하는 try 메소드를 추가합니다. 빨간 봉투 시스템은 균형 시스템과 동일합니다. TCC try 메서드는 각 비즈니스 리소스를 확인해야 하며 이 프로세스에서는 중간 상태를 도입해야 한다는 변환 프로세스를 보면 알 수 있습니다. 아래 그림을 바탕으로 전체 과정을 살펴보겠습니다.

TCC 확인:

TCC Step 1 TRY 모든 하위 서비스 호출이 성공했다면 이때 각 서비스를 확인해야 합니다. 각 서비스에 확인 방법을 추가합니다. 예를 들어 잔액 시스템의 확인 방법을 사용하여 동결 금액을 0으로 설정하고 빨간색 봉투 시스템은 위와 같습니다. 주문 시스템에서 주문 상태가 SUCCESS로 변경됩니다. 확인 메서드는 멱등성을 달성하는 데 주의를 기울여야 합니다. 예를 들어 주문 시스템을 업데이트하기 전에 먼저 주문 상태가 PAYING인지 확인해야 주문을 업데이트할 수 있습니다. 전체 과정은 아래와 같습니다.

이 시점에서 각 서비스를 홍보하려면 TCC 트랜잭션 프레임워크를 사용해야 합니다. TCC 트랜잭션 관리자는 TRY 메소드의 종료를 감지한 후 각 서비스에서 제공하는 확인 메소드를 자동으로 호출하여 각 서비스의 상태를 최종 상태로 수정합니다.

TCC 취소:

TCC Try 프로세스 중에 고정 빨간색 봉투 방법이 실패하면 이전 수정 사항을 모두 취소하고 초기 상태로 수정해야 합니다. cancle 메소드는 아래와 같이 확인 메소드와 같은 멱등성을 구현해야 합니다.

이를 보면 TCC Try가 성공하면 확인이 성공하고, 시도가 실패하면 취소가 성공해야 함을 알 수 있습니다. 시스템을 최종 상태로 업데이트하는 데는 확인이 핵심이기 때문입니다. 하지만 현실은 너무나 냉혹해서 프로덕션 시스템에서 확인이나 취소가 실패할 가능성이 분명히 있습니다. 이 경우 TCC 프레임워크는 확인 호출 결과를 기록해야 합니다. 확인 호출이 실패하면 TCC 프레임워크는 이를 기록한 다음 특정 간격으로 다시 호출해야 합니다.

요약 및 반성

원문을 읽은 후에는 기본적으로 분산 트랜잭션을 이해해야 합니다.

이를 바탕으로 정리합니다. 분산 트랜잭션을 사용하려면 실제 시나리오와 연계하여 적용해야 합니다.

비즈니스가 아직 초기 단계인 경우 실제로 빠른 온라인 반복을 보장하기 위해 데이터베이스 트랜잭션을 선택할 수 있습니다.

비즈니스가 특정 단계에 도달하면 시스템이 분할되기 시작하고, 데이터베이스도 분할됩니다. 이때 비즈니스의 일관성을 보장해야 한다면 분산 트랜잭션을 사용해야 합니다. 이때 분산 트랜잭션을 사용할 때 비즈니스에 따라 어떤 것을 사용할지 고려해야 합니다.

2PC 또는 3PC로 구현된 분산 프레임워크를 사용하면 비즈니스 애플리케이션 계층을 수정할 필요가 없으며 액세스가 비교적 간단합니다. 그러나 해당 성능이 낮고 데이터 리소스가 오랫동안 잠겨 있습니다. 인터넷과 같은 동시성이 높은 비즈니스 시나리오에는 적합하지 않습니다.

TCC 기반의 분산 프레임워크를 사용하면 2PC보다 성능이 뛰어나며 데이터의 최종 일관성을 보장할 수 있습니다. 그러나 애플리케이션 계층의 경우 한 가지 방법을 세 가지 방법으로 변환해야 하며 일부 중간 상태를 비즈니스에 도입해야 합니다. 상대적으로 말하면 애플리케이션 변환 정도가 상대적으로 큽니다.

위 내용은 분산 트랜잭션에 대한 자세한 그래픽 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!