90% Engineer Dùng Kafka Sai Cách: Sự Thật Về Distributed Log

Bạn dùng Kafka được vài năm nhưng hệ thống vẫn hay gặp lỗi lag partition không giải thích được? Thật ra, hầu hết Dev đang nhầm tưởng Kafka là một Message Queue truyền thống. Đọc ngay bài viết này để tránh những “cái bẫy” thiết kế khiến Production của bạn sụp đổ bất cứ lúc nào.

Kafka không phải message queue

Đây là misconception phổ biến nhất. Queue truyền thống: message được đọc xong thì xóa. Kafka hoàn toàn khác — nó là distributed append-only log. Message được giữ lại sau khi consume, có thể replay, nhiều service đọc độc lập mà không ảnh hưởng nhau. Một quyết định thiết kế duy nhất này thay đổi toàn bộ cách Kafka hoạt động.

3 khái niệm cốt lõi cần nắm

Topic + Partition là đơn vị scalability

Mỗi topic chia thành nhiều partition, phân tán trên nhiều broker. Kafka chỉ đảm bảo ordering trong một partition — không phải toàn topic. Vì vậy nếu cần events của cùng một user theo thứ tự, dùng userId làm partition key để chúng luôn rơi vào cùng partition.

Consumer Group là engine của horizontal scaling

Mỗi partition được assign cho đúng 1 consumer trong group. Muốn xử lý nhanh hơn? Thêm consumer. Consumer crash? Kafka tự reassign partition sang consumer khác — không cần can thiệp thủ công.

Replication đảm bảo fault tolerance

Mỗi partition có 1 leader và nhiều follower trên các broker khác nhau. Producer chỉ ghi vào leader. Follower replicate liên tục. Leader chết → follower lên thay tự động.

Hiệu năng thực sự bị giới hạn bởi partition strategy, không phải hardware. Một partition key được chọn sai có thể throttle cả pipeline mà không ai nhận ra. Và đừng tăng số partition tùy tiện — số partition không thể giảm sau khi tạo, chỉ có thể tăng.

Kafka không phức tạp vì API khó dùng. Nó phức tạp vì hầu hết người dùng không thực sự hiểu cái distributed log nằm bên dưới — và production mới là nơi điều đó bộc lộ.

Print

---