Đơn hàng trùng lặp khi làm việc với API: nguyên nhân và cách phòng tránh

Tại sao đơn hàng trùng lặp xuất hiện sau một thao tác

Chủ sở hữu bảng điều khiển có thể nhấn nút một lần và thấy nhiều đơn hàng giống nhau: cho người theo dõi, lượt xem, lượt tương tác hoặc dịch vụ khác. Thông thường vấn đề không nằm ở chính cú nhấp chuột, mà ở chuỗi giữa máy khách, API, cơ sở dữ liệu và nhà cung cấp.

Từ góc độ máy chủ, "một yêu cầu" không phải lúc nào cũng chỉ là một. Máy khách có thể không nhận được phản hồi, gửi lại, trong khi thao tác đầu tiên đã kịp được lưu. Đôi khi đơn hàng được tạo một lần trong cơ sở dữ liệu của bảng điều khiển, nhưng lại được gửi đến nhà cung cấp hai lần. Đây là những tình huống khác nhau và được khắc phục theo cách khác nhau.

Timeout không có nghĩa là đơn hàng chưa được tạo

Nguyên nhân phổ biến nhất là máy khách chỉ chờ phản hồi trong một khoảng thời gian giới hạn. Máy chủ nhận yêu cầu, tạo đơn hàng, nhưng phản hồi muộn hơn thời gian timeout đã đặt. Máy khách coi thao tác là thất bại và gửi lại.

Kết quả là đơn hàng đầu tiên đã có trong cơ sở dữ liệu, còn yêu cầu thứ hai tạo thêm một đơn nữa. Điều này đặc biệt thường xảy ra khi API bên ngoài phản hồi chậm, hàng đợi quá tải hoặc kết nối giữa các dịch vụ không ổn định.

Timeout chỉ cho biết không có phản hồi, chứ không phải yêu cầu không được xử lý.

Tự động gửi lại phía máy khách

Các thư viện gửi yêu cầu HTTP, tác vụ nền và dịch vụ tích hợp thường tự động gửi lại yêu cầu. Nguyên nhân có thể là lỗi kết nối, mã phản hồi của máy chủ, mất mạng hoặc phản hồi quá lâu.

Bản thân việc gửi lại là hữu ích: nó giảm số đơn hàng bị mất khi có sự cố tạm thời. Nhược điểm của cách làm này là nếu không có biện pháp phòng tránh xử lý lặp lại, nó biến mọi sự bất ổn của mạng thành trùng lặp.

• việc gửi lại có thể được kích hoạt trong mã của trang web hoặc bot;
• hàng đợi có thể khởi động lại tác vụ;
• proxy hoặc mô-đun tích hợp có thể gửi lại yêu cầu;
• người vận hành có thể gửi lại đơn hàng thủ công sau khi gặp lỗi.

Yêu cầu lặp lại đến trước phản hồi đầu tiên

Đôi khi hai yêu cầu giống nhau thực sự đến API gần như cùng lúc. Ví dụ, người dùng gửi biểu mẫu hai lần, giao diện không khóa nút hoặc tác vụ nền khởi động lại trước khi tác vụ đầu tiên hoàn thành.

Nếu trình xử lý trước tiên kiểm tra sự tồn tại của đơn hàng rồi mới tạo nó, hai thao tác song song có thể cùng vượt qua bước kiểm tra. Mỗi thao tác sẽ thấy đơn hàng chưa tồn tại và mỗi thao tác sẽ thêm một bản ghi mới.

Tình huống này được gọi là tranh chấp dữ liệu. Việc kiểm tra sơ bộ đơn giản trong mã không bảo vệ hoàn toàn khỏi nó. Nhược điểm của việc kiểm tra mà không có ràng buộc ở cấp cơ sở dữ liệu là nó sẽ hỏng khi có tải song song.

Đơn hàng đã được ghi nhưng phản hồi API bị mất

Yêu cầu trải qua nhiều giai đoạn: máy chủ nhận dữ liệu, tạo bản ghi, đưa tác vụ vào hàng đợi, gửi phản hồi. Sự cố có thể xảy ra giữa bất kỳ giai đoạn nào. Ví dụ, cơ sở dữ liệu đã xác nhận tạo đơn hàng, nhưng kết nối bị ngắt trước khi phản hồi được truyền đến máy khách.

Máy khách không biết đơn hàng đã được chấp nhận hay chưa và gửi lại thao tác. API không có cơ chế kiểm tra riêng sẽ coi yêu cầu là mới. Trong nhật ký, điều này thường trông như thể dịch vụ đã "tự" tạo hai đơn hàng, mặc dù nó đã nhận hai yêu cầu đến.

Khóa bất biến (idempotency key) để tạo đơn hàng

Đối với các thao tác tạo, cần có khóa bất biến duy nhất. Máy khách tạo khóa này trước lần gửi đầu tiên và truyền nó cùng với các tham số của đơn hàng. Khi gửi lại do timeout hoặc lỗi, khóa đó được sử dụng lại.

API lưu khóa cùng với kết quả xử lý. Nếu có yêu cầu với khóa đã biết, máy chủ không tạo đơn hàng mới mà trả về kết quả của lần gọi đầu tiên: mã đơn hàng, trạng thái của nó hoặc lỗi đã được tạo trước đó.

Một khóa phải tương ứng với một thao tác nghiệp vụ, chứ không phải một kết nối HTTP.

Nhược điểm của phương pháp này là khóa cần được lưu trữ, dọn dẹp theo quy định và kiểm tra ở phía API. Nếu tạo khóa mới mỗi lần gửi lại, biện pháp phòng tránh sẽ không hoạt động. Nếu dùng một khóa cho các đơn hàng khác nhau, một số thao tác mới sẽ bị từ chối nhầm.

Tính duy nhất phải được kiểm soát bởi cơ sở dữ liệu

Tính bất biến nên được bổ sung bằng ràng buộc duy nhất trong cơ sở dữ liệu. Để làm điều này, người ta chọn một tổ hợp mô tả rõ ràng đơn hàng: mã định danh nội bộ của khách hàng, khóa bất biến, loại dịch vụ và các trường cần thiết khác.

Cơ sở dữ liệu phải từ chối bản ghi thứ hai, ngay cả khi hai trình xử lý cùng đến bước tạo một lúc. Sau xung đột, API trả về đơn hàng đã tồn tại, chứ không phải lỗi không có giải thích.

Nhược điểm của ràng buộc duy nhất cứng nhắc là không thể chỉ xây dựng nó dựa trên liên kết hoặc username. Khách hàng có thể cố ý đặt một dịch vụ cho cùng một kênh nhiều lần. Một ràng buộc quá rộng sẽ chặn các lần mua lại bình thường.

Hàng đợi có thể giao tác vụ nhiều hơn một lần

Hàng đợi tác vụ thường hoạt động theo nguyên tắc "giao ít nhất một lần". Nếu worker đã xử lý tác vụ nhưng chưa kịp xác nhận hoàn thành, hàng đợi có thể giao lại tác vụ đó cho một worker khác.

Đối với hàng đợi, đây là cách bình thường để không làm mất tác vụ. Đối với việc tạo đơn hàng không có tính bất biến, đây là nguồn gốc của trùng lặp. Mã định danh tác vụ hoặc khóa thao tác riêng cần được truyền đến trình xử lý cuối cùng, bao gồm cả mô-đun gửi đơn hàng đến nhà cung cấp.

Nhược điểm của việc tắt giao lại là khi worker gặp sự cố, một số đơn hàng có thể bị mất. An toàn hơn là chấp nhận các lần lặp lại có thể xảy ra và làm cho trình xử lý chịu được chúng.

Trùng lặp phát sinh giữa bảng điều khiển và nhà cung cấp

Đơn hàng nội bộ có thể được tạo một lần, nhưng yêu cầu đến API bên ngoài lại được gửi hai lần. Nguyên nhân cũng như vậy: bảng điều khiển không nhận được phản hồi từ nhà cung cấp và quyết định gửi lại. Nếu nhà cung cấp đã kịp chấp nhận yêu cầu đầu tiên, phía họ sẽ xuất hiện hai yêu cầu giống nhau.

Cần có liên kết riêng giữa đơn hàng nội bộ và đơn hàng bên ngoài: mã định danh gửi, khóa bất biến hoặc phản hồi đã lưu của nhà cung cấp. Không thể cho rằng biện pháp bảo vệ ở đầu vào bảng điều khiển của mình sẽ tự động bảo vệ các cuộc gọi đi.

Nhược điểm của việc đối chiếu với API bên thứ ba là không phải nhà cung cấp nào cũng hỗ trợ tìm kiếm theo khóa bên ngoài. Khi đó phải ghi lại các lần gửi và xử lý riêng các trạng thái không xác định.

Webhook không được tạo đơn hàng mới

Webhook thông báo về các thay đổi: đơn hàng được chấp nhận, đã khởi chạy, đã hoàn thành, đã hủy hoặc cần kiểm tra. Lỗi xảy ra khi trình xử lý webhook coi thông báo là lệnh tạo lại đơn hàng.

Cùng một webhook có thể đến lặp lại. Bên gửi lặp lại việc giao nếu không nhận được xác nhận, và các thông báo đôi khi đến không đúng thứ tự. Trình xử lý phải tìm đơn hàng đã tồn tại theo mã định danh bên ngoài và cập nhật trạng thái.

Nhược điểm của việc xử lý webhook chỉ theo thời gian nhận là thông báo đến muộn có thể ghi đè trạng thái hiện tại bằng trạng thái cũ. Cần có mã định danh sự kiện, phiên bản trạng thái hoặc quy tắc chuyển đổi rõ ràng.

Những bản ghi nào giúp tìm ra nguồn gốc trùng lặp

Để điều tra, chỉ nhìn thấy hai mã đơn hàng là không đủ. Cần dữ liệu về từng giai đoạn xử lý: thời gian yêu cầu, khóa bất biến, mã định danh khách hàng, tham số đơn hàng, mã tác vụ nền, phản hồi của API bên ngoài và các lần gửi lại.

• đối chiếu các bản trùng lặp theo khóa thao tác, chứ không chỉ theo liên kết;
• kiểm tra xem có các yêu cầu giống nhau trong nhật ký API đến hay không;
• xem tác vụ có bị lặp lại trong hàng đợi hay không;
• tách biệt việc tạo đơn hàng nội bộ với việc gửi đến nhà cung cấp;
• lưu mã định danh bên ngoài của yêu cầu ngay sau khi nhận phản hồi.

Nhược điểm của nhật ký quá ngắn là nguồn gốc vấn đề biến mất trước khi kịp phân tích. Nhược điểm của việc ghi nhật ký quá mức là token, dữ liệu cá nhân và các trường nhạy cảm khác có thể lọt vào bản ghi, vì vậy chúng cần được che giấu.

Cách xử lý kết quả yêu cầu không xác định

Sau timeout, không thể ngay lập tức tạo lại đơn hàng với dữ liệu mới. Trước tiên, API phải kiểm tra thao tác theo khóa bất biến hoặc mã định danh khách hàng. Nếu tìm thấy đơn hàng, trạng thái hiện tại của nó được trả về. Nếu quá trình xử lý vẫn đang diễn ra, máy khách nhận được trạng thái chờ.

1. Tạo khóa thao tác trước yêu cầu đầu tiên.
2. Gửi cùng khóa đó trong mỗi lần lặp lại.
3. Lưu khóa và đơn hàng trong cùng một thao tác cơ sở dữ liệu được bảo vệ.
4. Truyền mã định danh thao tác vào hàng đợi và API bên ngoài.
5. Trả về đơn hàng đã tạo trước đó khi có yêu cầu lặp lại.

Kịch bản như vậy đòi hỏi phải cải tiến API và tích hợp phía máy khách. Nhược điểm của nó là gỡ lỗi phức tạp hơn và có nhiều trạng thái đơn hàng hơn, nhưng bù lại, việc gửi lại yêu cầu không còn tự động đồng nghĩa với việc mua lại.