사육사는 Kafka의 필수품입니까?

Kafka에서는 단일 브로커, 단일 주제 및 하나의 생산자 및 여러 소비자 (각 소비자가 브로커에서 자체 데이터 사본을 가져옴)가있는 단일 파티션 만 사용하고 싶습니다. 이를 감안할 때 Zookeeper를 사용하는 오버 헤드를 원하지 않습니다. 브로커 만 사용할 수 있습니까? 동물원 사육사는 왜해야합니까?

예, Kafka를 실행하려면 Zookeeper가 필요합니다. Kafka 시작하기 문서에서 :

2 단계 : 서버 시작

Kafka는 Zookeeper를 사용하므로 Zookeeper 서버가없는 경우 먼저 Zookeeper 서버를 시작해야합니다. kafka와 함께 패키지 된 간이 스크립트를 사용하여 빠르고 더러운 단일 노드 사육사 인스턴스를 얻을 수 있습니다.

왜 오래 전부터 사람들은 분산 시스템에서 작업, 상태 관리, 구성 등을 조정하는 방법이 필요하다는 것을 알게되었습니다. 일부 프로젝트는 자체 메커니즘을 구축했습니다 (MongoDB 샤딩 클러스터의 구성 서버 또는 Elasticsearch 클러스터의 마스터 노드). 다른 이들은 Zookeeper를 범용 분산 프로세스 조정 시스템으로 활용하기로 선택했습니다. 따라서 Kafka, Storm, HBase, SolrCloud는 Zookeeper를 사용하여 관리하고 조정하는 데 도움을주는 몇 가지를 모두 지정합니다.

Kafka는 분산 시스템이며 Zookeeper를 사용하도록 구축되었습니다. Kafka의 분산 기능을 사용하지 않는다는 사실은 빌드 방법을 변경하지 않습니다. 어쨌든 Zookeeper를 사용하면 오버 헤드가 많지 않아야합니다. 더 큰 문제는이 특정 디자인 패턴을 사용하는 이유입니다. Kafka의 단일 브로커 구현은 멀티 브로커 클러스터의 모든 신뢰성 기능과 확장 기능을 놓치게됩니다.

다른 사람들이 설명했듯이 Kafka (가장 최신 버전에서도)는 Zookeeper 없이는 작동하지 않습니다.

Kafka는 다음을 위해 Zookeeper를 사용합니다.

컨트롤러 선출 . 컨트롤러는 브로커 중 하나이며 모든 파티션에 대한 리더 / 팔로어 관계를 유지 관리합니다. 노드가 종료되면 컨트롤러는 다른 복제본이 파티션 리더가되도록하여 사라지는 노드의 파티션 리더를 교체하도록 지시합니다. Zookeeper는 컨트롤러를 선택하고, 단 하나만 있는지 확인하고 충돌하는 경우 새 컨트롤러를 선택하는 데 사용됩니다.

클러스터 멤버쉽 -어떤 브로커가 살아 있고 클러스터의 일부입니까? 이것은 또한 ZooKeeper를 통해 관리됩니다.

주제 구성 -존재하는 주제, 각 파티션 수, 복제본 위치, 선호하는 리더, 각 주제에 대해 설정된 구성 대체

(0.9.0)-할당량 -각 클라이언트가 읽고 쓸 수있는 데이터 양

(0.9.0)-ACL- 누가 어떤 주제 (오래된 상위 레벨 소비자)를 읽고 쓸 수있는 사람-어떤 소비자 그룹이 있는지, 누가 회원인지, 각 그룹이 각 파티션에서 얻은 최신 오프셋은 무엇입니까?

[ https://www.quora.com/What-is-the-actual-role-of-ZooKeeper-in-Kafka/answer/Gwen-Shapira에서 ]

시나리오에 따라 하나의 브로커 인스턴스와 여러 소비자가있는 하나의 프로듀서 만 푸셔를 사용하여 채널을 생성하고 소비자가 해당 이벤트를 구독하고 처리 할 수있는 해당 채널로 이벤트를 푸시 할 수 있습니다. https://pusher.com/

중요 업데이트-2019 년 8 월 :

ZooKeeper 종속성이 Apache Kafka에서 제거됩니다 . 의 높은 수준의 토론을 참조하십시오KIP-500 : ZooKeeper를 자체 관리 형 메타 데이터 쿼럼으로 교체에.

이러한 노력에는 몇 가지 Kafka 릴리스 및 추가 KIP가 필요합니다. Kafka Controllers는 현재 ZooKeeper 작업의 작업을 대신합니다. 컨트롤러는 Kafka의 핵심 개념 인 이벤트 로그의 이점을 활용합니다.

새로운 Kafka 아키텍처의 일부 장점은 아키텍처가 간단하고 조작이 쉽고 확장 성이 뛰어납니다 (예 : "무제한 파티션"허용).

2020 년 7 월에 업데이트 됨

최신 버전 (2.5.0)의 경우 Kafka를 실행 하려면 ZooKeeper가 여전히 필요 하지만 조만간 ZooKeeper는 자체 관리 메타 데이터 쿼럼으로 대체됩니다. .

허용 된 KIP-500 의 세부 사항을 참조하십시오 .

Kafka는 Zookeeper를 사용하도록 제작되었습니다. 그로부터 탈출은 없습니다.

Kafka는 분산 시스템이며 Zookeeper를 사용하여 kafka 클러스터 노드의 상태를 추적합니다. 또한 Kafka 주제, 파티션 등을 추적합니다.

귀하의 질문을 살펴보면 Kafka가 필요하지 않은 것 같습니다. Redis , Rabbit MQ 와 같은 pub-sub 또는 Pub-nub 와 같은 호스팅 된 솔루션 을 지원하는 모든 애플리케이션을 사용할 수 있습니다 .

IMHO Zookeeper는 오버 헤드가 아니지만 인생을 훨씬 쉽게 만듭니다.

기본적으로 클러스터의 서로 다른 노드 간 조정을 유지하는 데 사용됩니다. Kafka의 가장 중요한 것 중 하나는 zookeeper를 사용하여 주기적으로 오프셋을 커밋하여 노드 장애가 발생한 경우 이전에 커밋 된 오프셋에서 재개 할 수 있다는 것입니다 (자신이이 모든 것을 처리한다고 상상해보십시오).

Zookeeper는 또한 리더 감지, 구성 관리, 동기화, 새 노드가 클러스터에 참여하거나 클러스터에서 나가는시기 감지 등과 같은 다른 많은 목적을 수행하는 데 중요한 역할을합니다.

향후 Kafka 릴리즈는 Zookeeper 의존성을 제거 할 계획이지만 현재로서는 필수 요소입니다.

FAQ 페이지에서 가져온 몇 줄은 다음과 같습니다.

Zookeeper 쿼럼이 다운되면 브로커가 상태가 나 빠지고 클라이언트 요청 등을 정상적으로 처리 할 수 ​​없습니다. Zookeeper 쿼럼이 복구 될 때 Kafka 브로커가 자동으로 정상 상태로 다시 시작할 수 있어야하지만 몇 가지 경우가 여전히 있습니다 그들은 그것을 불가능하게하고 그것을 다시 정상으로 되돌리려면 어려운 살인과 회복이 필요하다. 따라서 동물원 관리자 클러스터를 면밀히 모니터링하고 성능을 발휘하도록 프로비저닝하는 것이 좋습니다.

자세한 내용은 여기를 확인 하십시오

Zookeeper는 모든 종류의 분산 시스템을위한 중앙 집중식 관리 시스템입니다. 분산 시스템은 서로 다른 노드 / 클러스터 (지리적 위치에있을 수 있음)에서 실행되지만 하나의 시스템으로 실행되는 서로 다른 소프트웨어 모듈입니다. Zookeeper는 노드 간 통신을 용이하게하고 노드간에 구성을 공유하며 어느 노드가 리더인지, 어떤 노드가 조인 / 리브하는지 등을 추적합니다. Zookeeper는 분산 시스템을 깔끔하게 유지하고 일관성을 유지하는 사람입니다. Zookeeper는 기본적으로 오케스트레이션 플랫폼입니다.

Kafka는 분산 시스템입니다. 따라서 지리적으로 멀리 떨어져 있거나 그렇지 않은 노드에 대해 일종의 오케스트레이션 이 필요합니다 .

그렇습니다. Zookeeper는 Kafka의 설계 상 필수입니다. Zookeeper는 일종의 Kafka 클러스터 관리 책임이 있기 때문입니다. 여기에는 모든 Kafka 브로커 목록이 있습니다. 브로커가 다운되거나 파티션이 다운되거나 새 브로커가 가동되었거나 파티션이 가동 된 경우 Kafka에 알립니다. 한마디로 ZK는 모든 Kafka 브로커가 Kafka 클러스터의 현재 상태를 업데이트하도록 유지합니다.

그런 다음 모든 Kafka 클라이언트 (프로듀서 / 소비자)가 모든 단일 브로커와 연결하고 해당 브로커에 Zookeeper가 업데이트 한 모든 메타 데이터가 있으므로 클라이언트가 브로커 발견 두통을 걱정할 필요가 없습니다.

일반적인 페이로드 메시지 전송 외에도 kafka에서 발생하는 다른 많은 통신이 있습니다.

• 클러스터 멤버십을 요청하는 브로커와 관련된 이벤트입니다.
• 브로커와 관련된 이벤트가 제공됩니다.
• 부트 스트랩 구성 설정 가져 오기
• 컨트롤러 및 리더 업데이트 관련 이벤트.
• 하트 비트 업데이트와 같은 상태 업데이트를 도와줍니다.

Zookeeper 자체는 앙상블의 여러 노드로 구성된 분산 시스템입니다. Zookeeper는 이러한 메타 데이터를 유지 관리하기위한 중앙 집중식 서비스입니다.

이 기사는 Kafka에서 Zookeeper의 역할을 설명합니다. 또한 kafka의 상태 비 저장 방법과 zookeper가 kafka (및 더 많은 분산 시스템)의 분산 특성에서 중요한 역할을하는 방법에 대해 설명합니다.

Zookeeper없이 Kafka를 실행하라는 요청은 일반적인 것으로 보입니다. 도서관 Charlatan 이이 문제를 해결합니다.

설명에 따르면 Charlatan은 Zookeeper에 대한 모의로, 다른 도구 또는 데이터베이스에 의해 백업 된 Zookeeper 서비스를 제공합니다.

나는 Charlatan 도서관의 저자들의 주요 제품을 다룰 때 그 도서관을 만났다. 거기에서 잘 작동합니다…

먼저

Apache ZooKeeper는 구성 및 동기화 서비스를 고 가용성으로 제공하는 데 사용되는 분산 저장소입니다 . 최신 버전의 Kafka에서는 클라이언트 소비자가 메시지를 얼마나 멀리 사용한지에 대한 정보 (오프셋이라고 함)를 ZooKeeper에 저장하지 않기 위해 작업을 수행했습니다. .This reduced usage did not get rid of the need for consensus and coordination in distributed systems however.Kafka는 내결함성과 복원력 을 제공하지만, 조정이 필요하며 ZooKeeper는 전체 시스템의 일부를 가능하게합니다.

둘째로

파티션의 리더가 누구인지에 동의하는 것은 Kafka 생태계 내에서 ZooKeeper를 실제로 적용한 예입니다.

Zookeeper would work if there was even a single broker. 

이것들은 Kafka In Action 책에서 나온 것입니다. 이 과정의 이미지