XA 사양
XA는 트랜잭션 미들웨어와 X/Open DTP가 정의한 데이터베이스 간의 인터페이스 명세(즉, 인터페이스 기능)로, 트랜잭션 미들웨어가 트랜잭션의 시작, 종료, 커밋, 롤백 등을 데이터베이스에 알리는 데 사용됩니다. XA 인터페이스 기능은 데이터베이스 벤더에서 제공합니다.
2차 제출 계약서와 3차 제출 계약서는 이 아이디어에서 파생되었습니다. 2단계 커밋이 XA 분산 트랜잭션을 구현하는 핵심이라고 할 수 있습니다(정확히 말하면, 2단계 커밋은 주로 분산 트랜잭션의 원자성을 보장합니다: 즉, 모든 노드가 전부 또는 아무것도 하지 않거나 하는 방식입니다)
2PC
2단계 커밋은 컴퓨터 네트워크와 데이터베이스 분야에서 분산 시스템 아키텍처를 기반으로 한 모든 노드의 트랜잭션 커밋의 일관성을 유지하기 위해 설계된 알고리즘을 의미합니다. 종종 2단계 커밋은 프로토콜이라고도 불립니다. 분산 시스템에서 각 노드는 자신의 작업의 성공 여부는 알 수 있지만, 다른 노드의 작업의 성공 여부는 알 수 없습니다. 트랜잭션이 여러 노드를 가로질러질 때, 트랜잭션의 ACID 특성을 유지하기 위해 조정자 역할을 하는 컴포넌트가 도입되어 모든 노드(참여자라 불림)의 결과를 제어하고 궁극적으로 이 노드들이 실제로 결과를 제출하도록 지시해야 합니다(예: 업데이트된 데이터를 디스크에 쓰는 것 등). 따라서 2단계 제출의 알고리즘 아이디어는 다음과 같이 요약할 수 있습니다: 참가자들은 조작의 성공 여부를 조정자에게 알리고, 조정자는 모든 참가자의 피드백 정보를 바탕으로 조작을 제출할지 중단할지 결정합니다.
이른바 두 단계는 1단계인 준비 단계(투표 단계)와 2단계인 제출 단계(실행 단계)입니다.
준비 단계
트랜잭션 코디네이터(트랜잭션 매니저)는 각 참가자(리소스 매니저)에게 준비 메시지를 보내고, 각 참가자는 실패(예: 실패한 권한 검증)를 직접 반환하거나, 로컬에서 트랜잭션을 실행하여 로컬 리do 및 실행 취소 로그를 작성하지만 커밋하지 않고, "모든 준비가 완료되었으며 동풍만 남아 있다"는 상태에 도달합니다.
준비 단계는 다음 세 단계로 더 나눌 수 있습니다:
1) 조정자 노드는 모든 참여 노드에게 투표를 할 수 있는지 묻고 각 참가자 노드의 응답을 기다리기 시작합니다.
2) 참여 노드는 쿼리가 시작될 때까지 모든 트랜잭션 작업을 수행하고, 실행 취소 정보와 재실행 정보를 로그에 기록합니다. (참고: 성공하면 각 참가자가 이미 트랜잭션 연산을 수행한 상태임)
3) 각 참여 노드는 조정자 노드가 시작한 문의에 응답한다. 참여 노드의 트랜잭션 연산이 실제로 성공적으로 실행되면 "동의" 메시지를 반환합니다; 참여 노드의 트랜잭션 연산이 실제로 실패하면, "중단됨" 메시지를 반환합니다.
서브미션 단계
코디네이터가 참가자로부터 실패 메시지나 타임아웃을 받으면, 각 참가자에게 직접 롤백 메시지를 보냅니다. 그렇지 않으면 커밋 메시지를 보내고; 참가자들은 코디네이터의 지시에 따라 커밋 또는 롤백 작업을 수행하여 트랜잭션 과정에서 사용되는 모든 잠금 자원을 해제합니다. (참고: 잠금 자원은 최종 단계에서 해제되어야 합니다)
다음으로, 제출 단계의 과정을 두 가지 경우에 걸쳐 별도로 논의합니다.
모든 참여 노드로부터 조정자 노드가 수신하는 대응하는 메시지가 Agree일 때:
서브미션 단계
코디네이터가 참가자로부터 실패 메시지나 타임아웃을 받으면, 각 참가자에게 직접 롤백 메시지를 보냅니다. 그렇지 않으면 커밋 메시지를 보내고; 참가자들은 코디네이터의 지시에 따라 커밋 또는 롤백 작업을 수행하여 트랜잭션 과정에서 사용되는 모든 잠금 자원을 해제합니다. (참고: 잠금 자원은 최종 단계에서 해제되어야 합니다)
다음으로, 제출 단계의 과정을 두 가지 경우에 걸쳐 별도로 논의합니다.
모든 참여 노드로부터 조정자 노드가 수신하는 대응하는 메시지가 Agree일 때:
1) 조정자 노드가 모든 참여 노드에 "커밋" 요청을 발송합니다.
2) 참여 노드가 공식적으로 작업을 완료하고 거래 기간 동안 점유된 자원을 해제합니다.
3) 참여 노드가 코디네이터 노드에게 "완료" 메시지를 보냅니다.
4) 조정자 노드는 모든 참여 노드로부터 "완료" 메시지 피드백을 받은 후 트랜잭션을 완료합니다.
1) 조정자 노드가 모든 참여 노드에 "롤백" 요청을 보냅니다.
2) 참여 노드는 이전에 작성된 실행 취소 정보를 사용하여 거래 기간 동안 점유된 자원을 롤백하고 해제합니다.
3) 참여 노드가 코디네이터 노드에 "롤백 완료" 메시지를 보냅니다.
4) 조정자 노드는 모든 참여 노드로부터 "롤백 완료" 메시지 피드백을 받은 후 트랜잭션을 취소합니다.
2단계 커밋은 원자 연산을 제공하는 것으로 보이지만, 안타깝게도 2단계 커밋에는 몇 가지 단점이 있습니다:
1. 동기 차단 문제. 실행 중에는 모든 참여 노드가 트랜잭션 블로킹을 합니다. 참여자가 공공 자원을 점유할 때, 다른 제3자 노드가 공공 자원에 접근하는 것을 차단해야 합니다.
2. 단일 고장 지점. 코디네이터의 중요성 때문에, 코디네이터가 실패하면 참가자들은 계속해서 막힘 차단을 계속할 것입니다. 특히 두 번째 단계에서는 코디네이터가 실패하면 모든 참가자가 여전히 거래 자원을 잠금한 상태에 있어 거래를 계속 수행할 수 없습니다. (코디네이터가 전화를 끊으면 코디네이터를 재선출할 수 있지만, 코디네이터가 다운되어 참가자가 차단되는 문제는 해결되지 않습니다)
3. 데이터 불일치. 커밋 2단계의 두 번째 단계에서, 코디네이터가 참가자에게 커밋 요청을 보낼 때 로컬 네트워크 예외가 발생하거나 커밋 요청 과정에서 코디네이터가 실패하여 일부 참가자만 커밋 요청을 수락하게 됩니다. 커밋 요청을 받은 후, 이 참가자들은 커밋 작업을 수행합니다. 하지만 커밋 요청을 받지 못하는 다른 기기들은 트랜잭션 커밋을 실행할 수 없습니다. 그 결과, 데이터 부서의 일관성은 전체 분산 시스템에서 발생합니다.
4. 두 번째 단계에서 해결할 수 없는 문제: 커밋 메시지를 보낸 후 코디네이터가 다운되고, 이 메시지를 받은 유일한 참가자도 다운됩니다. 따라서 조정자가 선거 계약을 통해 새로운 조정자를 선출하더라도, 거래의 상태는 불확실하며, 거래가 제출되었는지 아무도 알 수 없습니다.
3PC
3단계 커밋은 3단계 커밋 프로토콜이라고도 하며, 2단계 커밋(2PC)의 개선된 버전입니다.
2단계 커밋과 달리, 3단계 커밋에는 두 가지 변경사항이 있습니다.
1. 타임아웃 메커니즘 도입. 동시에 진행자와 참가자 모두에게 타임아웃 메커니즘이 도입됩니다.
2. 1단계와 2단계에 준비 단계를 삽입한다. 이로 인해 모든 참여 노드의 상태가 최종 커밋 단계까지 일관성을 유지할 수 있습니다.
즉, 타임아웃 메커니즘을 도입하는 것 외에도, 3PC는 2PC의 준비 단계를 다시 두 단계로 나누어 커밋의 세 단계에 CanCommit, PreCommit, DoCommit의 세 단계로 나누어 사용합니다.
CanCommit 단계
3PC의 CanCommit 단계는 사실 2PC의 준비 단계와 매우 유사합니다. 코디네이터는 참가자에게 커밋 요청을 보내고, 참가자는 커밋이 가능하면 예(Yes) 응답을, 아니면 노(No) 응답을 반환합니다.
1. 트랜잭션 조회 진행자가 참가자에게 CanCommit 요청을 보냅니다. 트랜잭션 커밋 작업을 수행할 수 있는지 물어보세요. 그 후 참가자들의 답변을 기다리기 시작하세요.
2. 응답 피드백 CanCommit 요청을 받은 후, 참여자는 예 응답을 반환하고 거래가 원활하게 실행될 수 있다고 판단되면 준비 상태에 들어갑니다. 그렇지 않으면 피드백은 아니오
프리커밋 단계
진행자는 참가자의 반응을 바탕으로 거래의 PreCommit 연산을 암기할지 여부를 결정합니다. 답변에 따라 두 가지 가능성이 있습니다.
진행자가 모든 참가자로부터 받은 피드백이 '예'라면, 거래의 사전 실행이 수행됩니다.
1. 사전 커밋 요청 전송 진행자가 참가자에게 프리커밋 요청을 보내고 준비 단계로 넘어갑니다.
2. 트랜잭션 프리커밋 참가자가 프리커밋 요청을 받은 후, 트랜잭션 작업을 수행하고 실행 취소 및 재실행 정보를 트랜잭션 로그에 기록합니다.
3. 응답 피드백 참여자가 트랜잭션 연산을 성공적으로 실행하면, 최종 명령어를 기다리기 시작하면서 ACK 응답이 반환됩니다.
1. 인터럽트 요청을 보내기 진행자가 모든 참가자에게 중단 요청을 보냅니다.
2. 트랜잭션 중단 참여자가 코디네이터로부터 ABORT 요청을 받은 후(또는 타임아웃 이후, 코디네이터의 요청이 수신되지 않은 상태) 트랜잭션 중단이 실행됩니다.
이 실제 트랜잭션 커밋 단계는 다음과 같은 두 가지 상황으로 나눌 수 있습니다.
커밋을 수행하세요
1. 커밋 요청을 보내기 Coordinate는 참가자가 보낸 ACK 응답을 받고, 그 후 프리커밋 상태에서 커밋 상태로 전환합니다. 그리고 모든 참가자에게 doCommit 요청을 보냅니다.
2. 트랜잭션 제출 doCommit 요청을 받은 후, 참여자는 공식적인 트랜잭션 커밋을 실행합니다. 트랜잭션 커밋을 완료한 후 모든 트랜잭션 자원을 해제합니다.
3. 피드백에 응답하기 트랜잭션이 제출된 후, 코디네이터에게 Ack 응답을 보냅니다.
4. 트랜잭션 완료 코디네이터가 모든 참가자로부터 ACK 응답을 받으면 트랜잭션이 완료됩니다.
코디네이터가 참여자로부터 ACK 응답을 받지 못하면(수신자의 ACK 응답이 아닐 수도 있고, 응답이 타임아웃되었을 수도 있음), 인터럽트 트랜잭션이 실행됩니다.
1. 인터럽트 요청을 보내기 진행자가 모든 참가자에게 중단 요청을 보냅니다
2. 트랜잭션 롤백 ABORT 요청을 받은 후, 참가자는 2단계에서 기록된 실행 취소 정보를 사용해 트랜잭션 롤백 작업을 수행하고, 롤백을 완료하면 모든 트랜잭션 자원을 해제합니다.
3. 피드백 결과 참여자가 트랜잭션 롤백을 완료한 후, 코디네이터에게 ACK 메시지를 전송하세요
4. 트랜잭션 중단 코디네이터가 참여자로부터 ACK 메시지를 받은 후 트랜잭션이 중단됩니다.
2PC와 3PC의 차이점
2PC에 비해 3PC는 주로 단일 지점 장애 문제를 해결하고 차단을 줄인다. 왜냐하면 참가자가 코디네이터로부터 메시지를 제때 받지 못하면 기본적으로 커밋을 실행하기 때문이다. 항상 거래 자원을 보유하고 차단 상태에 있는 대신, 하지만 이 메커니즘은 데이터 일관성 문제를 일으키기도 하는데, 네트워크 문제로 인해 코디네이터가 보낸 중단 응답이 참가자에게 제때 전달되지 않고, 참가자는 타임아웃을 기다린 후 커밋 작업을 실행하기 때문입니다. 이로 인해 중단 명령을 받고 롤백을 수행하는 다른 참가자들과 데이터 불일치가 발생합니다.
|
게시됨 2021. 3. 17. 오전 10:15:10
|
|
|
