Bài 8: Thiết kế "Tấm khiên" hệ thống — Schema Registry và Dead Letter Queue (DLQ)

1. Schema Registry: Cảnh sát kiểm duyệt cấu trúc dữ liệu

Vấn đề thực tế (The Problem): Kafka vốn dĩ rất "dễ dãi". Nó chỉ coi Message là một mảng byte (byte array). Nghĩa là Producer ném cái gì vào, Kafka cũng nhận. Hãy tưởng tượng hệ thống thu phí tự động (AFC) của bạn đang chạy ổn định với cấu trúc JSON như sau:

{
  "ticket_id": "T12345",
  "entry_station_id": 9,
  "amount": 15000
}

Một ngày đẹp trời, đội phát triển thiết bị TVM (Máy bán vé tự động) cập nhật phần mềm và đổi tên trường ticket_id thành card_number. Khi bản tin này được gửi vào Kafka, Consumer phía Backend đọc lên, tìm không thấy ticket_id đâu. Lập tức, Consumer báo lỗi Null Pointer Exception và toàn bộ quá trình xử lý giao dịch bị sập.

Giải pháp: Schema Registry Schema Registry ra đời để giải quyết vấn đề "sai hợp đồng". Nó là một máy chủ độc lập nằm ngoài cụm Kafka Broker, lưu trữ các "Hợp đồng dữ liệu" (Schema) thường được viết bằng Apache Avro, Protobuf hoặc JSON Schema.

Cơ chế hoạt động:

1. Kiểm duyệt tại nguồn: Khi Producer định gửi tin nhắn, nó phải đối chiếu với Schema Registry trước. Nếu cấu trúc dữ liệu không khớp với chuẩn đã thống nhất (ví dụ: thiếu trường bắt buộc, sai kiểu dữ liệu), Schema Registry sẽ báo lỗi ngay lập tức. Producer không thể đẩy tin nhắn rác vào Kafka.
2. Phiên bản hóa (Versioning): Khi cần nâng cấp cấu trúc dữ liệu (thêm trường mới), Schame Registry cho phép quản lý theo các phiên bản (v1, v2) với quy tắc tương thích (Compatibility). Điều này đảm bảo Consumer cũ vẫn đọc được dữ liệu mới mà không bị crash.
3. Tối ưu băng thông: Thay vì gửi toàn bộ chuỗi JSON dài dòng gồm cả tên trường (keys), Producer dùng Avro/Protobuf để mã hóa thành nhị phân cực kỳ nhỏ gọn, chỉ gửi kèm schema_id. Consumer nhận được sẽ dùng schema_id để tải cấu trúc từ Registry về và giải mã. Tốc độ parse dữ liệu của Go hay Node.js lúc này sẽ nhanh hơn rất nhiều.

2. Dead Letter Queue (DLQ): Khu vực cách ly "Vi khuẩn"

Dù có Schema Registry bảo vệ cấu trúc, hệ thống vẫn có thể gặp những bản tin hợp lệ về định dạng nhưng lại gây ra lỗi logic (Poison Pill).

Vấn đề thực tế (The Problem): Consumer lấy một bản tin giao dịch hợp lệ về, nhưng khi thực hiện lệnh truy vấn vào Database thì bị lỗi (ví dụ: trỏ đến một station_id không tồn tại trong hệ thống, hoặc DB đang bị lock). Lúc này, theo nguyên tắc At-least-once (Bài 4), Consumer chưa thể gửi Commit báo cáo "Đã đọc". Nó đành phải thử lại (Retry).

• Nó thử lại lần 1: Lỗi.
• Thử lại lần 2: Lỗi.
• Thử lại lần 100: Vẫn lỗi.

Hậu quả: Bản tin này trở thành một "cục máu đông". Nó kẹt lại ở đầu hàng đợi, khiến Consumer cứ xoay vòng xử lý nó mãi, làm cho hàng triệu bản tin bình thường xếp phía sau bị nghẽn lại (Head-of-line blocking).

Giải pháp: Thiết kế Dead Letter Queue (DLQ) DLQ thực chất chỉ là một Kafka Topic thông thường (ví dụ: đặt tên là afc_transactions_dlq), nhưng mang ý nghĩa là "Thùng rác tái chế" hoặc "Khu vực cách ly".

Sơ đồ xử lý chuẩn mực:

1. Giới hạn số lần thử (Max Retries): Cấu hình Consumer để chỉ thử lại một số lần nhất định (VD: 3 lần).
2. Cách ly: Nếu sau 3 lần vẫn lỗi, Consumer sẽ chủ động gửi bản tin này sang topic DLQ, kèm theo lý do lỗi (Error Header).
3. Bỏ qua và Đi tiếp: Sau khi vứt bản tin lỗi sang DLQ, Consumer lập tức "Đánh dấu đã đọc" (Commit) bản tin đó ở topic chính, và thong thả xử lý hàng triệu bản tin đang xếp hàng phía sau. Dòng chảy dữ liệu được khơi thông.
4. Xử lý hậu kỳ: Kỹ sư bảo trì sẽ có một công cụ (hoặc một Consumer phụ) chuyên theo dõi Topic DLQ này. Khi có cảnh báo (Alert) bắn về Telegram hoặc Slack, kỹ sư sẽ mở bản tin trong DLQ ra kiểm tra nguyên nhân cốt lõi (Root Cause), sửa lại dữ liệu (hoặc sửa code), sau đó mới phát lại (Replay) bản tin đó vào hệ thống.

Việc kết hợp Schema Registry (Phòng bệnh từ xa) và Dead Letter Queue (Cách ly chữa bệnh cục bộ) chính là tiêu chuẩn vàng để biến mọi hệ thống dựa trên Apache Kafka trở nên "Bất bại" trước các sự cố dữ liệu.