Tránh thao tác nghiệp vụ trùng lặp với yêu cầu idempotent

Người dùng bấm gửi, màn hình chờ rồi mất kết nối. Máy chủ có thể đã hoàn tất yêu cầu. Gửi lại với danh tính mới có thể tạo thêm lượt đặt chỗ hoặc chuyển khoản. Câu hỏi đúng không chỉ là có thử lại không, mà còn là hệ thống nhận ra cùng một ý định thao tác bằng cách nào.

Phân biệt ngữ nghĩa HTTP với bảo vệ nghiệp vụ

HTTP định nghĩa phương thức idempotent theo tác động dự kiến trên máy chủ: nhiều yêu cầu giống nhau có tác động dự kiến như một yêu cầu.[2] Điều đó không có nghĩa mọi phản hồi đều giống nhau hoặc mọi hoạt động nghiệp vụ xung quanh chỉ xảy ra đúng một lần. Không tự động áp dụng định nghĩa này cho một thao tác POST bất kỳ.

API nghiệp vụ có thể cung cấp cơ chế idempotency riêng. Với Stripe API v1, tài liệu mô tả việc lưu kết quả ban đầu sau khi bắt đầu thực thi và trả lại kết quả đó khi thử lại cùng khóa.[5] Đây là hợp đồng của nhà cung cấp cụ thể, không phải bảo đảm chung của HTTP.

Xác định danh tính và thời hạn của nó

Nên dùng một khóa cho một ý định thao tác nghiệp vụ. Giữ nguyên khóa qua lỗi kết nối và các lần thử lại. Một thao tác thực sự mới phải có khóa mới. Giới hạn phạm vi khóa theo khách hàng đã xác thực và loại thao tác để các khách hàng độc lập không va chạm.

Lưu dấu nhận diện của yêu cầu đã chuẩn hóa cạnh khóa. Từ chối nội dung khác tái sử dụng danh tính cũ. Xác định cách xử lý yêu cầu đồng thời, thời gian lưu và phản hồi khi công việc còn chạy. Nếu bản ghi hết hạn trước lúc yêu cầu thử lại đến muộn, hệ thống cần cách khác để nhận biết thao tác đã hoàn tất. Ghi rõ khoảng trống đó trong tài liệu.

Hỏi nhóm vận hành yêu cầu thử lại bị trì hoãn có thể xuất hiện trong bao lâu. Dùng khoảng khôi phục đó để chọn thời gian lưu, và quy định rằng thử lại ngoài khoảng được hỗ trợ phải qua quyết định xem xét có chủ đích.

Kiểm tra toàn bộ đường thực thi

Khóa ở đầu vào API không tự phối hợp cập nhật cơ sở dữ liệu, gọi nhà cung cấp và gửi thông báo. Nên có bản ghi thao tác bền vững cùng trạng thái khôi phục rõ ràng. Khi chưa biết kết quả bên ngoài, hãy đối soát trước khi bắt đầu một thao tác nghiệp vụ khác.

• Chọn chính xác thao tác nghiệp vụ mà khóa đại diện.
• Kiểm thử yêu cầu đồng thời cùng khóa và nội dung mâu thuẫn.
• Giữ bản ghi khóa nhất quán giao dịch với chuyển trạng thái nội bộ khi có thể.
• Quy định trách nhiệm về hết hạn, khôi phục và chống trùng ở hệ thống phía sau.

Ví dụ giả định: đặt thuê thiết bị

Ví dụ giả định: cổng thuê thiết bị tạo một lượt đặt nhưng trình duyệt không nhận được phản hồi. Trình duyệt gửi lại với khóa ban đầu. Dịch vụ tìm thấy bản ghi thao tác và trả mã đặt chỗ hiện có thay vì phân bổ thêm một thiết bị.

Nếu kết quả gọi nhà cung cấp vẫn chưa rõ, dịch vụ báo trạng thái chờ và tra cứu mã tham chiếu bên đó. Dịch vụ không âm thầm tạo một lượt đặt mới tại nhà cung cấp. Thiết kế này cần dung lượng lưu trữ và logic khôi phục. Hãy bắt đầu với thao tác mà việc trùng lặp gây chi phí vận hành lớn nhất, rồi kiểm tra các điểm lỗi quanh từng tác động ra bên ngoài.