"하둡. Mail.Ru Group Technostream 시리즈의 ZooKeeper "Hadoop에서 대용량 데이터의 분산 처리 방법"

"Hadoop에서 대용량 데이터의 분산 처리 방법" 시리즈 중 "Hadoop. ZooKeeper" 강의 대본을 읽어 보시기 바랍니다.

Hadoop 생태계에서 ZooKeeper의 위치는 무엇입니까? 분산 컴퓨팅에 대한 허위 사실. 표준 분산 시스템의 다이어그램. 분산 시스템을 조정하는 데 어려움이 있습니다. 전형적인 조정 문제. ZooKeeper 디자인의 기본 원칙. ZooKeeper 데이터 모델. znode 플래그. 세션. 클라이언트 API. 기본 요소(구성, 그룹 멤버십, 단순 잠금, 리더 선택, 무리 효과 없는 잠금) ZooKeeper 아키텍처. 주키퍼 DB. ZAB. 요청 처리기.

오늘은 ZooKeeper에 대해 이야기하겠습니다. 이것은 매우 유용합니다. 다른 Apache Hadoop 제품과 마찬가지로 로고가 있습니다. 그것은 남자를 묘사합니다.

이전에 우리는 그곳에서 데이터를 처리하는 방법, 저장 방법, 즉 어떻게든 사용하고 작업하는 방법에 대해 주로 이야기했습니다. 그리고 오늘 저는 분산 애플리케이션 구축에 대해 조금 이야기하고 싶습니다. ZooKeeper는 이 문제를 단순화할 수 있는 기능 중 하나입니다. 이는 분산 시스템, 분산 애플리케이션의 프로세스 상호 작용을 조정하기 위한 일종의 서비스입니다.

그러한 응용 프로그램에 대한 필요성은 매일 점점 더 커지고 있으며, 이것이 바로 우리 과정의 전부입니다. 한편으로 MapReduce와 이 기성 프레임워크를 사용하면 이러한 복잡성을 완화하고 프로그래머가 프로세스의 상호 작용 및 조정과 같은 기본 요소를 작성하지 않아도 됩니다. 그러나 반면에 이것이 어쨌든 수행될 필요가 없다고 보장하는 사람은 아무도 없습니다. MapReduce 또는 기타 기성 프레임워크는 이를 사용하여 구현할 수 없는 일부 사례를 항상 완전히 대체하지는 않습니다. MapReduce 자체와 기타 여러 Apache 프로젝트를 포함하며 실제로 이들 프로젝트도 분산 애플리케이션입니다. 그리고 더 쉽게 작성하기 위해 ZooKeeper를 작성했습니다.

모든 Hadoop 관련 애플리케이션과 마찬가지로 Yahoo! 이제 공식 Apache 애플리케이션이기도 합니다. HBase만큼 적극적으로 개발되지는 않습니다. JIRA HBase에 가면 매일 수많은 버그 보고서와 무언가를 최적화하기 위한 수많은 제안이 있습니다. 즉, 프로젝트 생활이 지속적으로 진행되고 있습니다. ZooKeeper는 상대적으로 단순한 제품인 동시에 신뢰성을 보장합니다. 그리고 사용하기가 매우 쉽기 때문에 Hadoop 생태계 내 애플리케이션의 표준이 되었습니다. 그래서 어떻게 작동하는지, 어떻게 사용하는지 이해하기 위해 복습해 보는 것이 도움이 될 것이라고 생각했습니다.

어느 강의에서 본 사진입니다. 지금까지 우리가 고려한 모든 것과 직교한다고 말할 수 있습니다. 그리고 여기에 표시된 모든 것은 어느 정도 ZooKeeper와 함께 작동합니다. 즉, 이러한 모든 제품을 사용하는 서비스입니다. HDFS나 MapReduce는 특별히 작동하는 유사한 서비스를 자체적으로 작성하지 않습니다. 따라서 ZooKeeper가 사용됩니다. 이는 개발 및 오류와 관련된 일부 작업을 단순화합니다.

이 모든 것이 어디서 오는가? 서로 다른 컴퓨터에서 두 개의 애플리케이션을 병렬로 실행하고 이를 문자열이나 메시로 연결하면 모든 것이 작동하는 것처럼 보입니다. 그러나 문제는 네트워크가 신뢰할 수 없다는 것입니다. 트래픽을 스니핑하거나 낮은 수준에서 무슨 일이 일어나고 있는지, 클라이언트가 네트워크에서 상호 작용하는 방식을 살펴보면 일부 패킷이 손실되거나 다시 전송되는 것을 종종 볼 수 있습니다. 특정 세션을 설정하고 메시지 전달을 보장할 수 있는 TCP 프로토콜이 발명된 것은 아무것도 아닙니다. 그러나 어쨌든 TCP조차도 항상 당신을 구할 수는 없습니다. 모든 것에는 시간 초과가 있습니다. 네트워크가 잠시 동안 중단될 수도 있습니다. 그냥 깜박일 수도 있습니다. 그리고 이 모든 것은 네트워크의 신뢰성을 신뢰할 수 없다는 사실로 이어집니다. 이는 네트워크가 없고 메모리에 더 안정적인 데이터 교환 버스가 있는 하나의 컴퓨터나 하나의 슈퍼컴퓨터에서 실행되는 병렬 응용 프로그램을 작성하는 것과의 주요 차이점입니다. 그리고 이것은 근본적인 차이점입니다.

무엇보다도 네트워크를 사용할 때 항상 특정 지연 시간이 발생합니다. 디스크에도 있지만 네트워크에는 더 많은 것이 있습니다. 지연 시간은 약간의 지연 시간으로, 작거나 상당히 클 수 있습니다.

네트워크 토폴로지가 변경되고 있습니다. 토폴로지란 무엇입니까? 이것은 네트워크 장비의 배치입니다. 데이터 센터가 있고, 거기에 서있는 랙이 있고, 양초가 있습니다. 이 모든 것을 다시 연결하거나 이동할 수 있습니다. 이 모든 것도 고려해야 합니다. IP 이름이 변경되고 트래픽이 이동하는 라우팅이 변경됩니다. 이 점 또한 고려해야 합니다.

네트워크는 장비 측면에서도 변경될 수 있습니다. 실제로 우리 네트워크 엔지니어들은 주기적으로 촛불에 대한 업데이트를 정말 좋아한다고 말할 수 있습니다. 갑자기 새로운 펌웨어가 나왔고 일부 Hadoop 클러스터에는 특별히 관심이 없었습니다. 그들은 자신의 직업을 가지고 있습니다. 그들에게 가장 중요한 것은 네트워크가 작동한다는 것입니다. 따라서 그들은 거기에 무언가를 다시 업로드하고 하드웨어에서 플래싱을 수행하고 하드웨어도 주기적으로 변경되기를 원합니다. 이 모든 것을 어떻게 든 고려해야합니다. 이 모든 것이 분산 애플리케이션에 영향을 미칩니다.

보통 어떤 이유에서인지 대량의 데이터로 작업을 시작하는 사람들은 인터넷이 무한하다고 믿습니다. 거기에 몇 테라바이트의 파일이 있으면 서버나 컴퓨터로 가져가서 다음을 사용하여 열 수 있습니다. 방법 그리고 지켜보세요. 또 다른 오류가 있습니다. 정력 로그를 보세요. 안좋으니까 절대 하지 마세요. Vim은 모든 것을 버퍼링하려고 하기 때문에 특히 이 로그를 탐색하고 무언가를 찾기 시작할 때 모든 것을 메모리에 로드하세요. 잊혀졌지만 고려해 볼 가치가 있는 것들입니다.

하나의 프로세서가 있는 하나의 컴퓨터에서 실행되는 하나의 프로그램을 작성하는 것이 더 쉽습니다.

시스템이 성장하면 모든 것을 병렬화하고 컴퓨터뿐만 아니라 클러스터에서도 병렬화하려고 합니다. 문제가 발생합니다. 이 문제를 어떻게 조정합니까? 우리 애플리케이션은 서로 상호 작용하지 않을 수도 있지만 여러 서버에서 여러 프로세스를 병렬로 실행했습니다. 그리고 모든 일이 잘 진행되고 있는지 모니터링하는 방법은 무엇입니까? 예를 들어, 인터넷을 통해 무언가를 보냅니다. 예를 들어 일종의 데이터베이스나 로그 등 어딘가에 자신의 상태에 대해 기록한 다음 이 로그를 집계하고 어딘가에서 분석해야 합니다. 또한 프로세스가 작동하고 작동 중인지, 갑자기 오류가 발생했거나 충돌이 발생했는지 고려해야 합니다. 그러면 해당 프로세스를 얼마나 빨리 알 수 있습니까?

이 모든 것을 신속하게 모니터링할 수 있다는 것은 분명합니다. 이것도 좋지만 모니터링은 최고 수준에서 일부 항목을 모니터링할 수 있는 제한적인 것입니다.

예를 들어 서로에게 일부 데이터를 전송하기 위해 프로세스가 서로 상호 작용하기 시작하려면 질문도 발생합니다. 어떻게 이런 일이 발생합니까? 어떤 종류의 경쟁 조건이 발생합니까? 서로 덮어쓰게 됩니까? 데이터가 올바르게 도착합니까? 도중에 손실되는 것이 있습니까? 일종의 프로토콜 등을 개발해야 합니다.

이러한 모든 프로세스를 조정하는 것은 사소한 일이 아닙니다. 그리고 이는 개발자가 더 낮은 수준으로 내려가 처음부터 시스템을 작성하거나 처음부터 작성하지 않도록 강요하지만 이는 그렇게 간단하지 않습니다.

암호화 알고리즘을 생각해내거나 심지어 구현하더라도 효과가 없을 가능성이 높으므로 즉시 폐기하십시오. 여기에는 제공하는 것을 잊어버린 많은 오류가 포함되어 있을 가능성이 높습니다. 불안정할 가능성이 높으므로 심각한 용도로 사용하지 마십시오. 존재하는 모든 알고리즘은 매우 오랜 시간 동안 테스트를 거쳤기 때문입니다. 커뮤니티에 의해 도청되었습니다. 이것은 별도의 주제입니다. 그리고 여기도 마찬가지입니다. 어떤 종류의 프로세스 동기화를 직접 구현하지 않는 것이 가능하다면 이를 수행하지 않는 것이 좋습니다. 왜냐하면 이는 매우 복잡하고 지속적으로 오류를 검색하는 불안정한 경로로 이어지기 때문입니다.

오늘은 ZooKeeper에 대해 이야기하겠습니다. 한편으로는 프레임워크이고, 다른 한편으로는 개발자의 삶을 더 쉽게 만들고 프로세스의 논리 구현과 조정을 최대한 단순화하는 서비스입니다.

표준 분산 시스템이 어떤 모습일지 기억해 봅시다. 이것이 우리가 이야기한 것입니다 - HDFS, HBase. 워커와 슬레이브 프로세스를 관리하는 마스터 프로세스가 있습니다. 그는 작업 조정 및 분산, 작업자 다시 시작, 새 작업자 시작 및 로드 분산을 담당합니다.

더 발전된 기능은 조정 서비스입니다. 즉, 조정 작업 자체를 별도의 프로세스로 이동하고 마스터가 실패할 수 있으므로 일종의 백업 또는 대기 마스터를 병렬로 실행합니다. 그리고 마스터가 쓰러지면 우리 시스템이 작동하지 않습니다. 백업을 실행 중입니다. 일부에서는 마스터를 백업에 복제해야 한다고 말합니다. 이는 조정 서비스에 위탁될 수도 있습니다. 하지만 이 다이어그램에서는 마스터 자신이 작업자 조정을 담당하며, 여기서는 서비스가 데이터 복제 활동을 조정합니다.

보다 고급 옵션은 일반적으로 수행되는 것처럼 모든 조정이 당사 서비스에서 처리되는 경우입니다. 그는 모든 것이 제대로 작동하는지 확인하는 책임을 집니다. 그리고 뭔가가 작동하지 않으면 우리는 그것에 대해 알아내고 이 상황을 피하려고 노력합니다. 어쨌든 우리에게는 슬레이브와 상호 작용하고 일부 서비스를 통해 데이터, 정보, 메시지 등을 보낼 수 있는 마스터가 남아 있습니다.

마스터가 없을 때 모든 노드는 동작이 다른 마스터 슬레이브가 됩니다. 하지만 여전히 서로 상호 작용해야 하므로 이러한 작업을 조정하기 위한 서비스가 아직 남아 있습니다. 아마도 이 원칙에 따라 작동하는 Cassandra가 이 계획에 적합할 것입니다.

이들 계획 중 어느 것이 더 효과적인지 말하기는 어렵습니다. 각각에는 장단점이 있습니다.

그리고 스승과 관련하여 어떤 것을 두려워할 필요가 없습니다. 왜냐하면 실습에서 알 수 있듯이 그는 지속적으로 봉사하는 데 그다지 민감하지 않기 때문입니다. 여기서 가장 중요한 것은 별도의 강력한 노드에서 이 서비스를 호스팅하기 위한 올바른 솔루션을 선택하여 충분한 리소스를 확보하여 가능하면 사용자가 해당 노드에 액세스하지 못하도록 하여 실수로 이 프로세스를 종료하지 않도록 하는 것입니다. 그러나 동시에 이러한 체계에서는 마스터 프로세스에서 작업자를 관리하는 것이 훨씬 쉽습니다. 즉, 구현 측면에서 이 체계가 더 간단합니다.

그리고 이 계획(위)은 아마도 더 복잡하지만 더 안정적일 것입니다.

가장 큰 문제는 부분적인 실패입니다. 예를 들어 우리가 네트워크를 통해 메시지를 보낼 때 어떤 사고가 발생하면 메시지를 보낸 사람은 자신의 메시지가 수신되었는지, 수신자 측에서는 무슨 일이 일어났는지 알 수 없으며 메시지가 올바르게 처리되었는지 알 수 없습니다. 즉, 그는 어떠한 확인도 받지 못할 것입니다.

따라서 우리는 이 상황을 처리해야 합니다. 가장 간단한 방법은 이 메시지를 다시 보내고 응답을 받을 때까지 기다리는 것입니다. 이 경우 수신자의 상태가 변경되었는지 여부는 고려되지 않습니다. 메시지를 보내고 동일한 데이터를 두 번 추가할 수 있습니다.

ZooKeeper는 그러한 거부에 대처할 수 있는 방법을 제공하여 우리의 삶을 더 쉽게 만듭니다.

앞서 언급했듯이 이는 다중 스레드 프로그램을 작성하는 것과 유사하지만 주요 차이점은 서로 다른 시스템에 구축하는 분산 애플리케이션에서 통신할 수 있는 유일한 방법은 네트워크라는 것입니다. 본질적으로 이는 비공유 아키텍처입니다. 한 머신에서 실행되는 각 프로세스나 서비스는 누구와도 공유하지 않는 자체 메모리, 디스크, 프로세서를 가지고 있습니다.

한 컴퓨터에서 다중 스레드 프로그램을 작성하면 공유 메모리를 사용하여 데이터를 교환할 수 있습니다. 거기에 컨텍스트 스위치가 있고 프로세스가 전환될 수 있습니다. 이는 성능에 영향을 미칩니다. 한편으로는 클러스터의 프로그램에는 그런 것이 없지만 네트워크에 문제가 있습니다.

따라서 분산 시스템을 작성할 때 발생하는 주요 문제는 구성입니다. 우리는 일종의 신청서를 작성하고 있습니다. 간단하다면 코드에 모든 종류의 숫자를 하드코딩하지만 이는 불편합니다. 왜냐하면 0.5초의 시간 초과 대신 1초의 시간 초과를 원한다고 결정하면 애플리케이션을 다시 컴파일하고 모든 것을 다시 펼치십시오. 하나의 머신에 있을 때는 다시 시작하면 문제가 되지만, 머신이 많으면 모든 것을 지속적으로 복사해야 합니다. 우리는 애플리케이션을 구성 가능하게 만들려고 노력해야 합니다.

여기서는 시스템 프로세스의 정적 구성에 대해 설명합니다. 이는 전적으로는 아니지만 운영 체제 관점에서 볼 때 프로세스에 대한 정적 구성일 수 있습니다. 즉, 간단히 취하고 업데이트할 수 없는 구성일 수 있습니다.

동적 구성도 있습니다. 이것들은 우리가 거기에서 선택되도록 즉석에서 변경하려는 매개변수입니다.

여기서 문제가 무엇입니까? 구성을 업데이트하고 출시했는데 그럼 어떻게 될까요? 문제는 우리가 구성을 롤아웃했지만 새로운 사항을 잊어버렸기 때문에 구성이 그대로 남아 있다는 점일 수 있습니다. 둘째, 출시하는 동안 일부 위치에서는 구성이 업데이트되었지만 다른 위치에서는 업데이트되지 않았습니다. 그리고 한 시스템에서 실행되는 애플리케이션의 일부 프로세스가 새로운 구성과 이전 구성으로 다시 시작되었습니다. 이로 인해 구성 관점에서 분산 애플리케이션이 일관되지 않을 수 있습니다. 이 문제는 일반적입니다. 동적 구성의 경우 즉시 변경될 수 있다는 점을 의미하므로 더 관련성이 높습니다.

또 다른 문제는 그룹 멤버십입니다. 우리는 항상 몇몇 워커 세트를 가지고 있으며, 우리는 항상 그들 중 누가 살아 있고, 누가 죽었는지 알고 싶어합니다. 마스터가 있는 경우 계산을 실행하거나 데이터 작업을 수행할 수 있도록 클라이언트로 리디렉션할 수 있는 작업자와 그렇지 않은 작업자를 이해해야 합니다. 지속적으로 발생하는 문제는 클러스터에서 누가 일하고 있는지 알아야 한다는 것입니다.

또 다른 전형적인 문제는 누가 책임자인지 알고 싶을 때 리더 선출입니다. 한 가지 예는 쓰기 작업을 수신한 다음 이를 다른 프로세스에 복제하는 일부 프로세스가 있는 복제입니다. 그는 지도자가 될 것이고, 다른 모든 사람들은 그에게 복종하고 그를 따를 것입니다. 두 명의 리더가 선출되는 일이 발생하지 않도록 모든 사람이 모호하지 않도록 프로세스를 선택해야 합니다.

상호 배타적인 액세스도 있습니다. 여기서 문제는 더 복잡합니다. 다중 스레드 프로그램을 작성하고 일부 리소스(예: 메모리 셀)에 대한 액세스를 제한하고 하나의 스레드에서만 수행하려는 경우 뮤텍스와 같은 것이 있습니다. 여기서 리소스는 좀 더 추상적인 것일 수 있습니다. 그리고 네트워크의 여러 노드에 있는 다양한 애플리케이션은 특정 리소스에 대한 독점적인 액세스 권한만 받아야 하며, 모든 사람이 리소스를 변경하거나 거기에 무언가를 쓸 수 있도록 해서는 안 됩니다. 이것은 소위 자물쇠입니다.

ZooKeeper를 사용하면 이러한 모든 문제를 어느 정도 해결할 수 있습니다. 그리고 이를 통해 어떻게 이를 수행할 수 있는지 예를 통해 보여 드리겠습니다.

차단 프리미티브가 없습니다. 우리가 무언가를 사용하기 시작하면 이 프리미티브는 어떤 이벤트가 발생할 때까지 기다리지 않습니다. 아마도 이 작업은 비동기식으로 작동하므로 프로세스가 무언가를 기다리는 동안 중단되지 않도록 할 수 있습니다. 이것은 매우 유용한 것입니다.

모든 클라이언트 요청은 일반 대기열의 순서대로 처리됩니다.

그리고 클라이언트는 변경된 데이터를 직접 보기 전에 일부 상태의 변경 사항, 데이터 변경 사항에 대한 알림을 받을 수 있습니다.

ZooKeeper는 두 가지 모드로 작동할 수 있습니다. 첫 번째는 하나의 노드에서 독립 실행형입니다. 이는 테스트에 편리합니다. 또한 원하는 수의 서버에서 클러스터 모드로 작동할 수도 있습니다. 100개의 시스템으로 구성된 클러스터가 있는 경우 100개의 시스템에서 작동할 필요는 없습니다. ZooKeeper를 실행할 수 있는 여러 머신을 선택하는 것으로 충분합니다. 그리고 고가용성의 원칙을 공언합니다. 실행 중인 각 인스턴스에서 ZooKeeper는 데이터의 전체 복사본을 저장합니다. 나중에 그가 어떻게 하는지 알려드리겠습니다. 데이터를 분할하거나 분할하지 않습니다. 한편으로는 많이 저장할 수 없다는 점은 마이너스이고, 다른 한편으로는 그렇게 할 필요가 없다는 점입니다. 그것은 데이터베이스가 아니기 위해 설계된 것이 아닙니다.

데이터는 클라이언트 측에서 캐시될 수 있습니다. 이는 서비스를 중단하지 않고 동일한 요청으로 로드하지 않기 위한 표준 원칙입니다. 스마트 클라이언트는 일반적으로 이에 대해 알고 캐시합니다.

예를 들어, 여기에서 뭔가가 변경되었습니다. 어떤 종류의 응용 프로그램이 있습니다. 예를 들어 쓰기 작업 처리를 담당하는 새로운 리더가 선출되었습니다. 그리고 우리는 데이터를 복제하고 싶습니다. 한 가지 해결책은 루프에 넣는 것입니다. 그리고 우리는 서비스에 대해 끊임없이 질문합니다. 변경된 사항이 있나요? 두 번째 옵션이 더 최적입니다. 이는 클라이언트에게 무언가 변경되었음을 알릴 수 있는 감시 메커니즘입니다. 이는 리소스 측면에서 비용이 덜 들고 고객에게 더 편리한 방법입니다.

클라이언트는 ZooKeeper를 사용하는 사용자입니다.

서버는 ZooKeeper 프로세스 자체입니다.

Znode는 ZooKeeper의 핵심입니다. 모든 znode는 ZooKeeper에 의해 메모리에 저장되며 트리 형태의 계층 다이어그램 형태로 구성됩니다.

작업에는 두 가지 유형이 있습니다. 첫 번째는 일부 작업이 트리의 상태를 변경하는 업데이트/쓰기입니다. 나무는 흔합니다.

그리고 클라이언트가 하나의 요청을 완료하지 못하고 연결이 끊어졌을 수도 있지만 ZooKeeper와 상호 작용하는 세션을 설정할 수 있습니다.

ZooKeeper의 데이터 모델은 파일 시스템과 유사합니다. 표준 루트가 있고 루트에서 나오는 디렉토리를 통과하는 것처럼 진행했습니다. 그리고 첫 번째 수준의 카탈로그, 두 번째 수준의 카탈로그입니다. 이것은 모두 znode입니다.

각 znode는 일반적으로 10KB와 같이 그리 크지 않은 일부 데이터를 저장할 수 있습니다. 그리고 각 znode는 특정 수의 자식을 가질 수 있습니다.

Znode는 여러 유형으로 제공됩니다. 생성될 수 있습니다. 그리고 znode를 생성할 때 그것이 속해야 하는 유형을 지정합니다.

두 가지 유형이 있습니다. 첫 번째는 임시 플래그입니다. Znode는 세션 내에 있습니다. 예를 들어 클라이언트가 세션을 설정했습니다. 그리고 이 세션이 살아있는 한 계속 존재할 것입니다. 이는 불필요한 것을 생산하지 않기 위해 필요합니다. 이는 세션 내에 데이터 기본 요소를 저장하는 것이 중요한 순간에도 적합합니다.

두 번째 유형은 순차 플래그입니다. znode로 가는 동안 카운터를 증가시킵니다. 예를 들어, 애플리케이션 1_5가 포함된 디렉토리가 있습니다. 그리고 첫 번째 노드를 생성했을 때 p_1을 받았고 두 번째 노드는 p_2를 받았습니다. 그리고 매번 이 메소드를 호출할 때 경로의 일부만 나타내는 전체 경로를 전달하며, 노드 유형(순차)을 나타내기 때문에 이 숫자는 자동으로 증가됩니다.

일반 znode. 그녀는 항상 살 것이며 우리가 말하는 이름을 갖게 될 것입니다.

또 다른 유용한 점은 감시 플래그입니다. 이를 설치하면 클라이언트는 특정 노드에 대한 일부 이벤트를 구독할 수 있습니다. 나중에 이 작업이 어떻게 이루어지는지 예시를 통해 보여드리겠습니다. ZooKeeper 자체는 노드의 데이터가 변경되었음을 클라이언트에 알립니다. 그러나 알림이 일부 새로운 데이터의 도착을 보장하지는 않습니다. 그들은 단지 뭔가가 변경되었다고만 말하므로 나중에 별도의 호출을 통해 데이터를 비교해야 합니다.

그리고 이미 말했듯이 데이터의 순서는 킬로바이트 단위로 결정됩니다. 데이터베이스가 아니고 행동 조정 서버이기 때문에 대용량 텍스트 데이터를 저장할 필요가 없습니다.

세션에 대해 조금 말씀 드리겠습니다. 서버가 여러 개인 경우 세션 식별자를 사용하여 서버에서 서버로 투명하게 이동할 수 있습니다. 꽤 편리합니다.

각 세션에는 일종의 시간 초과가 있습니다. 세션은 클라이언트가 해당 세션 중에 서버에 무엇인가를 보내는지 여부에 따라 정의됩니다. 시간 초과 동안 아무 것도 전송하지 않으면 세션이 중단되거나 클라이언트가 직접 세션을 닫을 수 있습니다.

기능이 많지는 않지만 이 API를 사용하면 다양한 작업을 수행할 수 있습니다. 우리가 본 create 호출은 znode를 생성하고 세 개의 매개변수를 취합니다. 이는 znode에 대한 경로이며 루트에서 전체를 지정해야 합니다. 그리고 이것은 우리가 거기로 전송하고 싶은 일부 데이터입니다. 그리고 깃발의 종류. 그리고 생성 후에는 znode에 대한 경로를 반환합니다.

둘째, 삭제할 수 있습니다. 여기서 중요한 점은 znode 경로 외에 두 번째 매개변수로 버전을 지정할 수 있다는 것입니다. 따라서 우리가 전송한 버전이 실제로 존재하는 버전과 동일하면 해당 znode가 삭제됩니다.

이 버전을 확인하고 싶지 않다면 간단히 "-1" 인수를 전달하면 됩니다.

셋째, znode가 있는지 확인합니다. 노드가 존재하면 true를 반환하고 그렇지 않으면 false를 반환합니다.

그러면 이 노드를 모니터링할 수 있는 플래그 감시가 나타납니다.

존재하지 않는 노드에도 이 플래그를 설정하고 노드가 나타날 때 알림을 받을 수 있습니다. 이것은 또한 유용할 수 있습니다.

몇 가지 추가 과제는 다음과 같습니다. 데이터 가져오기. znode를 통해 데이터를 수신할 수 있다는 것은 분명합니다. 깃발 감시를 사용할 수도 있습니다. 이 경우 노드가 없으면 설치되지 않습니다. 그러므로 존재한다는 것을 이해한 후 데이터를 받아야 합니다.

도 있습니다 데이터 설정. 여기서는 버전을 전달합니다. 그리고 이를 전달하면 특정 버전의 znode에 있는 데이터가 업데이트됩니다.

이 검사를 제외하려면 "-1"을 지정할 수도 있습니다.

또 다른 유용한 방법은 getChildren. 또한 여기에 속한 모든 znode의 목록을 얻을 수도 있습니다. 플래그 감시를 설정하여 이를 모니터링할 수 있습니다.

그리고 방법 동기화 모든 변경 사항을 한 번에 전송할 수 있으므로 변경 내용이 저장되고 모든 데이터가 완전히 변경되었는지 확인할 수 있습니다.

일반적인 프로그래밍으로 비유하자면 디스크에 무언가를 쓰는 write와 같은 메서드를 사용할 때 응답이 반환된 후에는 데이터를 디스크에 썼다는 보장이 없습니다. 운영 체제가 모든 것이 기록되었다고 확신하는 경우에도 디스크 자체에는 프로세스가 버퍼 계층을 통과하고 그 후에만 데이터가 디스크에 배치되는 메커니즘이 있습니다.

대부분 비동기 호출이 사용됩니다. 이를 통해 클라이언트는 다양한 요청을 동시에 처리할 수 있습니다. 동기식 접근 방식을 사용할 수 있지만 생산성이 떨어집니다.

우리가 이야기한 두 가지 작업은 데이터를 변경하는 업데이트/쓰기입니다. 여기에는 생성, setData, 동기화, 삭제가 있습니다. 그리고 읽기가 존재합니다, getData, getChildren.

이제 분산 시스템에서 작업하기 위한 기본 요소를 만드는 방법에 대한 몇 가지 예를 살펴보겠습니다. 예를 들어, 무언가의 구성과 관련됩니다. 새로운 일꾼이 나타났습니다. 기계를 추가하고 프로세스를 시작했습니다. 그리고 다음 세 가지 질문이 있습니다. ZooKeeper에 구성을 어떻게 쿼리하나요? 구성을 변경하려면 어떻게 변경해야 합니까? 그리고 우리가 그것을 바꾼 후에 우리가 가지고 있던 노동자들은 그것을 어떻게 얻습니까?

ZooKeeper를 사용하면 이 작업이 비교적 쉽습니다. 예를 들어, znode 트리가 있습니다. 여기에는 애플리케이션을 위한 노드가 있으며, 여기에 구성의 데이터가 포함된 추가 노드를 만듭니다. 이는 별도의 매개변수일 수도 있고 아닐 수도 있습니다. 크기가 작기 때문에 구성 크기도 일반적으로 작으므로 여기에 보관하는 것이 가능합니다.

방법을 사용하고 계십니다. 데이터 가져오기 노드에서 작업자에 대한 구성을 가져옵니다. 참으로 설정하세요. 어떤 이유로 이 노드가 존재하지 않는 경우 노드가 나타나거나 변경될 때 이에 대해 알려드리겠습니다. 뭔가가 변경되었는지 알고 싶다면 이를 true로 설정합니다. 그리고 이 노드의 데이터가 변경되면 우리는 이에 대해 알게 됩니다.

데이터 설정. 데이터를 설정하고 "-1"을 설정합니다. 즉, 버전을 확인하지 않고 항상 하나의 구성이 있다고 가정하므로 많은 구성을 저장할 필요가 없습니다. 많이 저장해야 한다면 다른 레벨을 추가해야 합니다. 여기서는 하나만 있다고 판단하여 최신 버전만 업데이트하므로 버전은 확인하지 않습니다. 이 순간, 이전에 구독한 모든 클라이언트는 이 노드에서 변경된 사항이 있다는 알림을 받습니다. 그리고 데이터를 받은 후에는 데이터를 다시 요청해야 합니다. 알림은 데이터 자체를 수신하지 않고 변경 사항에 대한 알림만 수신한다는 것입니다. 그 후에는 새로운 데이터를 요청해야 합니다.

기본 요소를 사용하는 두 번째 옵션은 다음과 같습니다. 그룹 멤버십. 우리는 분산된 애플리케이션을 가지고 있고 많은 워커가 있으며 우리는 그들이 모두 제자리에 있다는 것을 이해하고 싶습니다. 따라서 그들은 우리 애플리케이션에 자신이 일하고 있음을 등록해야 합니다. 또한 우리는 마스터 프로세스나 다른 곳에서 현재 보유하고 있는 모든 활성 작업자에 대해 알아보고 싶습니다.

어떻게 해야 할까요? 애플리케이션의 경우 작업자 노드를 생성하고 create 메서드를 사용하여 거기에 하위 레벨을 추가합니다. 슬라이드에 오류가 있습니다. 여기 당신이 필요합니다 잇달아 일어나는 지정하면 모든 작업자가 하나씩 생성됩니다. 그리고 이 노드의 하위 항목에 대한 모든 데이터를 요청하는 애플리케이션은 존재하는 모든 활성 작업자를 수신합니다.

이것은 Java 코드에서 이것이 어떻게 수행될 수 있는지에 대한 끔찍한 구현입니다. main 메소드부터 끝부터 시작해 보겠습니다. 이것은 우리 클래스입니다. 해당 클래스의 메서드를 만들어 보겠습니다. 첫 번째 인수로 연결하는 호스트를 사용합니다. 즉, 이를 인수로 설정합니다. 두 번째 인수는 그룹의 이름입니다.

연결은 어떻게 되나요? 이는 사용되는 API의 간단한 예입니다. 여기에서는 모든 것이 비교적 간단합니다. 표준 클래스 ZooKeeper가 있습니다. 우리는 그것에 호스트를 전달합니다. 예를 들어 시간 초과를 5초로 설정합니다. 그리고 connectSignal이라는 멤버가 있습니다. 기본적으로 전송 경로를 따라 그룹을 만듭니다. 무언가가 기록될 수 있지만 우리는 거기에 데이터를 쓰지 않습니다. 그리고 여기의 노드는 영구 유형입니다. 본질적으로 이것은 항상 존재하는 일반적인 일반 노드입니다. 세션이 생성되는 곳입니다. 이는 클라이언트 자체의 구현입니다. 클라이언트는 세션이 살아 있음을 나타내는 정기적인 메시지를 보냅니다. 그리고 세션이 종료되면 close를 호출하면 세션이 종료됩니다. 이는 문제가 발생하여 ZooKeeper가 이를 발견하고 세션을 중단할 경우를 대비한 것입니다.

리소스를 잠그는 방법은 무엇입니까? 여기서는 모든 것이 조금 더 복잡합니다. 워커 세트가 있고 잠그고 싶은 리소스가 있습니다. 이를 위해 lock1이라는 별도의 노드를 만듭니다. 우리가 그것을 만들 수 있었다면 여기에 자물쇠가 있는 것입니다. 생성할 수 없는 경우 작업자는 여기에서 getData를 가져오려고 시도하며 노드가 이미 생성되었으므로 여기에 감시자를 배치하고 이 노드의 상태가 변경되는 순간 이를 알게 됩니다. 그리고 우리는 그것을 재현할 시간을 갖도록 노력할 수 있습니다. 이 노드를 가져오고 이 잠금을 가져간 다음 더 이상 잠금이 필요하지 않으면 노드가 세션 내에만 존재하므로 이를 포기합니다. 따라서 사라질 것입니다. 그리고 다른 세션의 프레임워크 내에서 다른 클라이언트가 이 노드에 대한 잠금을 수행할 수 있습니다. 또는 오히려 그는 무언가 변경되었다는 알림을 받고 시간 내에 잠금을 시도할 수 있습니다.

주요 리더를 선택하는 방법에 대한 또 다른 예입니다. 이는 조금 더 복잡하지만 상대적으로 간단합니다. 여기서 무슨 일이 일어나고 있는 걸까요? 모든 작업자를 집계하는 기본 노드가 있습니다. 우리는 리더에 대한 데이터를 얻으려고 노력하고 있습니다. 이 작업이 성공적으로 수행되면, 즉 일부 데이터를 수신하면 작업자가 이 리더를 따르기 시작합니다. 그는 이미 지도자가 있다고 믿습니다.

예를 들어, 리더가 어떤 이유로 사망한 경우 새로운 리더를 만들려고 합니다. 그리고 우리가 성공하면 우리 직원이 리더가 됩니다. 그리고 지금 누군가가 새로운 리더를 만들었다면 우리는 그것이 누구인지 이해하고 그를 따르려고 노력합니다.

여기서 소위 무리 효과, 즉 무리 효과가 발생합니다. 왜냐하면 리더가 죽으면 시간상 첫 번째 사람이 리더가 되기 때문입니다.

리소스를 캡처할 때 다음과 같이 약간 다른 접근 방식을 사용해 볼 수 있습니다. 예를 들어, 우리는 자물쇠를 얻고 싶지만 Hert 효과는 없습니다. 이는 우리 애플리케이션이 잠금이 있는 기존 노드에 대한 모든 노드 ID 목록을 요청한다는 사실로 구성됩니다. 그리고 그 전에 우리가 잠금을 생성한 노드가 우리가 받은 세트 중 가장 작다면 이는 우리가 잠금을 캡처했음을 의미합니다. 잠금을 받았는지 확인합니다. 확인 사항으로 새 잠금을 생성할 때 받은 ID가 최소라는 조건이 있습니다. 그리고 그것을 받으면 우리는 더 많은 일을 합니다.

잠금보다 작은 특정 ID가 있으면 이 이벤트에 감시자를 배치하고 무언가 변경될 때까지 알림을 기다립니다. 즉, 우리는 이 잠금을 받았습니다. 그리고 떨어지기 전까지는 최소 아이디가 되지 않고, 최소 잠금도 받지 못하므로 로그인이 가능해집니다. 그리고 이 조건이 충족되지 않으면 즉시 여기로 가서 이 잠금을 다시 얻으려고 시도합니다. 왜냐하면 이 시간 동안 뭔가 변경되었을 수 있기 때문입니다.

ZooKeeper는 무엇으로 구성되어 있나요? 크게 4가지가 있습니다. 처리과정 - 요청입니다. 또한 ZooKeeper Atomic Broadcast도 있습니다. 모든 작업이 기록되는 커밋 로그가 있습니다. 그리고 In-memory Replicated DB 자체, 즉 이 전체 트리가 저장되는 데이터베이스 자체입니다.

모든 쓰기 작업이 요청 프로세서를 통과한다는 점은 주목할 가치가 있습니다. 그리고 읽기 작업은 인메모리 데이터베이스로 직접 이동됩니다.

데이터베이스 자체가 완전히 복제됩니다. ZooKeeper의 모든 인스턴스는 데이터의 전체 복사본을 저장합니다.

충돌 후 데이터베이스를 복원하기 위해 커밋 로그가 있습니다. 표준 관행은 데이터가 메모리에 저장되기 전에 메모리에 기록되어 충돌이 발생할 경우 이 로그를 재생하고 시스템 상태를 복원할 수 있다는 것입니다. 그리고 데이터베이스의 주기적인 스냅샷도 사용됩니다.

ZooKeeper Atomic Broadcast는 복제된 데이터를 유지하는 데 사용되는 것입니다.

ZAB는 ZooKeeper 노드의 관점에서 내부적으로 리더를 선택합니다. 다른 노드는 그녀의 추종자가 되어 그녀로부터 어떤 행동을 기대합니다. 항목을 받으면 모두 리더에게 전달합니다. 그는 먼저 쓰기 작업을 수행한 다음 변경된 내용에 대한 메시지를 추종자에게 보냅니다. 이는 실제로 원자적으로 수행되어야 합니다. 즉, 전체의 녹음 및 방송 작업이 원자적으로 수행되어야 데이터 일관성이 보장됩니다.

쓰기 요청만 처리합니다. 주요 임무는 작업을 트랜잭션 업데이트로 변환하는 것입니다. 이것은 특별히 생성된 요청입니다.

그리고 여기서는 동일한 작업에 대한 업데이트의 멱등성이 보장된다는 점에 주목할 가치가 있습니다. 그것은 무엇입니까? 이 작업이 두 번 실행되면 동일한 상태를 갖게 됩니다. 즉, 요청 자체는 변경되지 않습니다. 그리고 충돌이 발생한 경우 작업을 다시 시작하여 현재 떨어진 변경 사항을 롤백할 수 있도록 이 작업을 수행해야 합니다. 이 경우 시스템 상태는 동일해집니다. 즉, 일련의 동일한 작업(예: 업데이트 프로세스)으로 인해 시스템의 최종 상태가 달라지는 경우가 있어서는 안 됩니다.

출처 : habr.com