Họ đang đo gì
Bạn có nghĩ tới trạng thái trung gian và nghiệp vụ của việc huỷ không, hay chỉ nghĩ tới đường thành công.
Trả lời ngắn~30 giây
Saga: chia thành các bước cục bộ, mỗi bước có một hành động BÙ TRỪ tương ứng, và khi một bước lỗi thì chạy ngược các hành động bù trừ của những bước đã xong. Điểm quan trọng là bù trừ không phải rollback: bạn không xoá dấu vết mà tạo một sự kiện mới — hoàn tiền chứ không phải huỷ khoản trừ tiền — và có những thứ không bù trừ được, ví dụ email đã gửi đi rồi.
Giải thích sâu
Hai kiểu điều phối. Choreography: mỗi dịch vụ lắng nghe sự kiện và tự quyết định bước tiếp theo — ít hạ tầng, nhưng không ai nhìn thấy toàn bộ luồng và việc gỡ rối trở thành đọc log ở bốn nơi. Orchestration: một dịch vụ điều phối gọi từng bước và giữ trạng thái — thêm một thành phần, đổi lại luồng nằm ở một chỗ đọc được. Với quy trình có nhiều hơn ba bước, mình gần như luôn chọn orchestration.
Điều phải chấp nhận là saga cho ATOMICITY nhưng không cho ISOLATION: giữa hai bước, thế giới nhìn thấy một trạng thái nửa vời — kho đã trừ nhưng tiền chưa thu. Người khác có thể ra quyết định dựa trên trạng thái đó. Cách xử lý thường dùng là làm cho trạng thái trung gian trở thành một trạng thái NGHIỆP VỤ hợp lệ và hiển thị được: “đang giữ chỗ”, “chờ thanh toán” — thay vì giả vờ nó không tồn tại.
Và bù trừ cũng có thể lỗi. Đó là chỗ saga khác hẳn transaction: nếu hoàn tiền thất bại, không có tầng nào bên dưới cứu bạn. Thực tế thì bạn cần retry cho bù trừ, một trạng thái “cần can thiệp thủ công”, và một hàng đợi để người thật xử lý. Nói ra được điều này là dấu hiệu đã vận hành saga thật chứ không chỉ vẽ sơ đồ.
Câu hỏi tiếp theo họ sẽ hỏi
?Làm sao biết saga đang kẹt?
Mỗi phiên bản saga phải có timeout riêng và một trạng thái lưu bền. Cảnh báo dựa trên tuổi của saga chưa kết thúc, chứ không dựa vào lỗi — saga kẹt thường không ném lỗi nào cả, nó chỉ ngừng tiến triển, và đó là loại sự cố im lặng nhất.
Trả lời thế này là mất điểm
- Đề xuất transaction phân tán 2PC. Kafka và phần lớn broker không hỗ trợ XA, và coordinator chết là mọi bên treo ở trạng thái nghi vấn.
- Giả định mọi bước đều bù trừ được. Email đã gửi và tin nhắn đã bắn thì không.