카우치베이스 모바일 2.0의 새로운 데이터 복제 프로토콜 소개

분산 시스템에서는 여러 클라이언트에서 공유 데이터베이스에 대한 업데이트를 동기화해야 합니다. 복제 프로세스의 목표는 로컬 및 원격 데이터베이스의 변경 사항을 동기화하여 모든 모바일 클라이언트와 서버가 데이터를 일관되게 볼 수 있도록 하는 것입니다. Couchbase Mobile에서 복제는 Couchbase Lite를 실행하는 클라이언트와 서버의 동기화 게이트웨이 간에 이루어집니다.

카우치베이스 모바일 2.0 릴리스 는 수많은 새로운 기능 및 개선 사항. 주요 개선 사항은 새롭고 개선된 복제 프로토콜입니다. 이 게시물에서는 Couchbase Mobile 2.0의 새로운 복제 프로토콜의 기본 사항에 대해 소개합니다.
다음에서 Couchbase Mobile 2.0을 다운로드할 수 있습니다. 여기.

배경

그리고 카우치베이스 모바일 플랫폼 는 카우치베이스 라이트 클라이언트에서 실행되는 NoSQL 임베디드 데이터베이스, 그리고 동기화 게이트웨이 데이터 동기화, 데이터 라우팅 및 사용자 인증/인증을 담당합니다. 카우치베이스 서버 데이터 지속성 및 관리를 위해

Couchbase Mobile V1.x에서 복제는 REST 기반 프로토콜을 사용하여 구현되었습니다. CouchDB에서 시작 를 호출합니다. 사실상 복제 로직은 HTTP를 통한 일련의 API 호출로 구현되었습니다.

새로운 계층형 아키텍처

복제 프로토콜 2.0은 새로운 메시징 프로토콜 레이어 웹소켓. 모든 지원 카우치베이스 라이트 2.0 플랫폼 및 동기화 게이트웨이 2.0.

웹소켓 프로토콜은 단일 TCP 소켓 연결을 통해 원격 호스트 간에 전이중 메시지 전달을 가능하게 합니다. 웹소켓 프로토콜은 HTTP 연결로 시작하여 원격 호스트가 웹소켓을 지원하는 경우 웹소켓으로 전환합니다.

새로운 메시징 프로토콜은 옌스 알프케는 멀티플렉싱과 요청/응답 지원을 웹소켓 계층에 추가합니다. 새로운 계층형 아키텍처는 더 깔끔하고 복제 로직과 기본 메시징 전송 간의 문제를 분리할 수 있습니다. 새 프로토콜은 더 빠르고 대역폭과 소켓 리소스가 더 적게 필요합니다. 소켓 리소스가 절약되면 서버에서 동시 연결에 대한 지원을 늘릴 수 있습니다. 마지막으로 WebSocket 프로토콜의 양방향 특성은 피어 투 피어 구성에 적합합니다.

호환성

새로운 복제 프로토콜은 카우치베이스 라이트 2.0 클라이언트 및 동기화 게이트웨이 2.0에서 지원됩니다. 자세한 내용은 호환성 가이드 를 참조하세요.

이 프로토콜은 카우치베이스 모바일 2.0에서 사용되는 기본 복제 프로토콜입니다. 동기화 게이트웨이 구성에서 특별히 활성화할 필요는 없습니다. Couchbase Lite 1.x 클라이언트의 경우, 동기화 게이트웨이가 자동으로 이전 복제 프로토콜로 전환됩니다.

용어

이 토론에서 사용할 몇 가지 용어는 다음과 같습니다.

• "Client" : 카우치베이스 라이트 2.0 클라이언트
• "서버" : 동기화 게이트웨이 2.0
• "소스 데이터베이스" : 변경 사항이 복제되는 로컬 데이터베이스
• "대상 데이터베이스" : 변경 사항이 복제되는 원격 데이터베이스
• "소스 리플리케이터" : 데이터베이스 변경 사항을 전송하는 복제기
• "타겟 리플리케이터" : 데이터베이스 변경 사항을 수신하는 리플리케이터
• "푸시 복제" : 클라이언트가 로컬 소스 데이터베이스에서 원격(서버) 대상 데이터베이스로 데이터베이스 변경 사항을 업로드하는 프로세스
• "풀 복제" : 클라이언트가 원격(서버) 소스 데이터베이스에서 로컬 대상 데이터베이스로 데이터베이스 변경 사항을 다운로드하는 프로세스
• "활성 리플리케이터" : 데이터베이스 변경 사항을 자동으로 푸시 또는 풀링하는 Couchbase Lite 리플리케이터
• "패시브 리플리케이터" : 변경 사항에 대한 푸시 또는 풀 요청에 응답하는 동기화 게이트웨이 리플리케이터

복제 모드

복제 프로세스는 "연속" 또는 "원샷“.

• '연속' 복제 모드에서는 클라이언트와 동기화 게이트웨이 간에 변경 사항이 지속적으로 동기화됩니다.
• '원샷' 모드에서는 변경 사항이 한 번 동기화되고 클라이언트와 서버 간의 연결이 끊어집니다. 향후 변경 사항을 푸시업 또는 풀다운해야 하는 경우 클라이언트는 새 복제를 시작해야 합니다.

개념

프로토콜을 살펴보기 전에 몇 가지 주요 개념을 이해해야 합니다.

수정 트리

카우치베이스는 문서 관리를 위해 다중 버전 동시성 제어(MVCC) 시스템을 사용합니다. 이러한 시스템에서 Couchbase Mobile의 모든 문서는 일련의 수정본으로 저장됩니다. 문서가 생성되면 새 리비전이 자동으로 생성됩니다. 편집이든 삭제든 문서에 대한 모든 업데이트는 해당 문서의 새 리비전이 생성되는 결과를 낳습니다. 삭제를 표시하는 특수 수정본은 묘비 개정. The 현재 개정판 은 문서의 리프 수정본이며, 충돌하는 수정본이 있는 경우 해당 수정본은 우승 리비전. 2.0의 리비전 트리와 충돌 해결에 대한 자세한 내용은 이 주제에 대한 다음 블로그 포스팅을 기대해 주세요.

변경

소스 데이터베이스에는 있지만 대상 데이터베이스에는 없는 현재 수정본은 변경. 따라서 효과적으로 복제 프로세스 변경 사항 동기화 원격 데이터베이스 간

시퀀스 ID

모든 변경 사항은 고유한 시퀀스 ID 시간 순서대로 증가합니다. 마지막으로 수정한 타임스탬프와 비슷하지만, 벽시계 시간이 아니라 자동 증가 카운터라는 점이 다릅니다. 시퀀스 ID는 특정 데이터베이스에 고유하므로 문서가 복제될 때 동일한 시퀀스 ID로 끝나지 않습니다.

참고: Couchbase Lite의 시퀀스 ID는 단순한 정수인 반면, 동기화 게이트웨이의 시퀀스 ID는 긴 base64 문자열일 수 있습니다. 그 이유는 복잡하며 Couchbase Server 클러스터의 노드 간 내부 동시성과 관련이 있습니다. 원격 시퀀스 ID의 정확한 내용은 구현에 따라 다르며 클라이언트는 이에 대해 가정해서는 안 됩니다.

체크포인트

체크포인트는 마지막 시퀀스ID 리플리케이터에 의해 복제됩니다. 모든 복제 주기가 끝날 때마다 리플리케이터는 소스를 체크포인트합니다. 시퀀스ID 대상에 마지막으로 전송된 변경 사항에 해당합니다. 첫 번째 복제 주기에는 체크포인트가 없습니다.

복제는 실제로 어떤 기능을 하나요?

이제 주요 개념을 이해하셨으니 복제는 소스 리플리케이터가 모든 소스 리플리케이터의 변경 사항시퀀스 ID가 마지막 체크포인트보다 큰 리플리케이터를 대상 리플리케이터로 전송합니다. 리비전 바디의 현재 개정과 함께 관련 blob/첨부파일 및 수정본 기록이 복제됩니다.

참고: 동일한 문서가 소스 데이터베이스와 대상 데이터베이스에서 동시에 편집되어 충돌이 발생할 수 있습니다. 충돌과 복제에 대해서는 이 글의 뒷부분에서 조금 더 자세히 설명하겠습니다.

문서가 다음과 같은 경우 제거됨 를 데이터베이스에서 제거하면 제거가 복제되지 않습니다. 제거하면 데이터베이스에서 문서의 모든 흔적이 제거됩니다.

URL 구성표

카우치베이스 라이트 클라이언트는 반드시 ws 동기화 게이트웨이에 연결하기 위한 URL 구성표

다음은 몇 가지 예입니다.

프로토콜

연결 설정

1. 복제가 시작되면 클라이언트는 HTTP를 통해 웹소켓으로 전환할 것임을 나타내는 웹소켓 핸드셰이크 요청을 서버에 보냅니다. 이 요청은 리소스에 대한 특수 헤더가 포함된 HTTP GET 요청입니다. _blipsync 데이터베이스의 URL을 기준으로 합니다.
2. 서버가 프로토콜 전환에 동의한다는 응답을 보냅니다.
3. 일단 웹소켓 핸드셰이크 가 완료되면 소켓은 HTTP에 더 이상 사용되지 않으며, 이후 모든 통신은 웹소켓 메시지로 이루어집니다.

단일 소켓은 푸시 복제와 풀 복제를 동시에 지원할 수 있습니다. 두 유형 모두 체크포인트를 저장하고 검색하며, 계속 진행하려면 해당 체크포인트가 필요하므로 체크포인트 관리에 대해 먼저 설명합니다.

체크포인트 관리

푸시 및 풀 복제 모두 서버에 체크포인트를 저장하고 가져옵니다.

1. 연결이 설정된 후 클라이언트는 getCheckpoint 메시지를 서버에 전송하여 서버에서 마지막으로 알려진 소스 시퀀스 ID를 확인합니다. 요청에는 다음이 포함됩니다:
   • 클라이언트 ID 클라이언트를 식별하는
2. 다음에 대한 응답 getCheckpoint 요청에는 클라이언트에 대해 마지막으로 기록된 체크포인트가 포함됩니다. 체크포인트는 클라이언트가 이전에 생성하고 저장한 JSON 객체로, 클라이언트가 원하는 모든 데이터를 포함할 수 있습니다. 현재 를 입력합니다:
   • 로컬 시퀀스 ID 클라이언트가 마지막으로 푸시한 알려진 시퀀스입니다.
   • 원격 시퀀스 ID 클라이언트가 마지막으로 수신한 시퀀스 ID입니다.
3. 시퀀스가 성공적으로 복제되면 클라이언트가 주기적으로 설정 체크포인트 메시지를 보내 마지막으로 전송된 로컬 시퀀스 ID 및/또는 마지막으로 수신된 원격 시퀀스 ID를 기록합니다.

푸시 복제

푸시 복제 중에 일련의 변경 사항이 자동으로 전송됩니다. 활성 리플리케이터 를 패시브 리플리케이터

1. 체크포인트가 검색된 후 클라이언트 측 리플리케이터가 로컬 데이터베이스에 대한 변경 사항을 감지하면 로컬 시퀀스 ID로 설정하면 클라이언트는 제안변경 메시지를 서버로 전송합니다. 변경 변경된 각 현재 수정본에 해당하는 객체입니다. 여기에는 툼스톤 리비전이 포함됩니다. 변경 사항 자체는 중첩된 JSON 배열로 인코딩되며 다음을 포함합니다:
   • 문서 ID 변경과 관련된 문서의
   • 리비전 ID 문서의 현재 개정판의
   • 서버 Rev ID 알려진 서버 개정 버전이 있는 경우. 알려진 서버 수정본이 없는 경우 생략됩니다. 서버 Rev ID
   • 선택 사항으로 문서 본문의 대략적인 크기를 입력합니다.
2. 서버의 응답은 제안변경 요청에는 다음을 포함하는 JSON 객체가 포함됩니다:
   • 상태 코드 배열로, 각 항목은 리비전 ID에 지정된 제안변경 요청합니다.
     • 값이 0이면 서버가 rev에 관심이 있음을 나타냅니다.
     • 304 값은 서버에 이 리비전이 있음을 나타냅니다.
     • 409 값은 변경으로 인해 충돌이 발생할 수 있음을 나타냅니다.
3. 클라이언트가 rev 메시지 각 개정판에 대해 에서 요청된 제안변경 에 응답합니다. 그리고 rev 메시지의 본문에는 JSON 형식의 문서가 포함되며, 메시지의 헤더에는 메타데이터가 포함됩니다:
   • id 필드의 값은 본문이 포함된 문서의 문서 ID입니다.
   • rev 필드에 개정판에 해당하는 값을 포함시킵니다.
   • 시퀀스 필드에 변경 사항의 시퀀스 ID를 입력합니다.
   • 역사 필드에 쉼표로 구분된 개정판 ID 목록을 포함하는 알려진 조상 개정 에 지정된 대로 변경 사항 응답
4. 결국 rev 메시지가 전송되었습니다. 연속 모드에서는 클라이언트가 로컬 데이터베이스가 변경될 때까지 기다렸다가 1단계로 돌아갑니다. In 원샷 모드로 전환하면 연결이 끊어지고 복제가 종료됩니다.

풀 복제

풀 복제 중에 일련의 변경 사항이 서버의 패시브 리플리케이터 클라이언트의 풀 요청에 대한 응답으로 활성 리플리케이터.

1. 체크포인트가 검색된 후 클라이언트는 하위 교환 헤더가 포함된 메시지를 서버로 전송합니다:
   • 이후 필드에 원격 시퀀스 ID
   • 연속 필드에 연속 모드인지 여부를 표시합니다. 값은 true 는 클라이언트가 변경 사항에 대한 지속적인 알림을 받기를 원한다는 것을 나타냅니다.
   • 배치 필드에 단일 메시지로 전송할 최대 변경 횟수를 나타내는 값을 입력합니다.
2. 서버가 변경 사항 메시지를 클라이언트에 전달합니다. 변경 변경된 각 현재 수정본에 해당하는 객체입니다. 여기에는 툼스톤 리비전이 포함됩니다. 변경 사항 자체는 중첩된 JSON 배열로 인코딩되며 다음을 포함합니다:
   • 원격 시퀀스 ID 서버 측 변경 사항의 시퀀스 ID입니다.
   • 문서 ID 변경과 관련된 문서의
   • 리비전 ID 문서의 현재 개정판의
   • isDeleted 플래그를 사용하여 수정본이 툼스톤인지 여부를 나타냅니다. 값이 1이면 툼스톤 리비전임을 나타냅니다.
   • 선택 사항으로 문서 본문의 대략적인 크기를 입력합니다.
3. 클라이언트의 응답은 변경 사항 요청에는 다음을 포함하는 JSON 객체가 포함됩니다:
   • maxHistory 필드에 클라이언트가 허용하는 최대 기록 크기 값을 입력합니다.
   • 의 배열 알려진 조상에 지정된 각 리비전 ID에 대해 하나의 항목이 있습니다. 변경 사항 요청을 반환합니다. 항목의 null 값은 클라이언트가 해당 수정본에 관심이 없음을 나타냅니다.
4. 서버가 rev 메시지 각 개정판에 대해 에서 요청된 변경 사항 에 응답합니다. 그리고 rev 메시지의 본문에는 JSON 형식의 문서가 포함되며, 메시지의 헤더에는 메타데이터가 포함됩니다:
   • id 본문이 포함된 문서의 문서 ID에 해당하는 값을 가진 필드입니다.
   • rev 필드에 개정판에 해당하는 값을 포함시킵니다.
   • 시퀀스 필드를 변경 사항의 시퀀스 ID에 해당하는 값으로 채웁니다.
   • 역사 필드에는 쉼표로 구분된 개정판 ID 목록이 포함되어 있습니다. 알려진 조상 개정 에 지정된 대로 변경 사항 응답
5. 변경 사항 전송이 완료되면 서버는 빈 변경 사항 메시지를 표시하여 더 이상 전송할 변경 사항이 없음을 알립니다.
6. 모든 변경 사항이 전송된 후 연속 모드에서는 서버가 데이터베이스가 변경되기를 기다리는 동안 연결이 열린 상태로 유지된 다음 2단계로 돌아갑니다. In 원샷 모드로 전환하면 연결이 끊어지고 복제가 종료됩니다.

참고 2~4단계는 '클라이언트'와 '서버'의 역할이 바뀌었을 뿐 푸시 복제 1~3단계와 동일하다는 것을 알 수 있습니다. 클라이언트와 서버의 역할에 완전히 다른 코드가 필요한 HTTP 기반 API와 달리 복제 프로토콜은 매우 대칭적입니다. 이는 특히 클라이언트 간 피어 투 피어 복제의 경우 설계와 구현을 단순화하는 데 도움이 됩니다.

충돌 처리하기

다음과 같은 경우 충돌이 발생합니다. 동시 업데이트에 대한 동일 여러 소스에서 문서 수정본을 동시에 복제할 수 있습니다. 여기서 "동시"는 "복제 사이"를 의미합니다. 클라이언트가 한 시간 동안 오프라인이었다가 다시 돌아오면 해당 클라이언트에서 변경된 내용이 모두 적용됩니다. 해당 시간 동안 는 다른 모든 클라이언트의 변경과 효과적으로 동시에 이루어질 것입니다. 이러한 분산 시스템에서 동시성은 드문 경쟁 조건이 아니라 삶의 사실입니다.

카우치베이스 모바일 2.0은 새로운 충돌 없음 모드로 전환할 수 있습니다. 2.0에서 충돌이 처리되는 방식에 대한 자세한 내용은 이 블로그 게시물의 범위를 벗어나지만 여기에서 자세히 알아볼 수 있습니다. 여기. 높은 수준에서 클라이언트가 리비전을 저장하는 동안 충돌이 발생하면 문서와 연결된 충돌 해결 콜백이 호출되고 그 결과 병합된 리비전이 사용됩니다. 따라서 문서가 충돌된 상태로 눈에 띄게 존재하지 않습니다. 이에 대한 자세한 내용은 다음 블로그 게시물에서 확인할 수 있습니다.

서버 연결이 끊어짐

복제 중에 클라이언트가 서버에 연결할 수 없거나 서버와의 연결이 끊어지면 클라이언트는 지수 백오프 알고리즘을 사용하여 재접속을 시도하며, 재시도할 때마다 점점 더 오래 대기합니다.

• 의 경우 원샷 복제를 사용하면 클라이언트가 포기하기 전에 최대 두 번의 재시도가 이루어집니다.
• 다음과 같은 경우 연속 복제를 누르면 클라이언트는 무기한 재접속을 시도하지만 재시도 간격은 10분을 초과하지 않습니다.

리플리케이터는 장치의 네트워크 연결이 변경되었다는 알림을 받으면 타이머를 취소하고 즉시 다시 시도하지만(WiFi 또는 셀룰러 네트워크에 연결됨), IP 네트워킹 작동 방식으로 인해 장치는 자체 네트워크 인터페이스의 변경만 감지할 수 있고 서버로 가는 경로의 다른 곳, 심지어 로컬 WiFi 라우터에서 발생하는 변경은 감지하지 못합니다. 따라서 케이블 또는 이더넷 연결을 라우터에 다시 연결하면 다음과 같이 됩니다. not 즉시 감지됩니다. 하지만 라우터를 끄면 디바이스의 WiFi 네트워크 인터페이스가 다운되기 때문에 감지됩니다.

연결 끊김을 감지하는 것도 문제가 될 수 있습니다. TCP 연결이 유휴 상태일 때는 어느 쪽으로도 패킷이 전송되지 않으므로 상대방이 갑자기 플러그를 뽑았거나 라우터의 케이블이나 이더넷이 뽑힌 경우와 같이 연결이 끊어진 경우 두 피어 모두 이를 알 수 없습니다. 이 문제를 해결하기 위해 참가자들은 주기적으로 '하트비트' 메시지를 보냅니다. 발신자가 몇 초 이내에 메시지에 대한 응답으로 TCP ACK 패킷을 받지 못하면 연결이 끊어진 것으로 간주합니다.

다음 단계

카우치베이스 모바일 2.0의 복제 2.0 아키텍처는 REST API/HTTP를 기반으로 이전 버전보다 더 깔끔하고 간단하며 리소스 효율이 높습니다.

질문이나 피드백이 있으시면 아래에 댓글을 남기거나 트위터 @rajagp 또는 이메일로 저에게 연락해 주세요. priya.rajagopal@couchbase.com. . 카우치베이스 포럼 를 통해 질문할 수 있습니다.
마지막으로 옌스 알프케(https://github.com/snej), 그의 피드백에 감사드립니다.