Kafka: topic, partition và append-only log

Đúng hướng rồi. Về mô hình "nhiều bên cùng nhận một event", RabbitMQ và Kafka nhìn khá giống nhau. Nhưng chuyện "giữ lại message" không phải một chi tiết nhỏ: nó thay đổi cả cách nhìn về dữ liệu. RabbitMQ là queue (việc cần làm), Kafka là log (chuyện đã xảy ra). Bài này học phần lõi đó: topic, partition, append-only log.

1. Bài toán: shop-app phát event đơn hàng

Trong shop-app, order-service tạo đơn rồi phát event. Ba service khác cần event này:

order-service ──(OrderCreated, OrderPaid, OrderCancelled)──▶ ???
                                                   ├──▶ inventory-service    (trừ/hoàn kho)
                                                   ├──▶ notification-service (gửi email)
                                                   └──▶ analytics-service    (thống kê, có thể chạy lại)

Ở bài 8.2 ta làm bằng RabbitMQ: fanout/topic exchange → 3 queue. Chạy tốt. Nhưng có yêu cầu mới:

• analytics-service bị bug tính sai doanh thu 3 ngày qua. Sửa xong, muốn đọc lại event 3 ngày đó.
• Tháng sau thêm fraud-service, muốn đọc cả lịch sử event từ đầu.
• Black Friday: 20.000 event/giây, cần nhiều instance xử lý song song mà các event của cùng một đơn vẫn đúng thứ tự.

2. Vấn đề với queue

Queue:  [m1][m2][m3]  → consumer ACK m1 → m1 bị xóa khỏi queue

• Message đã ACK là biến mất. Muốn replay phải tự lưu ở đâu đó rồi publish lại.
• Service mới (fraud-service) tạo queue mới chỉ nhận được message từ lúc bind, không có lịch sử.
• Nhiều consumer cùng một queue thì xử lý song song, nhưng thứ tự giữa các message của cùng một đơn không còn được đảm bảo.

3. Giải pháp: Kafka là partitioned, append-only log

Kafka lưu event vào log: một dãy record chỉ được ghi thêm vào cuối (append-only), không sửa, không xóa từng record khi consumer đọc xong.

Consumer không "lấy đi" record. Mỗi consumer group tự nhớ mình đọc tới offset nào. Vì record còn đó, ta có thể replay: lùi offset về chỗ cũ và đọc lại.

4. Code từng bước

shop-app/
├── order-service/          <-- producer
├── inventory-service/      <-- consumer (bài 8.8)
├── notification-service/
└── analytics-service/

Bước 1: Dependency (Spring Boot quản lý version):

<dependency>
    <groupId>org.springframework.kafka</groupId>
    <artifactId>spring-kafka</artifactId>
</dependency>

Bước 2: application.yml của order-service:

spring:
  kafka:
    bootstrap-servers: ${KAFKA_BOOTSTRAP:localhost:9092}
    producer:
      key-serializer: org.apache.kafka.common.serialization.StringSerializer
      value-serializer: org.springframework.kafka.support.serializer.JsonSerializer

Bước 3: Tạo topic có chủ đích. Số partition là quyết định thiết kế, không để mặc định:

@Configuration
public class KafkaTopicConfig {

    @Bean
    public NewTopic ordersTopic() {
        return TopicBuilder.name("orders")
                .partitions(6)
                .replicas(3)                       // bài 8.7
                .config(TopicConfig.RETENTION_MS_CONFIG,
                        String.valueOf(Duration.ofDays(7).toMillis()))
                .build();
    }
}

Spring Boot có sẵn KafkaAdmin, khi app khởi động sẽ tạo topic nếu chưa có. Production thường tạo topic bằng pipeline/IaC thay vì để app tự tạo.

Bước 4: Publish event với key = orderId

public record OrderEvent(String orderId, String type, BigDecimal amount, Instant occurredAt) {}

@Service
@RequiredArgsConstructor
@Slf4j
public class OrderEventPublisher {

    private final KafkaTemplate<String, OrderEvent> kafkaTemplate;

    public void publish(OrderEvent event) {
        kafkaTemplate.send("orders", event.orderId(), event)   // topic, key, value
            .whenComplete((result, ex) -> {
                if (ex != null) {
                    log.error("Send failed orderId={}", event.orderId(), ex);
                    return;
                }
                RecordMetadata m = result.getRecordMetadata();
                log.info("orderId={} -> partition={} offset={}",
                        event.orderId(), m.partition(), m.offset());
            });
    }
}

Bước 5: Test

curl -X POST localhost:8081/orders -H "Content-Type: application/json" \
     -d '{"productId":"P1","quantity":2}'

# log:
# orderId=101 -> partition=4 offset=0
# (gọi pay cho đơn 101)
# orderId=101 -> partition=4 offset=1     <-- cùng partition

Xem trực tiếp trong Kafka:

kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic orders
kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic orders \
    --from-beginning --property print.key=true --property print.partition=true

5. Cách hoạt động

Topic: orders (6 partitions)

           hash(key) % 6
Producer ─────────────────┐
                          ▼
P0: [0][1][2][3]                    ← append vào cuối
P1: [0][1]
P2: [0][1][2][3][4][5]
P3: [0]
P4: [0 order101 CREATED][1 order101 PAID][2 ...]
P5: [0][1][2]

inventory-group    đọc P4 tới offset 2
analytics-group    đọc P4 tới offset 0   ← chậm hơn, không sao
                   (mỗi group nhớ offset riêng; record không bị xóa)

Retention 7 ngày: record cũ hơn 7 ngày bị xóa theo từng segment file, bất kể đã có ai đọc hay chưa.

6. So sánh: queue và log

7. Khi nào nên dùng / không nên dùng

• Nên: event stream nhiều bên đọc, cần replay, throughput lớn, cần thứ tự theo entity (orderId, userId).
• Không nên: task queue đơn giản cần routing linh hoạt, priority, delay từng message, hoặc request/reply. RabbitMQ hợp hơn (bài 8.10).

Hai câu này là nền của mọi thứ phía sau.

Số partition: do mình config

• Đặt khi tạo topic (--partitions 6 hoặc TopicBuilder.partitions(6)). Nếu không chỉ định, broker dùng num.partitions (mặc định của Kafka là 1, nhưng cluster có thể cấu hình khác).
• Kafka không tự nhìn traffic rồi đổi 3 → 10 partition cho bạn.
• Tăng được, không giảm được. Và tăng sẽ làm đổi mapping key → partition (xem dưới).

Message vào partition nào: do producer chọn

1. Producer chỉ định partition rõ ràng      → vào đúng partition đó (hiếm dùng)
2. Có key                                    → murmur2(key) % số_partition
3. Không key, không partition                → partitioner mặc định phân phối
                                               (sticky: dồn một batch vào một partition rồi đổi)

key "101" → murmur2 → ... % 6 = 4 → P4
key "101" → luôn P4 (khi số partition không đổi)
key "102" → P1

Chú ý: đừng học thuộc "không key = round-robin". Client mới dùng sticky partitioning để batch hiệu quả hơn.

Bẫy khi tăng partition

6 partition:  hash("101") % 6 = 4  → P4
tăng lên 8:   hash("101") % 8 = 2  → P2   ← event mới của đơn 101 sang partition khác!

Event cũ của đơn 101 ở P4, event mới ở P2: trong lúc chuyển giao, thứ tự của đơn 101 có thể bị đảo. Vì vậy nên chọn số partition dư ra ngay từ đầu cho tải dự kiến.

Đúng ý chính: message 11 hoàn toàn có thể xử lý xong trước. Chỉ chỉnh một điểm: không có chuyện "không có partition". Topic luôn có ít nhất 1 partition.

1 partition:
P0: M1 → M2 → ... → M10 → M11      → consumer đọc đúng thứ tự, nhưng chỉ 1 consumer/group

2 partition:
P0: M1 → M2 → ... → M10   → Consumer A (đang làm M1)
P1: M11                   → Consumer B (xong M11 trước) ✅ hợp lệ

Kafka chỉ đảm bảo thứ tự trong một partition, không đảm bảo giữa các partition. Cách giải: dùng key là business id cần giữ thứ tự.

key = orderId
P4: order101 CREATED → PAID → SHIPPED     (đúng thứ tự cho đơn 101)
P1: order102 CREATED → CANCELLED          (song song với đơn 101, không sao)

Thực tế hiếm khi cần thứ tự toàn hệ thống. Thường chỉ cần thứ tự của cùng một entity. Đó là điểm mạnh của Kafka: vừa song song, vừa giữ thứ tự theo key.

Lưu ý nhỏ: phía producer, nếu retry mà không bật idempotence thì thứ tự trong partition cũng có thể đảo. Từ Kafka 3.0, enable.idempotence=true là mặc định nên trường hợp này đã được xử lý (bài 8.9).

Q1. Kafka khác message queue truyền thống ở điểm nào?

🇻🇳 Tiếng Việt:

Kafka là một distributed append-only log. Record được giữ theo retention policy chứ không bị xóa khi consumer đọc xong. Mỗi consumer group tự quản lý offset của mình, nên nhiều group đọc cùng topic độc lập và có thể replay bằng cách lùi offset. Queue truyền thống như RabbitMQ thì xóa message sau khi ACK.

🇬🇧 English:

Kafka is a distributed append-only log. Records are kept according to a retention policy, not deleted when a consumer reads them. Each consumer group tracks its own offsets, so many groups can read the same topic independently and replay by resetting offsets. A traditional queue like RabbitMQ removes a message once it is acknowledged.

Q2. Kafka có đảm bảo thứ tự message không?

🇻🇳 Tiếng Việt:

Có, nhưng chỉ trong một partition. Không có thứ tự toàn topic. Nếu các event của cùng một entity cần giữ thứ tự, ví dụ cùng một đơn hàng, em dùng orderId làm key để chúng luôn vào cùng partition. Cần thứ tự toàn topic thì phải dùng 1 partition và chấp nhận mất khả năng song song.

🇬🇧 English:

Yes, but only within a partition; there is no global order across a topic. If events of the same entity must stay in order, such as one order, I use the orderId as the key so they always land in the same partition. Global ordering requires a single partition, which gives up parallelism.

Q3. Producer chọn partition thế nào? Tăng số partition có rủi ro gì?

🇻🇳 Tiếng Việt:

Nếu chỉ định partition thì dùng partition đó. Nếu có key thì hash key (murmur2) modulo số partition. Không có key thì partitioner mặc định phân phối, client mới dùng sticky partitioning. Tăng số partition làm đổi mapping key → partition, nên event mới của một key có thể sang partition khác và mất thứ tự tạm thời. Vì vậy em chọn số partition dư từ đầu.

🇬🇧 English:

An explicit partition wins. With a key, the producer hashes the key with murmur2 modulo the partition count. Without a key, the default partitioner spreads records, using sticky partitioning in modern clients. Adding partitions changes the key-to-partition mapping, so new events for a key may move and lose ordering temporarily. That is why I size partitions with headroom up front.

Cách nhớ ngắn gọn

• Kafka = log, không phải queue: đọc xong không xóa, giữ theo retention.
• Topic → Partition → Offset. Offset chỉ có nghĩa trong một partition.
• Thứ tự chỉ trong partition. Cần thứ tự theo entity → key = entityId.
• Partition tăng được, không giảm; tăng thì đổi mapping key.