원자 커밋

Atomic commit

컴퓨터 과학 분야에서 원자 커밋은 일련의 뚜렷한 변화를 하나의 연산으로서 적용하는 연산이다.변경사항이 적용되면 원자력이 성공한 것이라고 한다.원자력이 완료되기 전에 오류가 발생하면, 원자력이 완료된 모든 변경은 역전된다.이것은 시스템이 항상 일관된 상태로 유지되도록 한다.고립의 또 다른 핵심 속성은 원자 작전으로서의 그들의 성격에서 나온다.고립은 한 번에 하나의 원자 커밋만 처리되도록 보장한다.원자력 커밋의 가장 일반적인 용도는 데이터베이스 시스템과 버전 제어 시스템에 있다.

원자핵 약속의 문제는 그것들이 여러 시스템들 사이의 조정을 필요로 한다는 것이다.[1]컴퓨터 네트워크가 신뢰할 수 없는 서비스인 만큼, 이것은 어떤 알고리즘도 Two Generals 문제에서 입증된 것처럼 모든 시스템과 조정될 수 없다는 것을 의미한다.데이터베이스가 점점 더 분산될수록, 이러한 조정은 진정한 원자 약속을 만드는 어려움을 증가시킬 것이다.[2]

사용법

원자핵 커밋은 데이터에 대한 다단계 업데이트에 필수적이다.이는 두 당좌예금 계좌 사이의 송금 사례에서 분명히 알 수 있다.[3]

이 예는 X 계좌에서 Y 계좌로 100달러를 송금하는 거래에서 Y 계좌 잔액을 확인하는 거래로 복잡하다.우선, 계좌 X에서 100달러가 없어진다.둘째, 계좌 Y에 100달러가 추가된다.만약 전체 작전이 하나의 원자 커밋처럼 완료되지 않는다면, 몇 가지 문제가 발생할 수 있다.X에서 돈을 빼서 Y로 추가하기 전에, 중간에 시스템이 실패하면 100달러는 그냥 사라진 것이다.또 다른 쟁점은 100달러가 추가되기 전에 Y의 잔액을 확인하면 잘못된 잔액이 보고된다는 것이다.

원자력이 있는 경우 이 두 경우 모두 일어날 수 없는 경우, 시스템 실패의 첫 번째 경우, 원자력이 다시 롤백되어 X에게 돈을 돌려줄 것이다.두 번째 경우, Y의 균형에 대한 요청은 원자력이 완전히 완료될 때까지 일어날 수 없다.

데이터베이스 시스템

데이터베이스 시스템에서 원자 커밋은 AID,[4] 원자성 및 정합성의 두 가지 주요 특성 중 하나를 충족한다.일관성은 원자핵 커밋의 각 변화가 일치해야 달성된다.

예에서 볼 수 있듯이, 원자핵약정은 데이터베이스에서 다단계 작업에 매우 중요하다.데이터베이스가 상주하는 실제 디스크의 현대적인 하드웨어 설계로 인해 진정한 원자핵 커밋은 존재할 수 없다.디스크에 쓸 수 있는 가장 작은 영역을 섹터라고 한다.단일 데이터베이스 항목은 여러 다른 섹터에 걸쳐 있을 수 있다.한 번에 한 부문만 쓸 수 있다.이 글쓰기 한계는 진정한 원자약속이 불가능한 이유다.메모리의 데이터베이스 항목을 수정한 후에는 디스크에 기록하기 위해 대기열에 저장된다.이는 예에서 확인된 동일한 문제가 재발했다는 것을 의미한다.이 문제에 대한 어떤 알고리즘적인 해결책도 여전히 두 장군 문제에 직면할 것이다.2상 커밋 프로토콜과 3상 커밋 프로토콜 시도는 이것과 원자 커밋과 관련된 다른 문제들 중 일부를 해결하기 위한 것이다.

2상 커밋 프로토콜은 코디네이터가 데이터베이스의 원래 상태를 복구하는 데 필요한 모든 정보를 이상이 발생할 경우 유지하도록 요구한다.이름에서 알 수 있듯이 투표와 커밋의 두 단계가 있다.

투표 단계 동안 각 노드는 원자핵 커밋의 변경 사항을 자신의 디스크에 기록한다.그런 다음 노드들은 자신의 상태를 코디네이터에게 보고한다.노드가 코디네이터에게 보고하지 않거나 상태 메시지가 손실된 경우 코디네이터는 노드의 쓰기 실패를 가정한다.모든 노드가 코디네이터에 보고하면 2단계 작업이 시작된다.

커밋 단계 동안 코디네이터는 각 노드에 커밋 메시지를 보내 개별 로그에 기록한다.이 메시지가 노드의 로그에 추가될 때까지, 변경된 내용은 불완전한 것으로 기록된다.노드 중 하나라도 오류를 보고하면 코디네이터가 대신 롤백 메시지를 보내게 된다.이렇게 하면 노드가 디스크에 쓴 모든 변경 사항이 제거된다.[5][6]

3상 커밋 프로토콜은 커밋 단계 중에 코디네이터와 다른 노드가 동시에 실패하면 발생하는 2상 커밋 프로토콜의 주요 문제를 제거하려고 하는데, 이 두 가지 모두 어떤 조치가 일어나야 하는지 알 수 없다.이 문제를 해결하기 위해 프로토콜에 세 번째 단계가 추가된다.커밋 단계 준비는 투표 단계 이후와 커밋 단계 전에 이루어진다.

투표 단계에서, 2단계 커밋과 유사하게, 코디네이터는 각 노드가 커밋할 준비가 되어 있다고 요청한다.노드에 장애가 발생하면 코디네이터가 장애가 발생한 노드를 기다리는 동안 시간 초과됨.이 경우 코디네이터는 모든 노드에 중단 메시지를 전송한다.노드 중 하나라도 고장 메시지를 반환하는 경우에도 동일한 조치가 수행된다.

투표 단계의 각 노드로부터 성공 메시지를 수신하면 커밋 준비 단계가 시작된다.이 단계에서 코디네이터는 각 노드에 준비 메시지를 보낸다.각 노드는 준비 메시지를 확인하고 회신해야 한다.응답이 누락되거나 준비되지 않은 노드가 반환되는 경우 코디네이터는 중단 메시지를 발송한다.제한 시간이 만료되기 전에 준비 메시지를 수신하지 않는 노드는 커밋을 중단한다.

모든 노드가 준비 메시지에 회신하면 커밋 단계가 시작된다.이 단계에서 코디네이터는 각 노드에 커밋 메시지를 보낸다.각 노드가 이 메시지를 수신하면 실제 커밋을 수행한다.메시지가 손실되어 커밋 메시지가 노드에 도달하지 못하거나 코디네이터가 실패하면 시간 초과가 만료되면 커밋을 수행하게 된다.복구 시 코디네이터가 실패하면 각 노드에 커밋 메시지를 전송한다.[7]

수정제어

원자핵 커밋은 버전 제어 소프트웨어의 공통적인 특징이며 저장소의 일관된 상태를 유지하는 데 중요하다.[8]대부분의 버전 제어 소프트웨어는 실패한 커밋의 어떤 부분도 적용하지 않을 것이다.주목할 만한 예외는 CVS, VSS 및 IBM Rational ClearCase(UCM 모드일 경우)이다.[9]

예를 들어 버전 제어 소프트웨어가 자동으로 해결할 수 없는 병합 충돌에 직면하면 변경사항 집합의 일부가 병합되지 않는다.대신 개발자에게 변경사항을 되돌리거나 수동으로 충돌을 해결할 수 있는 기회가 주어진다.

이는 부분적으로 적용된 변경 집합으로 인해 전체 프로젝트가 손상된 상태로 들어가는 것을 방지하는데, 이 경우 커밋의 한 파일은 성공적으로 커밋되지만 종속 변경 사항이 있는 다른 파일은 실패한다.[10]

원자핵 커밋은 또한 모노레포로 알려진 버전 제어 소프트웨어 개발 전략을 사용하여 한 번의 작업으로 버전 제어 소프트웨어를 사용하여 여러 프로젝트를 동시에 변경할 수 있는 능력을 나타낼 수 있다.[8]

원자핵 커밋 규약

개정 제어 시스템을 사용할 때 공통적인 관례는 작은 커밋을 사용하는 것이다.이것들은 (이론적으로) 시스템의 단일 측면에만 영향을 미치기 때문에 때로는 원자 약정이라고 불린다.이러한 원자핵 약속은 이해도를 높이고, 변화를 되돌리려는 노력을 줄이며, 버그 식별을 용이하게 한다.[11]

더 큰 이해력은 커밋의 작은 크기와 집중적인 성격에서 나온다.한 가지 종류의 변화만을 찾는다면 무엇이 변화하고 그 이면에 있는 추리를 이해하는 것이 훨씬 쉽다.이는 소스 코드를 포맷할 때 특히 중요해진다.형식과 기능적 변화가 결합되면 유용한 변화를 식별하기가 매우 어려워진다.파일의 간격이 탭 사용에서 파일의 모든 탭이 변경된 것으로 표시될 3개의 공백으로 변경되었다고 가정해 보십시오.검토자가 단순히 기능 변경을 보지 않을 수 있기 때문에 일부 기능 변경도 수행되는 경우 이는 매우 중요해진다.[12][13]

만약 원자핵만 이루어진다면, 도입 오류가 식별하기 훨씬 더 간단해진다고 커밋한다.그것이 오류의 원인인지 확인하기 위해 모든 약속을 살펴볼 필요는 없으며, 기능성을 다루는 커밋만 검사하면 된다.만약 오류가 다시 롤백된다면, 원자력이 다시 일을 훨씬 더 단순하게 만든다.나중에 변경사항을 통합하기 전에 위반되는 개정판으로 되돌아가서 수동으로 변경사항을 제거해야 하는 대신, 개발자는 식별된 커밋의 변경사항을 되돌릴 수 있다.이는 또한 개발자가 우연히 동일한 커밋에 있었던 관련 없는 변경사항을 제거할 위험을 감소시킨다.

또한 원자성 커밋은 한 번에 하나의 버그 픽스만 커밋된 경우 버그 픽스를 쉽게 검토할 수 있도록 한다.관련성이 없는 여러 파일을 검사해야 하는 대신 검토자는 수정 중인 버그에 직접적인 영향을 미치는 파일 및 변경 사항만 검사해야 한다.이는 버그를 수정하는 변경사항만 커밋에 있기 때문에 버그 수정을 테스트를 위해 쉽게 패키징할 수 있다는 것을 의미하기도 한다.

참고 항목

참조

  1. ^ Bocchi, Wischik (2004). A Process Calculus of Atomic Commit.
  2. ^ Garcia-Molina, Hector; Ullman, Jeff; Widom, Jennifer (2009). Database Systems The Complete Book. Prentice Hall. pp. 1008–1009.
  3. ^ Garcia-Molina, Hector; Ullman, Jeff; Widom, Jennifer (2009). Database Systems The Complete Book. Prentice Hall. p. 299.
  4. ^ Elmasri, Ramez (2006). Fundamentals of Database Systems 5th Edition. Addison Wesley. p. 620.
  5. ^ Elmasri, Ramez (2006). Fundamentals of Database Systems 5th Edition. Addison Wesley. p. 688.
  6. ^ Bernstein, Philip A.; Hadzilacos, Vassos; Goodman, Nathan (1987). "Chapter 7". Concurrency Control and Recovery in Database Systems. Addison Wesley Publishing Company.
  7. ^ Gaddam, Srinivas R. Three-Phase Commit Protocol.
  8. ^ a b Levenberg, Rachel Potvin, Josh (July 2016). "Why Google Stores Billions of Lines of Code in a Single Repository". Communications of the ACM. Retrieved 20 July 2018.
  9. ^ Smart, John Ferguson (2008). Java Power Tools. "O'Reilly Media, Inc.". p. 301. ISBN 9781491954546. Retrieved 26 July 2018.
  10. ^ Vesperman, Jennifer (2009). Essential CVS (2nd ed.). Sebastopol: O'Reilly Media, Inc. p. 7. ISBN 9780596551407. A feature that CVS doesn't have, and that many teams like, is atomic commits. This feature ensures that while one person is committing changes to the repository, no one else can. Thus, each commit is a separate process, and the repository is never in a state where it has mismatched files.
  11. ^ "Subversion Best Practices". Apache.
  12. ^ Barney, Boisvert. Atomic Commits to Version Control.
  13. ^ "The Benefits of Small Commits". Conifer Systems.