싱크 게이트웨이 인스턴스 간 코드 샘플

여기서 게시물, 나는 사이의 복제본에 대해 자세히 설명했습니다. 싱크 게이트웨이 (SG) 인스턴스: 코우치베이스 모바일 (CBM). 작동하는 예제를 보여주기 위해 Swing 기반 UI를 사용하는 간단한 자바 애플리케이션을 작성했습니다. 모든 것을 시연하기 위해 이 앱을 SG의 두 가지 인스턴스와 함께 실행합니다.

이 다이어그램은 애플리케이션 내의 흐름과 SG 쌍과의 통신을 보여줍니다.

편집 창을 통해 JSON 데이터를 입력할 수 있습니다. 해당 데이터는 다음 위치에 저장됩니다: 코우치베이스 라이트 (CBL) 로컬 저장소. 우리는 두 개의 복제(복제본) 세트를 설정했습니다. 하나는 CBL 데이터베이스에서 'Primary'라고 명명한 싱크 게이트웨이(Sync Gateway) 인스턴스로 데이터를 푸시합니다. 이를 간단히 'Primary'라고 부르겠습니다. Primary는 자신을 백업 SG 인스턴스(이하 'Backup'이라고 함)로 복제합니다.

이를 확인하기 위해 저는 다음을 모니터링합니다. 변경 피드 주기억장치와 백업 양쪽 모두에서.

맥에서는 모든 것이 함께 실행됩니다. 개발용 컴퓨터에서 모두 실행되는 완전한 CBM 스택을 설정할 수 있습니다. 이는 초기 개발을 더 쉽게 만들어 줍니다. 또한 모든 구성 요소가 어떻게 결합되어 작동하는지 이해하는 데도 도움이 됩니다. 이에 대해서는 나중에 블로그에 더 자세히 다루겠습니다.

설정과 코드를 차근차근 살펴보겠습니다.

싱크 게이트웨이 구성하기

백업

나는 각 SG 인스턴스를 고유한 JSON 구성 파일로 실행합니다. 백업을 위한 구성은 약간 더 단순합니다. 여기에 있습니다.

SG를 두 대 실행하기 때문에 서로 다른 네트워크 포트를 사용하도록 해야 합니다. 기본적으로 SG는 4984번과 4985번 포트를 사용합니다. 백업용의 처음 몇 줄은 대신 5984번과 5985번 포트에서 수신 대기하도록 설정합니다. 이 포트들에 특별한 의미가 있는 것은 아닙니다. 컴퓨터의 다른 앱에서 사용하지 않는 포트를 선택하기만 하면 됩니다.

나머지 설정 파일은 SG가 모든 것을 로깅하도록 하고, (“walrus” 키워드로 표시되는) 특수 목적의 인메모리 데이터베이스에서 데이터를 제공하도록 설정하며, “GUEST” 사용자를 통해 누구나 자유롭게 접근할 수 있도록 허용합니다. 이는 초기 개발 단계에서 기억해 두면 좋은 유용한 부분입니다. Walrus를 사용하면 서버 백엔드 없이 SG를 독립형으로 사용할 수 있습니다. 모든 권한을 가진 GUEST를 사용하면 인증이나 채널 설정에 대한 걱정 없이 프로그램을 실행할 수 있습니다. 기본적으로 SG는 stderr에 로그를 남긴다는 점에 유의하세요. 대신 파일에 로그를 남기도록 옵션을 추가할 수 있습니다.

기본 및 인스턴스 간 복제

기본(Primary) 구성에서 푸시 복제(push replication)를 설정했습니다. 여기에는 동일한 상용구(boilerplate) 매개변수 중 일부가 포함되어 있습니다.

“복제(replications)” 섹션에서 흥미로운 작업이 이루어집니다. 항목이 배열이라는 점에 주목하세요. 원하는 만큼 복제본을 지정할 수 있습니다. 여기서는 하나만 지정했습니다.

복제본을 지정하려면 소스와 타겟을 제공해야 합니다. 모든 복제는 단방향이라는 점을 기억하십시오.

“source” 매개변수는 “db”로 식별되는 데이터베이스를 복제하려고 함을 나타냅니다. Walrus를 사용하여 이를 설정한 “databases” 아래의 섹션을 볼 수 있습니다.

대상은 동일한 SG 인스턴스에 연결된 다른 데이터베이스일 수도 있고, 여기서 한 것처럼 HTTP URL을 지정할 수도 있습니다. URL의 경로 부분(/db의 경우)에는 원격 데이터베이스의 이름을 사용하세요.

싱크 게이트웨이 실행 중

설정은 primary_gateway_config.json과 backup_gateway_config.json 두 개의 파일에 저장했습니다. 명령줄에서 SG를 수동으로 실행할 수 있습니다. 다양한 플랫폼용 SG 다운로드 및 실행에 대한 정보를 찾을 수 있습니다 여기.

백업을 먼저 시작합니다. 그렇지 않으면 프라이머리가 복제 수행을 위한 연결 실패에 관한 메시지를 많이 출력합니다.

자바 앱

저는 UI에 Swing을 사용하고 레이아웃에는 IntelliJ IDEA를 사용하여 자바 앱을 작성했습니다. 다음은 앱이 시작될 때의 모습입니다.

사용하려면 가장 왼쪽 텍스트 창에 JSON을 붙여넣으세요. 저장 버튼을 클릭하세요. 그러면 CBL 데이터베이스에 새 JSON 문서가 저장됩니다. 동기화는 처음에는 꺼져 있습니다. 활성화하려면 시작 버튼을 클릭하세요.

가운데 텍스트 창은 기본 변경 피드를 모니터링합니다. 가장 오른쪽에 있는 창은 백업 변경 피드를 모니터링합니다.

동기화가 활성화된 상태에서 문서를 저장할 때마다 두 변경 피드가 모두 반응하는 것을 볼 수 있습니다. 그 모습은 다음과 같습니다.

프로젝트 소스는 다음에서 찾을 수 있습니다. 깃허브. (이 샘플은 기초적인 내용을 강조합니다. 프로덕션 품질의 코드가 아닙니다.) 몇 가지 핵심 요소를 살펴보겠습니다.

네 개의 클래스가 있습니다. 대부분의 UI는 DBExplorer.java에 있습니다. DBService.java는 꽤 전형적인 헬퍼 클래스입니다. CBL과 SG 간에 복제가 어떻게 설정되는지 확인하려면 거기를 살펴보세요. Runtime.java는 주로 공유 인스턴스를 가지기 위해 존재합니다 잭슨 JSON ObjectMapper.

SGMonitor.java는 두 개의 변경 피드 모니터링을 담당합니다. 저는 OkHttp Square의 클라이언트 라이브러리를 사용하여 REST 호출을 수행합니다.

변경 피드를 모니터링하기 위해 저는 롱폴링(long-polling)이라는 방식을 사용합니다. 롱폴링을 사용하면 전송할 새 데이터가 없는 경우 HTTP 호출이 즉시 반환되지 않습니다. 대신 새 데이터가 전송되거나(또는 시간 초과될 때까지) 대기합니다. 그런 다음 연결이 닫힙니다. 즉, 변경 레코드를 계속 확인하려면 루프가 필요합니다. 변경 레코드는 JSON으로 전송된다는 점에 유의하세요. 결과는 배열로 번들로 묶이므로 응답당 둘 이상의 레코드를 가질 수 있습니다.

HTTP 요청 생성을 단순화하기 위해, 모든 호출에 필요한 매개변수가 추가된 URL 빌더를 생성합니다.

이를 읽어보면, _changes 엔드포인트에 연결하고, feed 유형을 longpoll로 사용하며, 타임아웃을 0으로 설정하고 있습니다(0은 타임아웃이 절대 발생하지 않음을 의미합니다).

루프를 실행하기 위해 SwingWorker 스레드를 설정했습니다. 이 스레드는 HTTP 요청을 생성하고, 전송한 뒤, 응답을 기다립니다.

여기서 마지막 요령은 Sync Gateway에 필요한 데이터가 무엇인지 알려주는 것입니다. 모든 SG _changes 응답에는 “last_seq” 속성이 포함되어 있습니다. 이 속성은 클라이언트가 이미 받은 레코드를 추적하는 데 도움이 되는 정수일 뿐입니다. 처리한 데이터를 추적하는 것은 클라이언트의 책임입니다. 응답을 처리하고 나면, 향후 요청에 “since” 파라미터를 추가하거나 업데이트해야 합니다. 그러면 SG는 더 최신의 변경 사항만 전달해야 한다는 것을 알게 됩니다.

여기 루프의 후반부가 있습니다.

Jackson ObjectMapper를 사용하여 변경 레코드를 파싱합니다. 그런 다음 last_seq 속성에서 추출한 값을 “since” 쿼리 파라미터로 추가합니다. 그러면 다음 요청을 위한 URL이 설정됩니다. publish 호출은 UI의 텍스트 영역을 업데이트하는 역할을 합니다.

그게 전부입니다. 전체 프로젝트를 단일 기기에서 실행할 수 있습니다. 이를 통해 Couchbase Lite, Sync Gateway 및 복제를 자세히 살펴볼 수 있습니다. 즐기시기 바랍니다.

추신

저희 쪽에서 더 많은 자료를 확인해 보세요 개발자 포털 그리고 트위터에서도 팔로우하세요 @CouchbaseDev.

당사는 다음 곳에 질문을 게시할 수 있습니다. 포럼. 그리고 우리는 적극적으로 참여합니다 스택 오버플로.

저를 개인적으로 팔로우하실 수 있습니다 @HodGreeley