ข้ามไปยังเนื้อหา

Broker, Topic และ Partition

topic คือ stream เชิงตรรกะที่ Kafka แบ่งจริงเป็น partition แต่ละ partition คือ log ที่มีลำดับหนึ่งอัน และ partition เหล่านั้นถูกกระจายไปตาม broker ต่าง ๆ ใน cluster ซึ่งคือวิธีที่ topic เดียว scale เกินหนึ่งเครื่องได้

broker คือ process เซิร์ฟเวอร์ Kafka หนึ่งตัว หลาย broker รวมกันเป็น cluster broker แต่ละตัวเก็บข้อมูลบางส่วนและจัดการการอ่านเขียนของ partition ที่ตัวเองเป็นเจ้าของ client เชื่อมต่อไปที่ broker ตัวไหนก็ได้ผ่าน address ของ bootstrap server จากตรงนั้น client จะ discover cluster ทั้งหมดและรู้ว่า broker ตัวไหน lead partition ไหน

Terminal window
# Create a topic with 3 partitions and 3 replicas across the cluster
kafka-topics.sh --bootstrap-server localhost:9092 \
--create --topic orders --partitions 3 --replication-factor 3

topic อย่าง orders ไม่ใช่ log ก้อนใหญ่ก้อนเดียว แต่ถูกแบ่งเป็น partition จำนวนคงที่ (orders-0, orders-1, orders-2) แต่ละ partition คือ log แบบ append-only อิสระที่มี offset sequence ของตัวเอง นี่คือหน่วยของทั้ง parallelism และ ordering

  • Parallelism partition คนละอันอยู่บน broker คนละตัว การอ่านเขียนเลยกระจายไปหลายเครื่อง ยิ่ง partition เยอะ throughput ยิ่งสูง
  • Ordering Kafka การันตีลำดับ ภายใน partition แต่ ไม่ข้าม partition offset 5 ของ orders-0 ไม่มีลำดับที่นิยามไว้เทียบกับ offset 5 ของ orders-1
flowchart TB
  subgraph b1["Broker 1"]
    p0["orders-0 (leader)"]
  end
  subgraph b2["Broker 2"]
    p1["orders-1 (leader)"]
  end
  subgraph b3["Broker 3"]
    p2["orders-2 (leader)"]
  end
  topic["Topic: orders (3 partitions)"] --> p0
  topic --> p1
  topic --> p2
topic กระจายเป็น partition ข้าม broker

record ใด ๆ ใน Kafka ถูกระบุด้วยพิกัดสามอย่าง

  • topic stream ไหน (orders)
  • partition log ไหนใน stream นั้น (orders-2)
  • offset ตำแหน่งใน log นั้น (offset 91)

สามอย่างนี้คือ address ถาวรของ record ตำแหน่งที่ consumer commit ไว้ก็คือสิ่งนี้เป๊ะ ๆ “สำหรับ orders-2 ฉันประมวลผลถึง offset 91 แล้ว”

จำนวน partition คือปุ่มปรับ throughput หลักของคุณ แต่ไม่ฟรี partition แต่ละอันคือไฟล์บนดิสก์และเป็นหน่วยงานสำหรับ consumer กับ controller น้อยไปก็ parallelize ไม่ได้ เยอะไปก็จ่าย overhead ทั้ง metadata, open file และเวลา rebalance วิธีที่นิยมคือ ประเมิน throughput เป้าหมาย, ตั้งจำนวน partition ให้พอดีกับเป้าหมายนั้น แล้วเผื่อ headroom ไว้ คุณ เพิ่ม partition ทีหลังได้ แต่การทำแบบนั้นเปลี่ยนวิธีที่ record แบบมี key map ไป partition (ข้อควรระวังที่ module ถัดไปจะอธิบาย)

ความสัมพันธ์ระหว่าง topic กับ partition คืออะไร
Kafka การันตีลำดับของ record ตรงไหน
ทำไมถึงเพิ่มจำนวน partition ให้ topic
ระบุตำแหน่ง record เฉพาะตัวใน Kafka ยังไง