Zookeeper เป็นสิ่งจำเป็นสำหรับ Kafka หรือไม่?

ในคาฟคาฉันต้องการใช้เพียงโบรกเกอร์เดียวหัวข้อเดียวและพาร์ติชันเดียวที่มีผู้ผลิตรายเดียวและผู้บริโภคหลายราย (ผู้บริโภคแต่ละรายจะได้รับสำเนาข้อมูลของตัวเองจากนายหน้า) ด้วยเหตุนี้ฉันไม่ต้องการค่าใช้จ่ายในการใช้ Zookeeper ใช้แค่นายหน้าอย่างเดียวไม่ได้หรือ? ทำไม Zookeeper ถึงต้อง?

ใช่ Zookeeper จำเป็นสำหรับการเรียกใช้ Kafka จากเอกสารการเริ่มต้นใช้งาน Kafka:

ขั้นตอนที่ 2: เริ่มเซิร์ฟเวอร์

Kafka ใช้ Zookeeper ดังนั้นคุณต้องเริ่มเซิร์ฟเวอร์ Zookeeper ก่อนหากคุณยังไม่มี คุณสามารถใช้สคริปต์อำนวยความสะดวกที่มาพร้อมกับคาฟคาเพื่อรับอินสแตนซ์ Zookeeper โหนดเดียวที่รวดเร็วและสกปรก

ด้วยเหตุใดหลายคนจึงค้นพบเมื่อนานมาแล้วว่าคุณจำเป็นต้องมีวิธีบางอย่างในการประสานงานการจัดการสถานะการกำหนดค่าและอื่น ๆ ในระบบแบบกระจาย บางโปรเจ็กต์ได้สร้างกลไกของตนเอง (ลองนึกถึงเซิร์ฟเวอร์คอนฟิกูเรชันในคลัสเตอร์ MongoDB sharded หรือโหนดหลักในคลัสเตอร์ 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:

ZooKeeper พึ่งพาจะถูกลบออกจากอาปาเช่คาฟคา ดูการอภิปรายระดับสูงในKIP-500 : แทนที่ ZooKeeper ด้วย Quorum เมทาดาทาที่จัดการด้วยตนเององค์ประชุม

ความพยายามเหล่านี้จะมีการเผยแพร่ Kafka และ KIP เพิ่มเติมเล็กน้อย Kafka Controllers จะเข้าควบคุมงานของ ZooKeeper ในปัจจุบัน ตัวควบคุมจะใช้ประโยชน์จากบันทึกเหตุการณ์ซึ่งเป็นแนวคิดหลักของคาฟคา

ประโยชน์บางประการของสถาปัตยกรรม Kafka ใหม่คือสถาปัตยกรรมที่เรียบง่ายขึ้นใช้งานง่ายและปรับขนาดได้ดีขึ้น (เช่นอนุญาตให้ "พาร์ติชันไม่ จำกัด "

อัปเดตเมื่อ ก.ค. 2020

สำหรับเวอร์ชันล่าสุด (2.5.0) ZooKeeper ยังจำเป็นสำหรับการใช้งาน Kafka แต่ในอนาคตอันใกล้ZooKeeper จะถูกแทนที่ด้วย Quorum เมทาดาทาที่จัดการด้วยตนเององค์ประชุม

ดูรายละเอียดในKIP-500 ที่ยอมรับ

Kafka สร้างขึ้นเพื่อใช้ Zookeeper ไม่มีการหลีกหนีจากสิ่งนั้น

Kafka เป็นระบบกระจายและใช้ Zookeeper เพื่อติดตามสถานะของโหนดคลัสเตอร์คาฟคา นอกจากนี้ยังติดตามหัวข้อ Kafka พาร์ทิชัน ฯลฯ

เมื่อดูคำถามของคุณดูเหมือนว่าคุณไม่ต้องการคาฟคา คุณสามารถใช้โปรแกรมใด ๆ ที่สนับสนุนผับย่อยเช่นRedisกระต่าย MQ หรือเป็นเจ้าภาพแก้ปัญหาเช่นผับนับ

IMHO Zookeeper ไม่ใช่ค่าใช้จ่าย แต่ทำให้ชีวิตของคุณง่ายขึ้นมาก

โดยทั่วไปจะใช้เพื่อรักษาการประสานงานระหว่างโหนดต่างๆในคลัสเตอร์ สิ่งที่สำคัญที่สุดอย่างหนึ่งสำหรับ Kafka คือการใช้ Zookeeper เพื่อทำการชดเชยเป็นระยะ ๆ เพื่อที่ว่าในกรณีที่โหนดล้มเหลวมันสามารถกลับมาทำงานต่อจากการชดเชยที่กำหนดไว้ก่อนหน้านี้ได้ (ลองนึกภาพว่าคุณดูแลทั้งหมดนี้ด้วยตัวคุณเอง)

Zookeeper ยังมีบทบาทสำคัญในการตอบสนองวัตถุประสงค์อื่น ๆ อีกมากมายเช่นการตรวจจับผู้นำการจัดการการกำหนดค่าการซิงโครไนซ์การตรวจจับเมื่อโหนดใหม่เข้าร่วมหรือออกจากคลัสเตอร์เป็นต้น

การเปิดตัว Kafka ในอนาคตกำลังวางแผนที่จะลบการพึ่งพาผู้ดูแลสวนสัตว์ แต่ ณ ตอนนี้มันเป็นส่วนสำคัญของมัน

นี่คือสองสามบรรทัดที่นำมาจากหน้าคำถามที่พบบ่อย:

เมื่อโควรัม Zookeeper หมดลงโบรกเกอร์อาจส่งผลให้อยู่ในสถานะที่ไม่ดีและไม่สามารถตอบสนองคำขอของลูกค้าได้ตามปกติเป็นต้นแม้ว่าโควรัม Zookeeper จะฟื้นตัว แต่โบรกเกอร์ Kafka ควรจะสามารถกลับสู่สถานะปกติได้โดยอัตโนมัติ แต่ก็ยังมีบางกรณี พวกเขาทำไม่ได้และจำเป็นต้องมีการฆ่าและกู้คืนอย่างหนักเพื่อให้มันกลับมาเป็นปกติ ดังนั้นขอแนะนำให้ตรวจสอบคลัสเตอร์ผู้ดูแลสวนสัตว์ของคุณอย่างใกล้ชิดและจัดเตรียมไว้เพื่อให้มีประสิทธิภาพ

ตรวจสอบรายละเอียดเพิ่มเติมได้ที่นี่

Zookeeper เป็นศูนย์กลางและระบบการจัดการสำหรับระบบกระจายทุกประเภท ระบบแบบกระจายเป็นโมดูลซอฟต์แวร์ที่แตกต่างกันที่ทำงานบนโหนด / คลัสเตอร์ที่แตกต่างกัน (อาจอยู่ในตำแหน่งที่ห่างไกลทางภูมิศาสตร์) แต่ทำงานเป็นระบบเดียว Zookeeper ช่วยอำนวยความสะดวกในการสื่อสารระหว่างโหนดการกำหนดค่าการแชร์ระหว่างโหนดติดตามว่าโหนดใดเป็นผู้นำโหนดใดเข้าร่วม / ออกเป็นต้น Zookeeper เป็นผู้ที่ทำให้ระบบกระจายมีสติและรักษาความสม่ำเสมอ Zookeeper โดยพื้นฐานแล้วเป็นแพลตฟอร์มการจัดระเบียบ

คาฟคาเป็นระบบกระจาย และด้วยเหตุนี้จึงจำเป็นต้องมีการประสานงานบางอย่างสำหรับโหนดที่อาจอยู่ห่างออกไปทางภูมิศาสตร์ (หรือไม่)

ใช่ Zookeeper ต้องได้รับการออกแบบสำหรับ Kafka เนื่องจาก Zookeeper มีหน้าที่ในการจัดการคลัสเตอร์ Kafka มีรายชื่อโบรกเกอร์ Kafka ทั้งหมดด้วย จะแจ้งให้ Kafka ทราบหากโบรกเกอร์ใด ๆ หยุดทำงานหรือพาร์ติชันหยุดทำงานหรือมีนายหน้าใหม่ขึ้นหรือพาร์ติชันขึ้น ในระยะสั้น ZK จะให้โบรกเกอร์ Kafka ทุกรายอัปเดตเกี่ยวกับสถานะปัจจุบันของคลัสเตอร์ Kafka

จากนั้นลูกค้า Kafka (ผู้ผลิต / ผู้บริโภค) ทุกคนต้องทำคือเชื่อมต่อกับโบรกเกอร์รายเดียวและโบรกเกอร์นั้นมีข้อมูลเมตาทั้งหมดที่อัพเดตโดย Zookeeper ดังนั้นลูกค้าไม่จำเป็นต้องกังวลกับอาการปวดหัวในการค้นหานายหน้า

นอกเหนือจากการถ่ายโอนข้อความเพย์โหลดตามปกติแล้วยังมีการสื่อสารอื่น ๆ อีกมากมายที่เกิดขึ้นในคาฟคาเช่น

• เหตุการณ์ที่เกี่ยวข้องกับโบรกเกอร์ที่ขอเป็นสมาชิกคลัสเตอร์
• มีกิจกรรมที่เกี่ยวข้องกับโบรกเกอร์
• รับการตั้งค่าการกำหนดค่า bootstrap
• เหตุการณ์ที่เกี่ยวข้องกับการอัปเดตตัวควบคุมและผู้นำ
• การอัปเดตสถานะความช่วยเหลือเช่นการอัปเดต Heartbeat

Zookeeper เป็นระบบแบบกระจายซึ่งประกอบด้วยโหนดหลายโหนดในชุด Zookeeper เป็นบริการแบบรวมศูนย์สำหรับการรักษาข้อมูลเมตาดังกล่าว

นี้บทความอธิบายถึงบทบาทของผู้ดูแลสัตว์ใน Kafka อธิบายว่าคาฟคาไร้สัญชาติอย่างไรและซูคีเปอร์มีบทบาทสำคัญอย่างไรในลักษณะการกระจายของคาฟคา (และระบบกระจายอื่น ๆ อีกมากมาย)

คำขอให้เรียกใช้ Kafka โดยไม่มี Zookeeper ดูเหมือนจะค่อนข้างธรรมดา ห้องสมุดCharlatanกล่าวถึงเรื่องนี้

ตามคำอธิบาย Charlatan เป็นเครื่องจำลองสำหรับ Zookeeper ไม่มากก็น้อยโดยให้บริการ Zookeeper ไม่ว่าจะสำรองโดยเครื่องมืออื่นหรือโดยฐานข้อมูล

ฉันพบห้องสมุดนั้นเมื่อจัดการกับผลิตภัณฑ์หลักของผู้เขียนสำหรับห้องสมุด Charlatan มันใช้งานได้ดี ...

ประการแรก

Apache ZooKeeper เป็นร้านค้าแบบกระจายซึ่งใช้เพื่อให้บริการการกำหนดค่าและการซิงโครไนซ์ด้วยวิธีที่พร้อมใช้งานสูง ในเวอร์ชันล่าสุดของ Kafka งานได้ดำเนินการเพื่อให้ลูกค้าที่เป็นลูกค้าไม่เก็บข้อมูลว่ามีการใช้ข้อความ (เรียกว่า offsets) ไปยัง ZooKeeper มากเพียงใด.This reduced usage did not get rid of the need for consensus and coordination in distributed systems however.ในขณะที่ Kafka ให้การยอมรับข้อผิดพลาดและความยืดหยุ่นแต่จำเป็นต้องมีบางอย่างเพื่อให้ จำเป็นต้องมีการประสานงานและ ZooKeeper ช่วยให้ระบบโดยรวมนั้นเป็นส่วนหนึ่ง

ในประการที่สอง

การยอมรับว่าใครเป็นผู้นำของพาร์ติชันเป็นตัวอย่างหนึ่งของการประยุกต์ใช้ ZooKeeper ในระบบนิเวศคาฟคา

Zookeeper would work if there was even a single broker. 

สิ่งเหล่านี้มาจากหนังสือKafka In Action ภาพมาจากหลักสูตรนี้