Trong kiến trúc Microservices, tại sao việc sử dụng Redis Pub/Sub để thực hiện Cache Invalidation lại tiềm ẩn rủi ro về tính nhất quán dữ liệu và giải pháp thay thế nào là tối ưu hơn?

Question

Accepted Answer

Phân tích rủi ro
Redis Pub/Sub là cơ chế 'fire and forget', nghĩa là nếu một instance của service bị gián đoạn mạng hoặc quá tải ngay tại thời điểm tin nhắn được gửi, nó sẽ mất thông báo xóa cache. Điều này dẫn đến tình trạng stale data kéo dài cho đến khi TTL hết hạn.
Giải pháp tối ưu
Thay vì dựa vào Pub/Sub, hệ thống Enterprise nên sử dụng các giải pháp dựa trên log như Debezium kết hợp với Kafka. Quy trình như sau:

Thay đổi dữ liệu tại Database được ghi lại vào Transaction Log.
Debezium đọc log này và đẩy sự kiện thay đổi vào Kafka.
Các service tiêu thụ (consume) sự kiện từ Kafka để thực hiện xóa cache.

Cách tiếp cận này đảm bảo tính 'at-least-once delivery', giúp hệ thống đồng bộ cache một cách tin cậy ngay cả khi các instance gặp sự cố tạm thời.

Trong kiến trúc Microservices, tại sao việc sử dụng Redis Pub/Sub để thực hiện Cache Invalidation lại tiềm ẩn rủi ro về tính nhất quán dữ liệu và giải pháp thay thế nào là tối ưu hơn?

Phân tích rủi ro

Làm Chủ Phỏng Vấn & Nâng Cao Trình Độ Chuyên Nghiệp

Tải Tuyển Tập 100+ Câu Hỏi Phỏng Vấn Chuyên Sâu (PDF)

Cần Mentor Phỏng Vấn Thử 1-1 & Tối Ưu CV?

Kiểm Tra CV Chuẩn ATS Miễn Phí

Câu hỏi caching liên quan cùng chủ đề