양방향 동기화를위한 충돌 해결


24

연결을 항상 사용할 수 없다고 가정하면 '기본'데이터베이스 서버와 많은 '보조'서버 간의 양방향 동기화, 특히 충돌 해결을 어떻게 관리합니까?

예를 들어, iOS에서 CoreData를 '데이터베이스'로 사용하는 모바일 앱이 있으며 사용자가 인터넷에 연결하지 않고도 컨텐츠를 편집 할 수 있도록하려고합니다. 동시에이 정보는 장치가 연결될 웹 사이트에서 사용할 수 있습니다. 두 DB 서버의 데이터가 충돌 할 경우 어떻게해야합니까?
(CoreData를 DB 서버라고하는데 약간 다른 점을 알고 있습니다.)

이런 종류의 문제를 처리하기위한 일반적인 전략이 있습니까? 다음은 내가 생각할 수있는 옵션입니다.
1. 항상 클라이언트 측 데이터를 우선 순위가 높은 것으로 사용합니다
. 2. 서버 측과 동일합니다.
3. 각 필드의 편집 타임 스탬프를 표시하고 최신 편집을 수행하여 충돌을 해결하십시오.

비록 세 번째 옵션이 치명적인 데이터 손상을위한 공간을 열 것이라고 확신합니다.

나는 CAP 정리가 이것과 관련이 있다는 것을 알고 있지만 결국 일관성을 원하기 때문에 완전히 배제하지는 않습니까?

관련 질문 : 양방향 데이터 동기화를위한 모범 사례 패턴 . 이 질문에 대한 두 번째 대답은 아마 할 수 없을 것입니다.


답변:


14

"어느 변경이 올바른지"알기위한 일반적인 해결책은 벡터 클럭 입니다. 기본적으로 데이터를 보유하는 각 저장소의 카운터를 추적하고 다른 모든 사람의 상태에 대한 특정 클라이언트의 관점이 연결된 피어의 관점과 다른 경우 변경 사항을 거부합니다.

당신이 대답해야 할 큰 문제는 거절 된 저축을 해결하는 방법입니다. 이것은 일반적으로 일종의 병합 작업을 의미합니다.

벡터 클럭 실시간 타임 스탬프를 사용 하지 않습니다 . 실시간 클럭 동기화와 관련된 문제는 데이터 동기화만큼 어렵습니다.


1
니스, 이것이 내가 찾던 것
K.Steff

10

이것은 비잔틴 장군 문제이며 해결할 수 없습니다. 당신은 결코 보장되지 는 보장 할 수 없습니다 경우 두 서버 동기화를 미래의 어떤 시점에서 , 당신은 모두 한 번에 동기화를 수행 할 수있는 신뢰할 수있는 대역폭을해야합니다.


좋아, 그러나이 사람들은 어떻게 비슷한 효과를 얻
습니까?

3
그들은 미래에 언젠가 충분한 대역폭을 안정적으로 연결한다고 가정합니다.
DeadMG

1

표준 방법이 없다고 생각합니다. 각 시스템은 충돌 해결을 위해 자체 정책을 사용합니다.

Google Docs가 충돌을 자동으로 처리하는 방법을 확인하기 위해 컴퓨터와 휴대 전화 및 Google 스프레드 시트 두 기기를 사용하여 시뮬레이션을 수행했습니다. 여기 몇 가지 경우가 있습니다 :

사례 1

  1. 컴퓨터와 전화가 오프라인 상태입니다
  2. '컴퓨터'값을 가진 컴퓨터 편집 셀 및 '전화'값을 가진 전화 편집 셀
  3. 컴퓨터가 온라인 상태가됩니다
  4. 전화가 온라인 상태가되고 컴퓨터와 전화 모두 '전화'를 표시합니다.

사례 2

  1. 컴퓨터와 전화가 오프라인 상태입니다
  2. '컴퓨터'값을 가진 컴퓨터 편집 셀 및 '전화'값을 가진 전화 편집 셀
  3. 전화가 온라인 상태가됩니다
  4. 컴퓨터가 온라인 상태가되고 컴퓨터와 전화 모두에 '컴퓨터'가 표시됩니다.

따라서 적어도 Google 문서 서버는 수신 한 마지막 데이터 (클라이언트 타임 스탬프)와 상관없이 가장 높은 우선 순위로받은 데이터를 사용합니다. 또한 백그라운드에서 동기화되는지 테스트했지만 분명히 일치하지 않으므로 충돌 해결의 결과가 사용자에게 투명합니다.

반면에 GIT는 충돌을 자동으로 처리하지 않지만 대신 저장소를 변경하려는 마지막 사용자에게 병합 수행 방법을 위임합니다.

사용자가 데이터를 시각화하여 포 그라운드에서만 동기화하면 Google 문서 접근 방식을 사용합니다. 그렇지 않으면 사용자는 자신의 휴대 전화가 자동으로 WiFi에 연결되어있는 동안 PC에서 다시 편집 한 후 미팅과 동기화되지 않은 변경 사항이 적용되었다는 사실에 놀라게 될 수 있습니다.

백그라운드 동기화가 필요하다면 클라이언트 타임 스탬프를 신뢰할 수 있고 원하지 않는 병합 비용이 사용자에게 원하는 버전을 선택하도록 요청하는 비용보다 저렴합니다. 유지.

그렇지 않으면 GIT 접근 방식으로 갈 것입니다. 포 그라운드에서 다음 클라이언트에 팝업을 표시하여 유지할 버전을 선택하거나 병합을 되돌릴 수있는 기회를 제공합니다.


1
사례 별 접근 방식이 여기에 적합한 방법이라는 데 동의합니다. 사용자가 변경 사항을 검토 / 병합하고 싶지 않을 수 있으므로 "최상의"방법 (git 접근 방식)이 항상 적용 가능한 것은 아닙니다.
K.Steff
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.