Apache ZooKeeper 설명


376

ZooKeeper, 작동 방식 및 작동 방식을 이해하려고합니다. ZooKeeper와 비슷한 응용 프로그램이 있습니까?

아는 경우 ZooKeeper를 평신도에게 어떻게 설명 하시겠습니까?

나는 아파치 위키, 동물원 사육사 sourceforge를 시도했지만 여전히 관련이 없다.

http://zookeeper.sourceforge.net/index.sf.shtml 통해 읽었 으므로 이와 같은 서비스가 더 없습니까? 서버 서비스를 복제하는 것만 큼 간단합니까?


6
유사하지만 당신이 찾고있는 정확한 답 : stackoverflow.com/questions/1479442/real-world-use-of-zookeeper
zengr


이 문서를 읽을 수 있습니다. ZooKeeper : 인터넷 규모 시스템을위한 대기없는 조정 2 개의 Yahoo! 엔지니어
yaphet

다음은 RentTheRunway의 CTO 인 Camille Fournier의 Apache ZooKeeper소개 하는 기술 강연입니다 . 도움이 되길 바랍니다.
Genadinik

@Luca Geretti ... 나를 위해 Zookeper는 API를 사용하여 분산 응용 프로그램을 조정할 수 있습니다. 내가 틀렸다면 나를 바로 잡으십시오.
user3797438

답변:


434

간단히 말해 ZooKeeper는 분산 응용 프로그램을 구축 할 수 있도록 도와줍니다.

작동 원리

ZooKeeper를 최종 일관성이있는 복제 된 동기화 서비스로 설명 할 수 있습니다. 지속 된 데이터가 여러 노드 (이 노드 집합을 "앙상블"이라고 함)간에 분산하고 한 클라이언트가 어떤 노드 (예 : 특정 "서버")에 연결하여 한 노드에 장애가 발생하면 마이그레이션하기 때문에 강력합니다. 대부분의 노드가 작동하는 한 ZooKeeper 노드의 앙상블이 살아 있습니다. 특히, 마스터 노드는 앙상블 내에서 합의에 의해 동적으로 선택됩니다. 마스터 노드가 실패하면 마스터 역할이 다른 노드로 마이그레이션됩니다.

쓰기 처리 방법

마스터는 쓰기 권한입니다. 이러한 방식으로 쓰기가 순서대로 유지되도록 보장 할 수 있습니다 (즉, 쓰기는 선형) . 클라이언트가 앙상블에 쓸 때마다 대부분의 노드가 정보를 유지합니다.이 노드에는 클라이언트 용 서버와 분명히 마스터가 포함됩니다. 이것은 각각의 쓰기가 마스터와 함께 서버를 최신 상태로 만든다는 것을 의미합니다. 그러나 동시에 쓰기를 할 수 없다는 것을 의미합니다.

선형 쓰기가 보장되는 이유는 ZooKeeper가 쓰기 주도적 워크로드에서 제대로 수행되지 않기 때문입니다. 특히 미디어와 같은 대용량 데이터를 교환하는 데 사용해서는 안됩니다. 통신에 공유 데이터가 포함되어있는 한 ZooKeeper가 도와드립니다. 데이터를 동시에 쓸 수있는 경우, ZooKeeper는 실제로 작가의 관점에서 꼭 필요한 것은 아니지만 엄격한 순서로 작업을 수행하기 때문에 실제로 방해가됩니다. 클라이언트간에 메시지가 교환되는 조정에 이상적입니다.

읽기 처리 방법

이것은 ZooKeeper가 탁월한 곳입니다. 읽기는 클라이언트가 연결하는 특정 서버에서 제공되기 때문에 동시입니다. 그러나 이는 최종 일관성의 이유이기도합니다. 마스터는 제한이 있지만 정의되지 않은 지연으로 해당 서버를 업데이트하므로 클라이언트의 "보기"가 오래되었을 수 있습니다.

상세히

ZooKeeper의 복제 된 데이터베이스는 znodes 트리로 구성되며 파일 노드를 대략적으로 나타내는 엔티티입니다 (디렉토리라고 생각). 각 znode는 데이터를 저장하는 바이트 배열로 보강 될 수 있습니다. 또한 각 znode에는 다른 znode가있을 수 있으며 실제로 내부 디렉토리 시스템을 형성합니다.

순차적 znode

흥미롭게도 znode의 이름은 순차적 일 수 있습니다 . 즉 znode를 작성할 때 클라이언트가 제공하는 이름은 접두사 일뿐입니다. 전체 이름은 앙상블이 선택한 순차적 번호로도 제공됩니다. 예를 들어, 동기화 목적에 유용합니다. 여러 클라이언트가 자원에 대한 잠금을 얻으려는 경우 각 위치에서 동시에 순차적 znode를 작성할 수 있습니다. 가장 적은 수의 사람은 잠금을받을 수 있습니다.

임시 znodes

또한 znode는 일시적 일 수 있습니다 . 즉 , znode 를 작성한 클라이언트가 연결을 끊 자마자 소멸됩니다. 이는 클라이언트가 실패한시기를 알기 위해 주로 유용하며, 이는 클라이언트 자신에게 새 클라이언트가 수행해야 할 책임이있을 때 관련 될 수 있습니다. 잠금의 예를 들어, 잠금을 해제 한 클라이언트가 연결을 끊 자마자 다른 클라이언트는 잠금을 사용할 수 있는지 여부를 확인할 수 있습니다.

시계

znode의 상태를 주기적으로 폴링해야하는 경우 클라이언트 연결 끊기와 관련된 예가 문제가 될 수 있습니다. 다행스럽게도 ZooKeeper는 znode에서 시계 를 설정할 수 있는 이벤트 시스템을 제공합니다 . 이 시계는 znode가 특별히 변경되거나 제거되거나 그 아래에 새로운 자식이 만들어지면 이벤트를 트리거하도록 설정 될 수 있습니다. 이것은 znode에 대한 순차 및 임시 옵션과 함께 유용합니다.

사용 장소 및 방법

Zookeeper 사용법의 일반적인 예는 분산 메모리 계산으로, 일부 데이터는 클라이언트 노드간에 공유되며 동기화를 고려하여 매우 신중하게 액세스 / 업데이트해야합니다.

ZooKeeper는 동기화 프리미티브를 구성 할 수있는 라이브러리를 제공하는 반면 분산 서버를 실행하면 중앙 집중식 (브로커와 유사한) 메시지 저장소를 사용할 때 발생하는 단일 장애 지점 문제를 피할 수 있습니다.

주 키퍼 (ZooKeeper)는 특징이 가벼워 리더 선출, 자물쇠, 장벽 등의 메커니즘이 아직 존재하지 않지만 ZooKeeper 프리미티브 위에 작성할 수 있습니다. C / Java API가 목적에 맞지 않는 경우 케이지 및 특히 큐레이터 와 같이 ZooKeeper에 빌드 된 라이브러리를 사용해야합니다 .

더 읽어야 할 곳

꽤 좋은 공식 문서를 제외하고는 ZooKeeper가 수행하는 작업을 본질적으로 설명하는 ~ 35 페이지가 있고 구성 서비스의 예가 나와 있는 Hadoop : The Definitive Guide의 14 장을 읽는 것이 좋습니다 .


2
귀하가 제안하는 커뮤니케이션 체계를 이해하지는 못하지만 ZooKeeper를 사용하여 생산자의 정보를 "게시"하고 여러 소비자가 읽도록 할 수 있습니다. 반면에 각 서버 종류의 인스턴스가 하나만 존재하는 경우 ZK를 사용하면 이점이 거의 없습니다.
Luca Geretti

57
IMO 이것은 ZooKeeper가 평신도에게 어떤 것인지 설명하지 못합니다. ZooKeeper는 언제 필요합니까? 내가 무엇을 쓸까요? 어떤 문제가 해결됩니까? 키-값 저장소입니까? 검색 엔진? 분산 잠금? Redis 나 파일, JIRA 또는 포스트잇 메모보다 ZooKeeper를 선택하는 이유는 무엇입니까? ZooKeeper에 대해 많이 알고 있지만 기술적으로 덜 설명 할 수 있습니까?
Dan Passaro

1
Zookeeper에는 선형 쓰기가 있으므로 비동기 API를 사용하여 노드를 만들고 콜백에서 응답을 취하는 것을 멈추지 않습니다. 내부적으로 동시 쓰기를 허용하지 않을 수 있습니까, 아니면 뭔가 빠졌습니까?
jdk2588

1
"클라이언트가 앙상블에 쓸 때마다 대부분의 노드가 정보를 유지합니다.이 노드에는 클라이언트 용 서버와 분명히 마스터가 포함됩니다."=> 문서를 알려주세요. 또는 이것이 설명되는 곳? 클라이언트가 연결된 서버를 제외하고 상태가 성공적으로 변경 될 수 있는지 궁금합니다 (이 경우 클라이언트는 잠시 동안 자체 쓰기를 읽을 수없는 이상한 동작을 경험할 수 있음)
senseiwu

2
질문에 대한 완전하고 완전하게 반대되는 주장. 시계 인 경우, 요동주기, 관성 모멘트 및 인공 사파이어 크리스털의 영향에 따른 메인 스프링, 휠 트레인, 탈출 및 상호 작용에 대한 설명이 아닌 "시간 유지 장치"를 찾고있을 것입니다.
Rick O'Shea

10

Zookeeper는 분산 프로세스를 안정적으로 조정하는 데 도움이되는 최고의 오픈 소스 서버 및 서비스 중 하나입니다. Zookeeper는 일관성 및 파티션 허용 오차를 제공하는 CP 시스템 (CAP 정리 참조)입니다. 모든 노드에서 Zookeeper 상태를 복제하면 궁극적으로 일관된 분산 서비스가됩니다.

또한 추종자가 많은 제안이 누락 된 경우 새로 선출 된 모든 리더는 제안이 누락되거나 주 스냅 샷으로 추종자를 업데이트합니다.

Zookeeper는 사용하기 매우 쉬운 API도 제공합니다. 이 블로그 게시물 인 Zookeeper Java API 예제 에는 예제를 찾고있는 경우 몇 가지 예가 있습니다.

그래서 우리는 이것을 어디에 사용합니까? 분산 서비스에 중앙 집중식의 안정적이고 일관된 구성 관리, 잠금, 대기열 등이 필요한 경우 Zookeeper가 신뢰할 수있는 선택입니다.


4
"Zookeeper는 일관성 및 파티션 허용 오차를 제공하는 CP 시스템 (참조 CAP 정리)입니다."Zookeeper에는 마스터와 팔로워가 있으며 마스터 다운시 팔로워 중 하나가 리더로 선출되므로 Zookeeper는 그러나 AP는 결국 일관성이 있습니다.
YuFeng Shen

5
CAP 정리에서 "C"는 실제로 선형성을 의미합니다. ZooKeeper는 실제로 "순차 일관성"을 제공하며 이는 클라이언트의 업데이트가 수신 된 순서대로 적용됨을 의미합니다. 이는 선형성보다 약하지만 여전히 "최종 일관성"보다 훨씬 강력합니다. 주 키퍼는 A가 아니며 이는 리더를 선출 할 수없는 경우 (쿼럼 없음) 주 키퍼는 요청에 실패하기 때문입니다. 이것이 고 가용성이 아닌 이유입니다.
Binu George

7

나는 ZooKeeper는 일반적으로 이해하지만 "쿼럼"과 "분할 뇌"라는 용어에 문제가있어서 결과를 여러분과 공유 할 수있을 것입니다 (저도 평신도라고 생각합니다).

서버 5 대의 ZooKeeper 클러스터가 있다고 가정 해 봅시다. 서버 중 하나가 리더가되고 다른 서버가 추종자가됩니다.

  • 이 5 개의 서버는 쿼럼을 형성합니다. 쿼럼은 단순히 "이 서버는 누가 리더가되어야하는지 투표 할 수 있습니다"를 의미합니다.

  • 따라서 투표는 다수를 기준으로합니다. 대다수는 단순히 "반 이상"을 의미하므로 서버 수의 절반 이상이 특정 서버가 리더가되도록 동의해야합니다.

  • "분할 뇌"라고 불리는 이런 나쁜 일이 있습니다. 5 개의 서버 클러스터가 두 부분으로 나뉘거나 "서버 팀"이라고 부르겠습니다. 한 부분은 2 개, 다른 하나는 3 개입니다. 두 "서버 팀"이 특정 순서를 실행해야하는 것처럼 이것은 실제로 나쁜 상황입니다. 클라이언트로부터 다른 정보를 받았을 수 있습니다. 따라서 어떤 "서버 팀"이 여전히 관련이 있으며 어떤 서버를 무시해야하는지 아는 것이 매우 중요합니다.

  • 대다수는 홀수의 서버를 사용해야하는 이유이기도합니다. 4 대의 서버와 2 대의 서버가 분리 된 분리 된 두뇌가있는 경우 두 "서버 팀"은 "이봐, 누가 리더인지 결정하고 싶다"고 말할 수 있습니다. 그러나 어떤 2 ​​대의 서버를 선택해야하는지 어떻게 결정해야합니까? 서버가 5 개인 경우 간단합니다. 서버가 3 개인 서버 팀이 다수이며 새로운 리더를 선택할 수 있습니다.

  • 서버가 3 대인데도 그 중 하나가 실패하더라도 다른 2 대가 여전히 대다수를 차지하며 그 중 하나가 새로운 리더가 될 것에 동의 할 수 있습니다.

일단 당신이 그것에 대해 한 번 생각하고 더 이상 그렇게 복잡하지 않은 용어를 이해하면 깨닫습니다. 나는 이것이 또한이 용어를 이해하는 데 도움이되기를 바랍니다.


1

Zookeeper는 구성 정보 유지 관리 및 관리, 명명 규칙 및 분산 클러스터 환경 동기화를위한 중앙 집중식 오픈 소스 서버입니다. Zookeeper는 분산 시스템이 낮은 대기 시간과 고 가용성을 제공하여 관리 복잡성을 줄일 수 있도록 도와줍니다. Zookeeper는 처음에 Hadoop의 하위 프로젝트 였지만 이제는 Apache Software Foundation의 최상위 독립 프로젝트입니다.

추가 정보


2
동물원 사육사가 중앙 집중식이라고 말하는 것은 무엇입니까? 사육사는 배포 할 수 있으며 실행해야합니다.
Benjamin Hammer Nørgaard

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.