저는 Azure Service Bus가 처음이므로 메시지 대기열을위한 트랜잭션 전략을 수립하려고합니다. SQL Azure는 MSDTC를 지원하지 않으므로 분산 된 TransactionScope를 사용하므로 사용할 수 없습니다. 따라서 데이터베이스 트랜잭션을 수동으로 처리 할 수있는 작업 단위 (Unit of Work)가 있습니다.Azure 서비스 버스 및 트랜잭션
문제는 TransactionScope를 사용하는 사람들 만 데이터베이스와 Azure Service Bus 작업을 처리 할 수 있다는 것입니다. TransactionScope를 사용하지 않고 서비스 버스에서 트랜잭션을 수행하는 다른 마술적인 방법이 있습니까?
감사합니다.
하늘색 서비스 버스와 같은 클라우드 호스팅 또는 서비스를 사용하려면 2 단계 커밋 (2PC) 또는 분산 트랜잭션 (DTC)을 포기할 것을 고려해야합니다.
대신 자원 별 트랜잭션 (즉, SQL 명령의 트랜잭션 또는 서비스 버스 작업의 트랜잭션)을 신중하게 사용하십시오. 그리고 그 자원 경계를 넘는 거래를 피하십시오.
그런 다음 워크 플로우 관리 및 오류 보상을 위해 신뢰할 수있는 메시징 및 sagas 등과 같은 패턴을 사용하여 이러한 자원/구성 요소 작업을 결합 할 수 있습니다. 그리고 거기에서 확장하십시오.
구름에서 2PC는 all sorts of reasons에 대해 어렵습니다 (불가능하지는 않지만 여전히 IaaS를 사용할 수 있음).
2PC는 DTC에 의해 구현되므로 코디네이터 및 로그 및 코디네이터와의 연결이 매우 유용하게 사용됩니다. 또한 모든 당사자가 긍정적 인 결과에 협조하는 방식에 따라 달라집니다. 이를 위해서는 장애 조치 클러스터에서 DTC를 실행해야합니다. 이는 전체 시스템의 Achilles가되어 모든 트랜잭션이 DTC를 지우는 데 달려 있기 때문입니다.
거 야 quote 여기에 메시지/일련의 작업으로 2PC 트랜잭션 생각하는 방법의 좋은 예및 보상 2PC 거래에 대한
그랜드 정식 예는 은행 계좌 이체이다. 귀하는 하나의 계좌에서 인출하여 다른 계좌에 대금을 청구합니다.
이 두 작업은 성공하거나 실패해야합니다. 그렇지 않으면 돈을 생성하거나 파기 (불법입니다)하기 때문입니다. 이것이 2PC 트랜잭션을 설명하는 데 매우 일반적으로 사용되는 예제입니다.
캐치는 실제로 작동하는 방식이 아닙니다. 하나의 은행 계좌에서 다른 은행 계좌로 돈을 얻는 것은 상당히 복잡한 일로, 다른 계좌로는 많은 돈이 듭니다. 더 중요한 것은 동기식 실패/성공 시나리오가 아닙니다.
대신 회계 원칙이 적용됩니다 (놀람!). 이전이 시작되면 온라인 뱅킹에서 이체가 계정 시스템에 제출하기 위해 메시지 형식으로 기록되고 차변이 표시된 잔액에 영향을 미치는 '보류 중'트랜잭션으로 계정에 기록된다고 가정 해 봅니다.
사용자의 관점에서 볼 때 트랜잭션은 '완료'되었지만 실제로는 아무 것도 발생하지 않았습니다. 결국 회계 시스템은 메시지를 받고 전송 작업을 시작하게됩니다. 종종 계단식 작업이 이루어지며 그 중 많은 계좌에서 계좌 개설을 예약하고 다른 은행에 통보 할 것을 포함하여 더 많은 메시지를 보냅니다.
여기서의 원칙은 모든 진전이 앞으로 이뤄진다는 것입니다.어떤 기술적 인 이유로 작동이 작동하지 않으면 기술적 이유가 해결되면 다시 시도 할 수 있습니다.
업무상의 이유로 인해 작업이 실패하면 작업을 중단 할 수 있습니다. 그러나 이전 작업을 소멸시키지 않고 이전 작업의 반대 작업을 수행 할 수 있습니다. 계좌에 크레딧이 적립되면 해당 크레딧은 동일한 금액의 이체로 무효화됩니다.
일부 유형의 실패한 트랜잭션의 경우 'inverse'연산이 완전히 대칭이 아니지만 위약금과 같은 추가 작업이 발생할 수 있습니다.
실제로 회계에서 모든 작업을 몰살하는 것은 불법입니다. '삭제'와 '업데이트'는 감옥에 들어가는 가장 좋은 방법입니다.
당신은 Sagas를 고려 했습니까? –