12년후의 CAP정리:"법칙"은 어떻게 변했나?

CAP 정리, 공통의 데이터를 취급하는 네트워크로 연결된 시스템은 3 개의 바람직한 성질 중 2 개 밖에 채울 수없는 것을 나타냅니다. 그러나 명시 적으로 분할 처리함으로써 설계자들은 일관성과 가용성을 최적화하고 3 개의 특성 모두의 균형을 취할 수 있습니다.

CAP 정리가 소개 된 지 10 년 디자이너와 연구원은 CAP 정리를 새로운 분산 시스템을 찾기위한 지침으로 사용 (또는 남용)했습니다. NoSQL도 기존의 데이터베이스에 대한 논거로 CAP 정리를 이용하고 있습니다.

CAP 정리, 공통의 데이터를 취급하는 네트워크로 연결된 시스템이 세 가지 바람직한 성질 중 2 개 밖에 채울 수없는 것을 나타냅니다.

일관성 (C), 즉 단일의 최신 데이터를 가지고
데이터의 업데이트에 대한 고 가용성 (A)
그리고 네트워크 분할에 대한 내성 (P)
CAP 정리의이 표현은 목적을 완수했습니다. 목적은 설계자가 시스템 대한 폭 넓은 시각을 가지고 장단점을 의식하게 될 것입니다. 실제로 지난 10 년 동안 다양한 새로운 시스템이 나타나 일관성과 가용성의 상대적인 장점에 대해서도 많은 논의가되었습니다. 그러나 "3 중 2 개"라는 공식은 오보이었습니다. 라고하는 것은,이 공식은 3 개의 특성의 긴장 관계를 지나치게 단순화 해 버리기 때문입니다. 지나친 단순화는 문제입니다. CAP가 불가능하다고하는 것은 극히 일부의 설계입니다. 즉, 분할이 발생하고있는 상태에서 완벽한 가용성 및 일관성을 갖춘 시스템의 설계입니다. 그러나 현실은 이러한 디자인은 거의 없습니다.

설계자는 분할이 발생했을 때 일관성과 가용성 중 하나를 선택해야하지만, 분할의 취급 방법과 분할 복구에 유연한 대처 방법이 있습니다. 현재 CAP의 목적은 특정 응용 프로그램이 필요로하는 일관성과 가용성을 최적화하는 것입니다. 이러한 방법은 분할 발생중인 계획과 분할 복구 계획이 포함되어 있습니다. 따라서 설계자는 이러한 방법을 채용하는 것으로, 종래 받아왔다 CAP의 한계를 넘어 CAP 생각할 수 있습니다.

왜 "3 개 중 2 개"가 오보인가

CAP을 이해하는 가장 쉬운 방법은 분할의 양쪽에 하나씩 노드가있는 경우를 생각할 수 있습니다. 한쪽 노드 만 상태를 업데이트 할 수 있도록하면 두 노드에 일관성이 없습니다. 즉, C가 손실됩니다. 일관성을 유지하려고하면 한 노드는 사용할 수없는 상태 인 것처럼 작동해야합니다. 이 경우 A가 손실됩니다. 일관성과 가용성을 유지할 수는 두 노드가 통신 할 때뿐입니다. 이 경우 P가 손실됩니다. 일반적으로 광역 시스템의 경우 설계자는 P를 잃는 없기 때문에 C와 A 사이에서 어려운 선택을 강요 당하고 있습니다. 어떤 의미에서는 NoSQL의 발흥은 가용성을 최우선으로 일관성을 뒷전으로하는 대안을 만들어 내고 있다고 말할 수 있습니다. ACID 특성에 따라 데이터베이스 (원 자성, 일관성, 독립성, 내구성)이 반대입니다. "ACID, BASE, CAP"섹션에서이 차이를 자세히 설명합니다.

사실,이 차이에 대한 검토가 CAP 정리를 낳았습니다. 1990 년대 중반, 나는 동료와 함께 다양한 클러스터 기반의 광역 시스템 (클라우드 컴퓨팅의 선구자)을 구축했습니다. 검색 엔진 및 프록시 캐시 콘텐츠 전송 시스템 등입니다 1. 수익 목표와 계약 사양에 대한 시스템 가용성이 최우선입니다, 우리는 캐시를 채택하고, 나중에 데이터 복구에 사용하기 위해 업데이트를 기록하거나하여 가용성을 최적화했습니다 . 그러나 이러한 방법으로 가용성은 향상했지만 일관성이 희생되었습니다.

일관성 대 가용성 논의의 첫 번째 버전은 ACID 대 BASE라는 형태로 나타났습니다 2. 그러나이 논쟁은 당시별로 허용되지 않았습니다. 모두의 ACID 속성을 선호하고 있으며, ACID를 포기할 수 없었기 때문입니다. CAP 정리의 목적은 더 넓게 설계에 대해 탐구해야한다는 것이 었습니다. 그리고 "3 가지 중 2 가지"라는 공식이 출생했습니다. CAP 정리는 1998 년 가을에 태어나 1999 년에 발표되어 2000 년 Symposium on Principles of Distributed Computing4의 기조 연설에서 발표를 계기로 입증되었습니다.

"CAP 혼란"절에 설명 된대로, "3 가지 중 2 가지"일부 장면에서 오보입니다. 먼저 분할은 좀처럼 일어나지 않기 때문에 분할이없는 상태에서 C와 A는 손실되지 않습니다. 다음은 동일한 시스템에서 매우 세분화 몇번이나 C와 A 중 하나를 선택할 수 있습니다. 서브 시스템에서 다른 선택을 할 수 있으며, 조작이나 데이터와 관련된 사용자에 의해 선택을 바꿀 수 있습니다. 마지막으로, 세 가지 특성은 만족 / 만족하지의 두 선택 밖에없는 것이 아니라 정도가 있습니다. 가용성은 분명히 0 %에서 100 %까지 정도가 있지만, 일관성도 다양한 레벨이 있습니다. 분할 내성도 마찬가지입니다. 시스템에 분할이 있는지에 대한 이견도 포함한 정도가 있습니다.

이런 정도를 조사하여 3 개의 특성의 최적화를 도모하는 경우 분할로 기존의 대처법을 더욱 적극적으로 추진해야하지만 여기에는 근본적인 어려움이 따릅니다. 분할은 좀처럼 일어나지 않기 때문에 대부분의 경우 완벽한 C와 A를 얻을 수 있지만 분할이 발생한 경우를 위해 분할을 감지하여 명시 적으로 처리하는 구조를 갖추고 있어야합니다. 이 방법은 3 단계로 나누어집니다. 우선 분할을 감지하는 단계, 그리고 동작이 제한되는 분할 모드에 명시 적으로 이행하는 단계, 마지막으로 복구 프로세스를 시작하고 일관성을 복원하고 분할 중 발생한 오작동을 보상하는 단계입니다.

ACID, BASE, CAP

ACID와 BASE는 일관성과 가용성면 양쪽의 설계 사상입니다. ACID 속성은 일관성에 중점을 둔 데이터베이스의 전통적인 속성입니다. 90 년대 후반, 나는 동료와 함께 당시 등장하기 시작했다 고 가용성을 유지하기위한 설계 방법을 파악 일관성과 가용성의 영역과 그 안에서의 선택을 명시하기 위해 BASE를 만들었습니다. 클라우드를 포함한 대규모 광역 시스템은 2 개의 방법론을 혼합하여 사용하고 있습니다.

ACID 나 BASE도 단어로 기억하기 쉽습니다 만, BASE라는 약자는 조금 이해하기 어렵습니다. BASE는 다음 단어의 머리 글자를 맞추고 있습니다. Basically Available (기본적으로 사용 가능), Soft state (부드러운 상태) Eventually consistent (최종 일관성). 부드러운 상태와 최종 일관성은 분할이 발생했을 경우의 대처법에서 가용성을 담보합니다.

CAP와 ACID의 관계는 복잡하고 혼동하기 쉽습니다. 라고는 ACID A와 C는 CAP의 A와 C와 다른 개념을 나타내고 있기 때문입니다. 또한 가용성에 중점을두고도 ACID가 보장하는 속성의 일부에만 영향을주지 않기 때문입니다. ACID의 4 가지 특성은

원 자성 (A) 모든 시스템 불가분 인 처리의 혜택. 가용성의 관점에서 생각한다면 분할의 양쪽 노드가 분리 처리를 할 필요가있다. 높은 수준의 분리 처리는 복구가 쉽다.

일관성 (C) ACID의 C는 트랜잭션이 고유 키와 같은 데이터베이스의 규칙을 지킨다는 의미. 한편, CAP의 C는 데이터의 단일 사본의 일관성에 관해서 만 언급하고있다. 즉, ACID 일관성의 아주 작은 부분 인 것이다. 또한 ACID의 일관성은 분할에 걸쳐 유지되지 않는다. ACID의 C는 분할 복구 복원되어야한다. 일반적으로 분할 발생시 불변 식을 유지하는 것은 불가능하기 때문에 분할 발생 중에 어떤 처리를하지 않도록 할 것인지, 분할 복구에서 어떻게하고 불변 식을 복원 할 것인지주의 깊게 생각해 둘 필요가있다.

독립성 (I) 독립성은 CAP 정리의 핵심에있다. ACID의 독립성을 요구하는 시스템은 분할이 발생하는 동안 한쪽에서만 작동 할 수있다. 그러나 직렬화 가능성을 담보 할 수 없다. 통신이 필요하기 때문이다. 이 경우 토라자쿠숀의 정확성은 분할의 복구 처리를 전제로 정의된다.

내구성 (D) 개발자는 내구성의 유지가 힘든 때문에 부드러운 상태 (BASE의)를 사용하여 내구성이 필요없는 시스템을 만들려고 할지도 모르지만, 원자 성뿐만 아니라 내구성도 잃고 수 없다. 분할에서의 복구는 모르게 불변 식을 침범했다 지속성있는 처리를 취소 할 수있다. 그러나 복구시에는 분할의 양쪽 지속성있는 처리 기록이 있기 때문에, 그런 처리는 감지 수정할 수있다. 일반적으로는 분할 양쪽에서 ACID 트랜잭션이 실행되고 있으면 복구가 용이하고, 분할 복구에 이용되는 보상 거래의 구조도 활용할 수있다.

CAP와 통신 지연

일반적인 해석은 CAP 정리 지연을 무시하고 있습니다. 그러나 실제로는 지연과 분할에 깊은 관련이 있습니다. CAP의 본질은 시간 초과가 발생했을 때 나타납니다. 즉, 프로그램이 분할이 발생한 경우의 판단을해야 할 때입니다. 즉

처리를 중단하고 가용성을 희생한다. 또는

처리를 진행하고 일관성을 희생한다.

예를 들어 Paxos와 2 단계 커밋을 사용하여 일관성을 보장하기 위해 통신의 리 트라이를하는 것은이 결정을 연기하고있을뿐입니다. 프로그램은 어느 시점에서 판단을 내려야합니다. 무한 재시도를 계속는 A보다 C를 우선한다는 것입니다.

실제로 분할은 통신에있는 일정한 시간 폭으로 나타납니다. 그 일정한 시간 내에 일관성을 보장하는 데 실패했다는 것이 분할의 발생을 설명하며, 이러한 처리에 대해 C 또는 A 중 하나를 선택할 수 있습니다. 이러한 생각은 지연에 대한 설계의 본질적인 과제를 잡습니다. 즉, 분할 양측은 통신하지 않고 독립적으로 처리를 진행 여부 것입니다.

이 실용적인 관점에서 보면 몇 가지 중요한 결론을 이끌 수 있습니다. 첫째 전체에 적용 할 수있는 분할의 개념은 존재하지 않는다는 것입니다. 라고하는 것은, 노드는 분할을 감지 할 수 있지만 다른 노드는 감지하지 않을지도 모르기 때문입니다. 둘째 노드는 분할 된 것을 감지하면 분할 모드, 즉 C와 A의 최적화를 목표로하는 모드가된다는 것입니다.

마지막으로, 설계자는 통신 상대의 응답 시간을 감안하여 의도적으로 시간 폭을 설정할 수 있다는 것입니다. 이 시간 폭이 좁은 시스템은 네트워크 속도뿐 실제로는 분리가 발생하지 않은 경우에도 분할 모드로되어 버릴지도 모릅니다.

광역에 걸쳐 일관성을 유지하기 위해 발생하는 지연을 피하기 위해 엄격한 C를 포기한 것이 좋은 경우도 있습니다. Yahoo의 PNUTS는 원격 복사를 비동기 적으로 관리하기 위해 일관성이 무너집니다 5. 그러나 마스터 복사본이 로컬에 있으므로, 지연은 발생하기 어렵다. 실제로이 방법은 잘 작동합니다. 사용자의 데이터가 해당 사용자의 위치에 의해 자연적으로 나누어 져 있기 때문입니다. 각 사용자의 데이터 마스터가 사용자의 근처에있는 것은 이상적입니다.

Facebook은 반대의 방법을 채용하고 있습니다 6. 마스터 복사본을 하나의 위치에두고 사용자가 자신의 위치에 가깝지만 최신이 아닐 수있는 사본을 사용합니다. 그러나 사용자가 페이지를 업데이트 할 때 잠시 지연이 발생하면서 업데이트도 읽기도 마스터 복사본에 대해 수행됩니다. 20 초 후 근처에있는 사본을 참조하게됩니다. 즉, 업데이트가 근처의 복사에 반영 될 때까지 마스터 복사본을 참조하는 것입니다.

CAP의 혼란

CAP 정리 오해되기 십상입니다. 특히 가용성 및 일관성의 범위에 대해서는 오해가 많습니다. 이 오해로 인해 바람직하지 않은 결과가 발생할 수 있습니다. 사용자가 서비스를 전혀 이용하지 못하면 C도 A도 선택할 수 없습니다.

그림 1

분할의 발생을 감지하는
명시 적으로 기능 제한이있는 분할 모드로
통신이 복원되면 복구 프로세스를 시작하는
마지막 단계의 목적은 일관성을 복원하고 분할 발생중인 프로그램의 실패를 보상하는 것입니다.

그림 1은 분할의 진행을 나타냅니다. 일반적으로 프로세스는 원자 적으로 하나씩 순서대로 실행됩니다. 따라서 분할은 항상 처리 사이에 발생합니다. 초과되면 시스템은 분할을 감지하여 분할을 감지 한 쪽은 분할 모드입니다. 실제로 분할이 발생하는 경우에, 다른 쪽도 분할 모드되지만 한쪽 만 분할 모드로 들어갈 수 있습니다. 이런 경우, 다른 하나는 필요에 따라 통신을하지만 분할을 감지하는 것이 성공적으로 응답하거나 통신을 요구하지 않거나 중 하나입니다. 어디라도 일관성은 유지됩니다. 그러나 분할을 감지하는 것이 일관성을 무시한 처리 될 수 있으므로 분할 모드가되어야합니다. 쿼럼을 사용하는 시스템은이 한쪽 분할 모드 중 하나의 예입니다. 한쪽이 쿼럼을 가지고 처리를 계속 다른 처리를 계속한다는 것입니다. 비 연결 처리는 분명 분할 모드의 개념을 가지고 있습니다. 원자 적 동보 시스템 또는 Java JGroup도 마찬가지입니다.

시스템이 분할 모드에 돌입하면 두 동작이있을 수 있습니다. 하나는 처리를 제한하는 동작으로, 이것은 가용성을 낮 춥니 다. 또 하나는 분할에서의 복구에 도움이 처리 정보를 기록하는 동작입니다. 또한 통신을 시도 있으면 시스템은 언제 분할이 끝난 여부를 확인할 수 있습니다.

어떤 처리를 추진해야 하나

어떤 처리를 제한하거나 그 시스템이 지켜야한다 불변 식에 따라 달라집니다. 설계자는 어떤 불변 식을 유지하고 어떤 불변 식을 유지하지 않는지, 혹은 의도적으로 불변 식을 침해하고 복구시 복구하도록 할 것인지 결정해야합니다. 예를 들어, 테이블의 키는 고유이라는 불변식이 있었다고합니다. 설계자는 보통 분할 모드시에는 굳이이 불변 식을 위반하여 중복 키를 허용합니다. 라고하는 것은 중복 키를 발견하는 것이 쉽지 쉽게 복구 할 수 있기 때문입니다.

그러나 설계자는 분할 발생 동안 유지해야한다 불변 식을 침해 할 수있는 작업이 금지하거나 변경을 할 필요가 있습니다 (일반적으로 어떤 처리가 불변 식을 침해하는 인지는 모릅니다. 분할을 횡단하는 상태가 어떻게되어 있는지 모르기 때문입니다). 신용 카드 결제 처리는 이러한 처리 제한이 걸려 있습니다. 이 경우 처리를 기록해 둡니다 분할에서 복구 한 후 실행합니다. 이러한 트랜잭션은 더 큰 처리의 흐름의 일부이고 명확한 주문 처리 상태를 갖습니다. 또한 분할이 끝날 때까지이 정지해도 큰 문제는 발생하지 않습니다. 설계자는 의미에서 A를 잃지 만 사용자에게 보이지 않습니다. 사용자가 알고있는 것은 자신이 주문을 한 것으로 그 처리 후에 행해지는 것뿐입니다.

일반적으로 분할 모드는 사용자 인터페이스에 난제를들이 댈 있습니다. 작업이 실행 중이지만 아직 끝나지 않는다는 것을 보여줄 필요가 있기 때문입니다. 연구자는 비 연결 처리 문제로이 수수께끼를 탐구하고 왔습니다. 비 연결 처리는 장기간의 분할입니다. 예를 들어, Bayou 캘린더 응용 프로그램은 일관성있는 가능성의 약속을 다른 색으로 표시합니다 13. 이러한 표시 방법은 워크 플로우 애플리케이션과 Google Docs와 같은 오프라인 모드가 클라우드 서비스에서 볼 수 있습니다.

단순히 읽고 쓰기가 아니라 명확한 원자 적 처리에 주목하는 것은 그분이 처리의 불변 식에 미치는 영향을 쉽게 파악할 수 있기 때문입니다. 원래 설계자가 그 제품의 모든 프로세스와 모든 불변 식의 교차 테이블을 만들고 어떤 프로세스가 어떤 불변 식을 침해 할 가능성이 있는지를 파악하고 있어야합니다. 그리고 분할 발생시에 그 처리를 금지하거나 지연 시키거나 변경할지 여부를 결정합니다. 사실,이 결정은 알려진 상태 및 매개 변수에 따라 달라집니다.

분할 양쪽의 처리 내역을 추적하는 데 가장 좋은 방법은 버전 벡터를 사용하는 것이다. 버전 벡터 처리 사이의 인과 관계를 파악합니다. 벡터의 세트 (노드와 논리적 시간)을 가지고 하나의 항목이있는 개체를 업데이트 한 모든 노드 및 업데이트시의 논리 시간의 쌍을 가지고 있습니다. 예를 들어, 2 개의 비켜 객체 A와 B가 모든 노드 벡터에서 A가 B보다 새로운 경우 모든 벡터 A의 논리 시간은 B와 동일한 지 B보다 큰 적어도 하나의 벡터 A 논리 시간은 B보다 큰 것을 알 수 있습니다.

벡터를 순서에 늘어 놓을 수없는 경우 업데이트는 병렬로 진행되며 일관성이 무너지고있을 수 있습니다. 분할의 양쪽 버전 벡터의 기록을 사용하여 어떤 프로세스가 기본 순서로 처리되며, 처리 결과와 병렬 실행되었는지 쉽게 파악할 수 있습니다. 최근의 연구에서는 14 설계자가 가용성을 최우선으로하는 경우 이러한 인과 관계의 일관성을 보장 할 수있는 최선의 결과임을 증명하고 있습니다.

분할 복구

어느 시점에서 통신이 재개 분할은 끝납니다. 분할 동안 분할의 양쪽 작동하고 처리를 계속했지만, 일부 처리 지연, 일부 불변 식은 성립하지 않게되어 있습니다. 이 때, 시스템은 양쪽의 상태와 이력을 알고 있습니다. 분할 발생중인 상세한 로그를 보유하고 있기 때문입니다. 상태보다 기록이 더 유용합니다. 시스템은 기록에서 어떤 처리가 불변 식을 침해하고 무슨 일이 일어 났는지 추측 할 수 있습니다. 사용자에게 응답 내용 등을 확인할 수 있습니다. 복구시에는 설계자는 두 난제를 해결해야합니다.

분할의 양쪽을 일관성을 유지 한 상태로 할
분할 모드시의 처리 실패를 보상 할 수
일반적으로 분할 발생시 상태에서 일관성을 유지할 수 일정한 순서로 작업을 다시 실행하여 현재 상태를 제대로하는 것이 가장 쉬운 방법입니다. Bayou 데이터베이스를있는 시간까지 롤백하고 확정적인 순서로 모든 작업을 다시 실행하여 모든 노드가 동일한 상태에 도달하도록합니다 15. Concurrent Versioning System (CVS)과 같은 소스 코드 관리 시스템뿐만 아니라 일관성있는 시점에서 롤 포워드하고 업데이트를 다시 실행 지점을 병합합니다.

대부분의 시스템은 항상 충돌을 해결할 수있는 것은 아닙니다. 예를 들어, CVS에서 사용자가 수동으로 병합하여야한다 충돌이 있습니다. 오프라인 모드가 위키 시스템을 수동으로 편집해야 충돌이 발생합니다 16.

반대로, 분할 발생중인 프로세스를 선택하여 항상 자동으로 충돌을 병합 할 수있는 시스템도 있습니다. 예를 들어, Google Docs17 텍스트 편집은 분할 발생시는 스타일 적용 및 텍스트 추가 및 삭제 만 가능합니다. 이러한 방법은 경쟁의 일반적인 문제를 해결하지 않지만 실제로는 분할시의 처리를 제한함으로써 시스템이 자동으로 상태를 병합 할 수 있습니다. 위험한 처리를 지연시키는 것은 이러한 방법의 비교적 간단한 구현입니다.

자동으로 상태를 복구하는 일반적인 방법에 가장 가까운 것은 교환 가능한 처리를 사용하는 것이다. 시스템은 처리 내역을 연결하고 일정한 순서로 정렬 실행합니다. 처리가 교환 가능하다는 것은 처리를 원하는 순서대로 정렬된다는 것입니다. 불행히도 교환 가능한 처리는 실현하는 것이 어렵습니다. 예를 들어, 추가 처리는 교환 가능하지만, 경계 값 체크를 수반하는 추가 처리는 교환 할 수는 없습니다.

INRIA의 Marc Shapiro 씨 등의 최근 연구는 18,19 상태 복구를위한 교환 가능한 처리의 이용을 크게 개선했습니다. 연구팀은 가능 換複 제 데이터 형 (commutative replicated data types, CRDT)를 개발했습니다. 이 데이터 형식은 분할 후 수렴하고이 데이터 형식을 사용하여 다음을 수행하는 방법을 설명합니다.

분할시 모든 처리의 교환 가능성을 보장한다. 또는
뭉치 (lattice)에 값을 표현하여 분할 발생중인 모든 프로세스에서 그 무리의 값이 단순하게 증가하는 것을 보장
두 번째 방법은 분할의 양쪽의 값을 최대까지 이동하여 상태를 복구하는 방법입니다. 이것은 Amazon이 장바구니에서 제공하는 방법을 공식화 개선 한 것입니다 20. 분할이 끝난 후 두 장바구니는 일정한 처리의 조합을 적용하여 복구 상태입니다. 이 방법의 경우 삭제 된 상품이 부활 버릴지도 모릅니다.

그러나 CRDT 분할 내성이 제품의 추가 및 삭제가 가능한 집합을 구현할 수 있습니다. 이 방법의 중요한 점은 두 집합을 처리하는 것입니다. 각각의 집합은 수렴합니다. 두 집합의 차이도 마찬가지입니다. 시스템은 어느 시점에서 두 집합에서 삭제 된 항목을 제거합니다. 그러나 분할이 발생하지 않은 때 않으면이 처리되지 않습니다. 즉, 분할 발생 중에는 금지하거나 연기해야 ​​처리가 있지만, 그것은 가용성을 훼손하지 않는다는 것입니다. 이렇게 CRDT을 사용하여 상태를 구현함으로써 설계자는 A를 담보하면서 자동으로 상태를 복원 할 수 있습니다.

처리 실패를 보상한다

분할 후의 상태의 복구뿐만 아니라 분할 모드 사이의 처리 실패를 보상하는 어려운 문제가 있습니다. 분할 모드시의 처리 추적 및 처리 제한 덕분에 어떤 불변 식을 침범되었는지를 알 수 있으므로 설계자는 불변 식의 복구 방법을 만들 수 있습니다. 보통 시스템은 분할 복구시에 침해 된 불변 식을 찾아 내고 그 때 수정을 해 버립니다.

불변 식 침해의 수정에는 여러 가지가 있습니다. "마지막으로 쓴 승리"(일부 업데이트가 무시된다)라고하는 흔한 방법과 병합 처리보다 현명한 방법 인간에게 통지하고 해결하는 방법 등 다양합니다. 인간에게 통지하는 방법의 예로는 비행기의 오버 부킹이 있습니다. 오버 부킹이 발생하고있는 비행기에 탑승는 방식으로 분할 복구합니다. 이 복구는 비행기의 좌석 수와 승객의 수가 일치해야한다는 불변 식을 포함한다. 만약 승객이 좌석 수보다 많은 경우 사람의 좌석이 없습니다. 이 경우 고객 서비스가 좌석이없는 승객에게 어떤 보상을 실시합니다.

이 비행기의 예는 구체화 된 처리 실패의 예이기도합니다. 만약 항공사가 승객에게 좌석이 있다고 전하고 있지 않으면, 수정은 더 쉬울 것입니다. 위험한 처리를 지연되는 이유도 여기에 있습니다. 즉, 복구시에는 진실이 알고있는 것입니다. 보상의 개념은 이러한 처리 실패에 가장 중요합니다. 설계자는 불변 식을 복구하고 외부화 된 실패를 보상 처리를 작성해야합니다.

기술적으로 CRDT는 로컬에서 확인할 수 불변성만을 허용합니다. 이 제한은 보상 불필요하지만 동시에이 기술의 힘을 다소 약화. CRDT을 사용한 상태 복원 방법은 글로벌 불변 식을 일시적으로 침해 할 가능성이 있지만, 분할이 끝난 후 상태를 복원하고 필요한 보상 처리를 실행합니다.

외부화 된 처리 실패 복구는 외부에 출력 기록이 필요합니다. 예를 들어, 만취 전화 해 버린 경우를 생각해 봅시다. 어떤 사람은 전날 밤, 만취하는 동안 여러 사람에게 전화를 걸어 버렸 습니다만 기억하지 않습니다. 다음날 그의 상태는 문제 없을지도 모르지만, 전화 발신은 남아 있습니다. 이 중 어느 하나의 발신이 어떤 문제를 일으키는 원인이 될 수 있습니다. 이 발신 그의 상태 (만취)의 외부 효과입니다. 그는 기억하지 않기 때문에 어떤 문제가 발생해도 보상하는 것은 어려울 것입니다.

컴퓨터는 분할 발생 중에 동일한 작업을 두 번 수행 할 수 있습니다. 시스템이 의도적으로 2 회 처리 한 경우와 처리가 중복 버린 경우를 구별 할 수 있으면 중복 된 작업을 취소 할 수 있습니다. 실패가 구체화되어 버리면, 고객에게 이메일을 자동 전송 시스템 문제로 인해 처리를 두 번 버렸지 만이 처리 실수는 이미 수정하고 있음을 설명하고 다음 쇼핑에서 사용할 수있는 할인 쿠폰을 송부하면 좋을 것입니다. 그러나 적절한 처리 내역이 없으면 처리 오류의 불편은 고객에게 전가되어 버립니다.

장시간의 트랜잭션을 처리하기 위해