code

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

codestyles 2020. 9. 3. 19:18
반응형

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


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


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

2 단계 : 서버 시작

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

그 이유에 대해 잘 알려진 사람들은 분산 시스템에서 작업, 상태 관리, 구성 등을 조정하는 방법이 필요하다는 것을 오래 전에 발견했습니다. 일부 프로젝트는 자체 메커니즘을 구축했습니다 (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/


Kafka는 Zookeeper를 사용하도록 제작되었습니다. 그것에서 벗어날 수는 없습니다.

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

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


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

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

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

새로운 Kafka 아키텍처의 몇 가지 이점은 더 단순한 아키텍처, 작업 용이성 및 더 나은 확장 성입니다 (예 : "무제한 파티션"허용).


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

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

Zookeeper는 리더 감지, 구성 관리, 동기화, 새 노드가 클러스터에 합류하거나 탈퇴하는시기 감지 등과 같은 다른 많은 목적을 제공하는데도 중요한 역할을합니다.

향후 Kafka 릴리스는 사육사 종속성을 제거 할 계획이지만 현재로서는 필수 요소입니다.

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

Zookeeper 쿼럼이 다운되면 브로커가 불량 상태가되어 일반적으로 클라이언트 요청을 처리 할 수 ​​없습니다. Zookeeper 쿼럼이 복구되면 Kafka 브로커가 자동으로 정상 상태로 재개 할 수 있어야하지만 여전히 몇 가지 코너 케이스가 있습니다. 그들은 할 수 없으며 그것을 정상으로 되돌리려면 하드 킬 앤 리커버리가 필요합니다. 따라서 사육사 클러스터를 면밀히 모니터링하고 성능을 발휘하도록 프로비저닝하는 것이 좋습니다.

자세한 내용은 여기에서 확인 하세요.


일반적인 페이로드 메시지 전송 외에도 kafka에서 발생하는 다른 많은 통신이 있습니다. * 클러스터 멤버십을 요청하는 브로커 관련 이벤트 * 브로커 관련 이벤트 사용 가능 * 부트 스트랩 구성 설정 가져 오기. * 컨트롤러 및 리더 업데이트와 관련된 이벤트. * Heartbeat 업데이트와 같은 도움말 상태 업데이트.

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


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

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


예, Zookeeper는 Kafka를 위해 설계해야합니다. Zookeeper는 Kafka 클러스터를 관리하는 일을 담당하기 때문입니다. 모든 Kafka 브로커 목록이 있습니다. 브로커가 다운되거나 파티션이 다운되거나 새 브로커가 실행되거나 파티션이 실행되면 Kafka에 알립니다. 간단히 말해 ZK는 Kafka 클러스터의 현재 상태에 대해 모든 Kafka 브로커를 업데이트합니다.

그런 다음 모든 Kafka 클라이언트 (생산자 / 소비자)는 단일 브로커와 연결하기 만하면되고 해당 브로커는 Zookeeper에서 모든 메타 데이터를 업데이트하므로 클라이언트가 브로커 검색 문제를 걱정할 필요가 없습니다.

참고 URL : https://stackoverflow.com/questions/23751708/is-zookeeper-a-must-for-kafka

반응형