Partition กับ Ordering

ไอเดียในประโยคเดียว

Partition คือหน่วยของทั้ง parallelism และ ordering: partition ยิ่งเยอะ throughput ยิ่งสูง แต่ Kafka การันตีลำดับแค่ ภายใน partition เท่านั้น ไม่เคยการันตีข้าม partition ทั้ง topic.

การันตีเดียว scope เดียว

Kafka ให้การันตีลำดับที่แข็งแรง แต่ scope อยู่แค่ partition เดียว ภายใน orders-0 offset 5 มาหลัง offset 4 เสมอตลอดไป ส่วนข้าม partition ไม่มี ลำดับที่แน่นอน: offset 5 ของ orders-0 กับ offset 5 ของ orders-1 อาจถูกเขียนก่อนหลังกันแบบไหนก็ได้ และ consumer อาจอ่านสลับลำดับกันได้

orders-0:  [a0][a1][a2][a3]      ← totally ordered
orders-1:  [b0][b1][b2]          ← totally ordered
                                  ← a2 vs b1: NO defined order

นี่ไม่ใช่ข้อจำกัดที่ต้องหาทางเลี่ยง แต่เป็นราคาของการ scale แนวนอน log เดียวที่ ordered ทั้งหมดเขียนเร็วกว่าที่เครื่องเดียว append ได้ไม่ได้ การแตกเป็น partition ทำให้หลายเครื่อง append พร้อมกัน — คุณแลก global order กับ throughput.

Partition กำหนดเพดาน parallelism ของ consumer

ภายใน consumer group หนึ่ง partition หนึ่งถูกอ่านโดย consumer เดียวในเวลาหนึ่ง ทำให้จำนวน partition เป็นเพดานว่ามี consumer ทำงานพร้อมกันได้กี่ตัว:

6 partition, 3 consumer → แต่ละตัวอ่าน 2 partition.
6 partition, 6 consumer → แต่ละตัวอ่าน 1 (parallelism สูงสุด).
6 partition, 8 consumer → 6 ตัวทำงาน อีก 2 ตัวว่าง เพราะไม่มี partition ให้ assign.

ถ้าอยาก scale การ consume ทีหลัง ต้องเตรียม partition ให้พอตั้งแต่แรก — consumer แบ่งย่อย partition เดียวไม่ได้

flowchart LR
  subgraph topic["Topic: orders (4 partitions)"]
    p0["orders-0"]
    p1["orders-1"]
    p2["orders-2"]
    p3["orders-3"]
  end
  p0 --> c1["Consumer 1"]
  p1 --> c1
  p2 --> c2["Consumer 2"]
  p3 --> c3["Consumer 3"]
  idle["Consumer 4 (idle: ไม่เหลือ partition)"]

จำนวน partition คุมว่ามี consumer ทำงานพร้อมกันได้กี่ตัว

Tradeoff ในการออกแบบ

การเลือกจำนวน partition คือการเลือกจุดบนเส้นโค้ง:

Partition เยอะ → throughput สูงและ consumer parallelism มากขึ้น แต่ open files เยอะ metadata เยอะ และ rebalance นานขึ้น
Partition น้อย → เรียบง่ายและถูกกว่า แต่เพดาน throughput ต่ำ
ความต้องการ ordering → ถ้า event ชุดหนึ่งต้องเรียงลำดับกันเป๊ะ ต้องลงที่ partition เดียวกัน (บทถัดไปอธิบายว่า key ทำแบบนี้ยังไง).

กฎที่ใช้ได้จริง: ตั้ง partition ตาม throughput เป้าหมายบวก headroom และให้ event ที่ต้องเรียงลำดับกันอยู่ partition เดียวกัน