여러 트랜잭션이없는 외부 시스템에서의 원자 적 작동

Question

3 개의 다른 외부 시스템을 연결하는 애플리케이션이 있다고 가정 해보십시오. 모두 3을 업데이트해야합니다. 실패한 경우 작업을 롤백해야합니다. 이것은 구현하기가 어렵지 않지만 작업 3이 실패하고 롤백 할 때 작업 1의 롤백이 실패했다고 말합니다! 이제 첫 번째 외부 시스템이 유효하지 않은 상태입니다 ...

가능한 해결책은 응용 프로그램을 종료하고 외부 시스템의 수동 수정을 강요하지만 다시 시도하는 것입니다. 이 정보를 사용했기 때문에 (또는 아마도 그것이 실패한 이유 일 수도 있습니다) 충분한 액세스 권한이 없을 수도 있습니다. 아니면 액션을 롤백하는 좋은 방법이 아닐 수도 있습니다!

이러한 사례를 처리하는 좋은 방법이 있습니까?

편집 : 일부 응용 프로그램 세부 정보 ..

다중 사용자 웹 응용 프로그램입니다. 대부분의 작업은 Quartz.Net을 통해 예약 된 작업으로 수행되므로 대부분의 작업은 자체 스레드에서 실행됩니다. 일부 사용자 작업은 여러 시스템을 업데이트하는 작업을 트리거해야합니다. 외부 시스템은 다소 불안정합니다.

내가 나쁜 생각이 될 수있는 응용 프로그램을 종료, 응용 프로그램 (기업 대 단일 사용자)의 크기에 따라 작업 패턴

Answer 1

2 단계 커밋 (2PC)이 여기에 적합 할 수 있습니다.

첫 번째 단계는 커밋을 진행할 의사가 있다는 데 동의하는 다양한 데이터베이스를 얻는 것입니다. 예제에서 데이터베이스 1은 3 개의 데이터베이스 모두에서 트랜잭션이 가능하다고보고 될 때까지 쓰기 작업을 진행하지 않습니다.

이것은 "낙관적 인"접근 방식으로 설명하는 프로세스와 비교됩니다. 데이터베이스 1은 트랜잭션이 그렇지 않으면 학습하고 롤백하도록 강요 될 때까지 통과해야한다고 가정합니다.

Answer 2

의 명령 및 단위를 사용하도록 응용 프로그램을 변경하는 생각을했다.

우선, 3 가지 외부 앱에서 변경되는 정보의 초기 상태를 자신의 앱의 로컬 저장소에 저장하는 것이 좋습니다. 즉, 적어도 앱 크래시/롤백 실패/등등과 같은 경우 롤백 상태가 무엇인지 결정할 수 있습니다. 트랜잭션이 성공적으로 커밋되면이 데이터를 삭제할 수 있습니다.

작업 중 하나가 실패 할 때 수행 할 작업은 외부 시스템 3 개 기능에 따라 다릅니다. 이 시스템 중 하나에 직원 데이터가 있다고 가정 해 봅시다. 트랜잭션 실패로 인해 한 직원의 주소가 잘못되어 간단히 응용 프로그램을 종료하는 것은 과도한 작업입니다. 직원의 데이터에 액세스 할 때마다 실패한 트랜잭션 로그 (즉, 3 개의 외부 응용 프로그램의 초기 상태를 저장 한 로컬 저장소)를 단순히 확인하는 것이 좋습니다. 해당 직원 데이터가 유효하지 않은 것으로 플래그되면 레코드가 유효하지 않으며 검색 할 수 없음을 나타내는 오류를 던집니다.

그러나 외부 시스템 전체가 실패한 트랜잭션에 의해 혼란에 빠지면 예 - 여기서 해결할 수있는 것이 없지만 문제가 해결 될 때까지 응용 프로그램을 종료하십시오.

Answer 3

작업 1의 롤백이 실패하는 방법에 대해 자세히 설명하겠습니까?

도착하기를 목표로하는 상태는 이전에 있었던 상태이므로 논리적으로 일관되어야합니다.네트워크 장애와 같은 일시적인 문제가있을 수 있지만 문제를 해결할 때까지 재 시도하는 것이 가장 좋은 방법 일 수 있습니다.

그 다음 트랜잭션이 잠겨 있거나 데이터를 변경 한 경우 문제가 발생하면 훨씬 큰 문제가 발생합니다. 즉, 트랜잭션이 기본이 아니며 롤백하면 다른 트랜잭션의 출력이 유효하지 않을 수 있습니다.

Answer 4

Oddthinking의 대답은 좋은 것이지만 실제로는 매우 어렵 기 때문에 제한적일 것입니다. 2PC를 신뢰할 수 있습니다. 많은 사람들이이를 무시하기 위해 최선을 다했지만, 이것은 분산 컴퓨팅 커뮤니티에서 꽤 오랫동안 알려져 왔습니다.

이 영역에 대해 자세히 알아 보려면 Paxos consensus algorithm을 시작하는 것이 좋습니다. 그리고 이것이 놀랍게도 어려운 문제라는 것을 명심하십시오. 정확히 말하자면, 문제를 암시하는 것과 실제로 제한된 시간 내에 메시지를 전달할 수있는 진정으로 신뢰할 수있는 메시징 시스템을 만드는 것은 실제로 불가능하다는 사실입니다. 그 이유를 이해하려면 someone with a backhoe이 다양한 통신 당사자 간의 모든 네트워크 링크를 없앨 수 있다고 생각하십시오.)

실제 수정 사항은 전체 시스템의 아키텍처와 전반적인 변경 사항을 롤아웃하는 방법으로 판단됩니다. 한 지역에서의 통신 손실이 재앙이 아니라는 사실을 정확한 세부 사항에 따라 수행하기 쉽지 않을 수도 있습니다.