# Làm thế nào để tránh tạo trùng tác vụ video khi yêu cầu API hết thời gian chờ? > Ngăn tác vụ video bị tạo trùng bằng cách gán cho mỗi đầu ra dự kiến một khóa thao tác ổn định, lưu yêu cầu trước khi gửi, dùng cơ chế idempotency được nhà cung cấp tài liệu hóa khi có, và đối soát các lần hết thời gian chờ có kết quả chưa rõ trước khi thử lại. Hết thời gian chờ nghĩa là chưa biết kết quả, không có nghĩa nhà cung cấp đã từ chối tác vụ. # Làm thế nào để tránh tạo trùng tác vụ video khi yêu cầu API hết thời gian chờ? Một lần gửi yêu cầu bị timeout tạo ra kết quả mơ hồ. Yêu cầu có thể thất bại trước khi đến dịch vụ, đến dịch vụ nhưng bị từ chối, hoặc đã tạo một tác vụ video từ xa nhưng phản hồi không quay về máy khách. Vì vậy, thử lại ngay có thể biến một clip dự kiến thành hai lần tạo có tính phí. Giải pháp là đặt một lớp thao tác idempotent quanh API video. Trước tiên hãy tạo và lưu thao tác dự kiến, gán cho nó một khóa ổn định, ghi lại từng lần gửi và dùng cơ chế idempotency hoặc tra cứu đã được nhà cung cấp tài liệu hóa. Nếu không thể chứng minh kết quả từ xa, hãy chuyển thao tác sang trạng thái `unknown` rõ ràng thay vì giả định rằng nó đã thất bại. ## Xác định một tác động dự kiến Khóa idempotency phải nhận diện thứ người dùng yêu cầu hệ thống tạo ra. Nó không được đại diện cho một lần gọi HTTP riêng lẻ. Nếu mỗi lần thử lại nhận một khóa mới, nhà cung cấp không có cách nhận ra yêu cầu trùng. Trong quy trình xử lý danh mục, một thao tác có thể được xác định bởi: * ID sản phẩm; * phiên bản mẫu sáng tạo; * dấu vân tay của nội dung nguồn; * phiên bản prompt; * ngôn ngữ; * tỷ lệ khung hình; * tên biến thể. Hãy tạo một biểu diễn chuẩn hóa với thứ tự khóa ổn định và giá trị đã chuẩn hóa, rồi băm biểu diễn đó. Lưu các chiều dữ liệu dễ đọc bên cạnh giá trị băm. Khi người dùng cố ý yêu cầu một lần tạo độc lập khác, hệ thống phải tạo thao tác hoặc biến thể mới, ngay cả khi prompt tình cờ giống hệt. Đừng dùng UUID ngẫu nhiên được tạo bên trong vòng lặp thử lại. Hãy tạo khóa thao tác trước yêu cầu đầu tiên và dùng lại nó cho đến khi tác động dự kiến đạt trạng thái kết thúc. ## Lưu trước khi gửi Cơ sở dữ liệu cục bộ phải biết về thao tác trước khi lệnh gọi mạng bắt đầu. Đây là nguyên tắc ghi trước được áp dụng cho tác động của API. Một bản ghi thao tác có thể gồm: | Trường | Mục đích | |---|---| | Khóa thao tác | Ngăn ý định cục bộ trùng lặp | | Hàm băm yêu cầu | Chứng minh bộ tham số đã gửi | | Trạng thái | Phân biệt đã chuẩn bị, đã gửi, chưa xác định và hoàn tất | | Số lần thử | Áp dụng chính sách thử lại có giới hạn | | Nhà cung cấp và mô hình | Hỗ trợ định tuyến và đối soát | | ID tác vụ từ xa | Tiếp tục thăm dò mà không gửi lại | | Lỗi gần nhất | Giữ lại bối cảnh chẩn đoán | | Checksum đầu ra | Phát hiện nội dung trùng hoặc bị thay đổi | Dùng ràng buộc duy nhất trong cơ sở dữ liệu cho khóa thao tác. Hai worker cố tạo cùng một thao tác phải hội tụ về một bản ghi. Trước khi gửi yêu cầu, hãy nhận quyền xử lý bản ghi bằng cập nhật nguyên tử hoặc lease. ## Chỉ dùng idempotency của nhà cung cấp theo tài liệu Một số API chấp nhận khóa idempotency hoặc request token và trả về kết quả của yêu cầu được chấp nhận đầu tiên khi cùng khóa được gửi lại. Đây là con đường chắc chắn nhất khi tài liệu nêu rõ endpoint áp dụng, thời gian lưu khóa, cách so sánh tham số và hành vi lỗi. Hãy xác minh bốn điểm: * endpoint tạo video có hỗ trợ khóa hay không; * nhà cung cấp ghi nhớ khóa trong bao lâu; * cùng khóa nhưng khác tham số có bị từ chối không; * lần thử lại có trả về ID tác vụ từ xa ban đầu không. Đừng cho rằng một header được hỗ trợ cho thanh toán hoặc yêu cầu văn bản đồng bộ cũng áp dụng cho tác vụ video bất đồng bộ. Hình dạng yêu cầu tương thích OpenAI không tự động khiến việc tạo tác vụ riêng của nhà cung cấp trở nên idempotent. ## Xem timeout là kết quả chưa xác định Hãy dùng các trạng thái mô tả bằng chứng thay vì kỳ vọng. | Trạng thái | Bằng chứng | Hành động tiếp theo | |---|---|---| | `prepared` | Bản ghi cục bộ tồn tại, chưa bắt đầu gửi | Gửi yêu cầu | | `sending` | Worker đã bắt đầu yêu cầu | Chờ kết quả hoặc timeout | | `accepted` | Đã nhận ID tác vụ từ xa | Thăm dò | | `unknown` | Timeout xảy ra mà chưa xác nhận kết quả | Đối soát | | `failed` | Nhà cung cấp từ chối rõ ràng hoặc tác vụ kết thúc lỗi | Áp dụng chính sách lỗi | | `complete` | Đầu ra đã được lưu bền vững | Trả về kết quả hiện có | Sự khác biệt giữa `unknown` và `failed` là thiết yếu. Ngoại lệ mạng là bằng chứng về kết nối của máy khách, không nhất thiết là bằng chứng về công việc của nhà cung cấp. Gắn khóa thao tác cục bộ vào metadata của nhà cung cấp khi API có client reference hoặc đối tượng metadata. Nhờ vậy, truy vấn danh sách hoặc yêu cầu hỗ trợ sau này có một dấu mốc ổn định để tìm kiếm. ## Đối soát trước khi thử lại Worker đối soát điều tra một thao tác chưa xác định. Bằng chứng có thể sử dụng tùy nhà cung cấp, nhưng thứ tự xử lý cần có chủ đích. 1. Kiểm tra xem lần thử ban đầu có lưu ID tác vụ từ xa trước khi tiến trình thất bại hay không. 2. Truy vấn nhà cung cấp bằng khóa idempotency hoặc client reference nếu được hỗ trợ. 3. Tìm trong danh sách tác vụ có giới hạn bằng thời gian tạo, mô hình và dấu vân tay yêu cầu. 4. Kiểm tra sự kiện webhook có thể đến sau khi máy khách timeout. 5. So sánh sự kiện thanh toán hoặc sử dụng nếu chúng xuất hiện đủ nhanh để hỗ trợ. 6. Chỉ thử lại khi hệ thống chứng minh được không có tác vụ hoặc khi idempotency đã được tài liệu hóa khiến lần thử lại an toàn. So khớp chỉ bằng thời gian và prompt có thể tạo kết quả dương tính giả. Hãy dùng nhiều thuộc tính và đưa các kết quả không chắc chắn sang xem xét. Nếu API không có tra cứu và không cam kết idempotency, chính sách đúng có thể là chờ, chấp nhận khả năng trùng, hoặc yêu cầu con người quyết định dựa trên chi phí clip và thời hạn. ## Tách thử lại truyền tải khỏi thử lại thao tác Thư viện HTTP thường tự động thử lại lỗi mạng. Cách này hữu ích cho thao tác đọc an toàn nhưng rủi ro với lệnh gửi có tác động. Hãy tắt thử lại POST chung trừ khi thao tác được bảo vệ bởi khóa idempotency ổn định và endpoint có tài liệu rõ ràng. Dùng hai bộ đếm: * số lần thử truyền tải để gửi cùng một thao tác được bảo vệ; * số lần thử tạo nội dung để cố ý tạo đầu ra thay thế sau lỗi kết thúc hoặc sau khi đầu ra bị loại vì chất lượng. Hai bộ đếm đại diện cho hai loại chi phí khác nhau. Một lần thử lại truyền tải phải hội tụ về cùng tác vụ từ xa. Một lần thử tạo nội dung là một lần sáng tạo mới có tính phí và cần danh tính riêng, dù vẫn liên kết với tác vụ sản xuất ban đầu. ## Xử lý worker đồng thời bằng lease Timeout không phải nguồn duy nhất gây trùng. Hai worker có thể lấy cùng một mục hàng đợi, hoặc một worker chậm vẫn tiếp tục sau khi khóa của nó hết hạn. Nhận việc bằng lease nguyên tử gồm chủ sở hữu, thời điểm nhận và thời điểm hết hạn. Trước khi gửi, worker xác nhận nó vẫn sở hữu lease và chưa có tác vụ từ xa được chấp nhận nào được ghi lại. Lưu ID tác vụ từ xa trong một giao dịch hoặc cập nhật compare-and-set sẽ thất bại nếu worker khác đã đưa thao tác tiến lên. Dùng fencing token khi worker cũ vẫn có thể ghi. Mỗi lần nhận lease làm tăng một phiên bản. Cơ sở dữ liệu chỉ chấp nhận thay đổi trạng thái từ phiên bản mới nhất, nhờ đó tiến trình cũ không thể ghi đè kết quả mới hơn. ## Thiết kế webhook và polling để hội tụ Tác vụ video là bất đồng bộ, vì vậy polling và webhook có thể báo cùng một chuyển trạng thái. Trình xử lý của chúng cũng phải idempotent. Loại bỏ sự kiện webhook trùng bằng ID sự kiện của nhà cung cấp khi có. Đồng thời áp dụng cập nhật trạng thái có điều kiện: sự kiện `processing` không được đưa tác vụ lùi từ `complete`. Việc tải cùng đầu ra hai lần phải ghi vào một khóa tạm thời xác định trước, xác minh checksum và hội tụ về một đối tượng bền vững cuối cùng. Đường hoàn tất thành công phải an toàn khi lặp lại: ```text nhận thông báo hoàn tất tìm thao tác bằng ID tác vụ từ xa sao chép đầu ra vào khóa lưu trữ xác định trước xác minh tệp media và checksum ghi URI bền vững đánh dấu thao tác hoàn tất nếu chưa hoàn tất ``` Nếu bất kỳ bước nào bị lỗi tiến trình, trình xử lý tiếp theo có thể bắt đầu lại mà không tạo video mới. ## Ghi đủ bằng chứng để kiểm toán bản trùng Với mỗi lần thử, hãy giữ lại mốc thời gian trước và sau khi gửi, loại timeout, hàm băm yêu cầu, khóa idempotency, header phản hồi của nhà cung cấp, ID từ xa và quyết định thử lại. Che thông tin xác thực và dữ liệu prompt nhạy cảm. Theo dõi các chỉ số vận hành: | Chỉ số | Điều được thể hiện | |---|---| | Lần gửi chưa xác định | Mơ hồ do mạng hoặc nhà cung cấp | | Đối soát mà không thử lại | Số bản trùng được tránh thành công | | Số lần thử lại được bảo vệ | Hành vi idempotency khi có lỗi | | Tác vụ nghi bị trùng | Rủi ro tài chính còn lại | | Checksum đầu ra trùng | Kết quả giống nhau hoặc lặp lại từ nhà cung cấp | | Thời gian ở trạng thái chưa xác định | Tốc độ phục hồi | Cảnh báo khi số kết quả chưa xác định tăng bất thường trước khi chỉ đơn giản tăng giới hạn thử lại. Suy giảm mạng kết hợp với thử lại quyết liệt có thể nhanh chóng nhân chi phí. ## Đặt hành vi nhà cung cấp sau một adapter Ứng dụng dùng nhiều mô hình nên cung cấp một giao diện gửi nội bộ với cờ năng lực của nhà cung cấp. Adapter chịu trách nhiệm về schema endpoint, cơ chế idempotency, tra cứu tác vụ, ánh xạ trạng thái và trích xuất đầu ra. [Atlas Cloud](https://www.atlascloud.ai/?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=avoid-duplicate-video-jobs-api-timeout) có thể giảm công sức tích hợp cho đội ngũ dùng mô hình văn bản, hình ảnh và video thông qua một nền tảng tương thích OpenAI. Tuy vậy, vẫn cần xác minh hành vi hiện tại của đúng mô hình và endpoint video. Tính tương thích chuẩn hóa nhiều mẫu yêu cầu, nhưng không nên được xem là lời hứa phổ quát về idempotency của tác vụ bất đồng bộ. Trả về kết quả chuẩn hóa như đã chấp nhận kèm ID từ xa, bị từ chối rõ ràng, hoặc chưa xác định. Đừng biến ngoại lệ truyền tải thành lỗi nhà cung cấp bên trong adapter. ## Chủ động kiểm thử các trường hợp mơ hồ Luồng thành công không chứng minh được khả năng chống trùng. Trong môi trường staging, hãy tiêm lỗi trước khi gửi, sau khi byte rời máy khách, sau khi nhà cung cấp chấp nhận, sau khi nhận phản hồi nhưng trước khi cập nhật cơ sở dữ liệu, và trong lúc giao webhook. Với mỗi trường hợp, hãy khẳng định rằng một thao tác dự kiến tạo không quá một tác vụ từ xa khi nhà cung cấp hỗ trợ idempotency. Nếu không hỗ trợ, hãy khẳng định thao tác đi vào `unknown`, tạm dừng gửi lại tự động và cung cấp đủ bằng chứng cho chính sách đã chọn. Đồng thời kiểm thử worker chạy song song, lease hết hạn, webhook đến muộn, webhook lặp, tiến trình khởi động lại và việc tái sử dụng khóa cũ với tham số khác. Các kiểm thử này rẻ hơn nhiều so với phát hiện tác vụ tạo trùng qua hóa đơn. ## Kết luận Hãy tránh tác vụ video trùng bằng cách gán cho mỗi đầu ra dự kiến một khóa thao tác bền vững và tách thao tác đó khỏi các lần gọi HTTP. Lưu ý định trước khi gửi, dùng idempotency đã được tài liệu hóa và xem timeout là kết quả chưa xác định cần đối soát. Với lease, thay đổi trạng thái có điều kiện, trình xử lý hoàn tất idempotent và nhật ký lần thử bền vững, việc thử lại trở thành phục hồi có kiểm soát thay vì một lần mua lặp ngoài ý muốn. ## FAQ ### HTTP timeout có nghĩa là API video không tạo tác vụ phải không? Không. Nhà cung cấp có thể đã chấp nhận yêu cầu và tạo tác vụ dù máy khách không nhận được phản hồi. Hãy xem kết quả là chưa xác định cho đến khi đối soát xong. ### Khóa idempotency nên đại diện cho điều gì? Nó nên đại diện cho một tác động dự kiến, chẳng hạn một sản phẩm, phiên bản mẫu, ngôn ngữ, tỷ lệ khung hình và biến thể. Hãy dùng lại khóa đó khi thử lại cùng thao tác, nhưng tạo khóa mới cho đầu ra thực sự mới. ### Ràng buộc duy nhất trong cơ sở dữ liệu có ngăn được mọi bản trùng không? Nó ngăn thao tác cục bộ trùng lặp, nhưng tự nó không thể ngăn nhà cung cấp chấp nhận hai yêu cầu. Hãy kết hợp với idempotency của nhà cung cấp hoặc một quy trình đối soát. ### Máy khách có nên tự động thử lại mọi lần timeout không? Không. Chỉ nên tự động thử lại khi yêu cầu có tính idempotent hoặc có thể xác định kết quả phía nhà cung cấp. Nếu không, hãy đưa tác vụ vào trạng thái chưa xác định và đối soát trước. ### Nên lưu bản ghi idempotency trong bao lâu? Ít nhất phải lâu bằng cửa sổ thử lại, cửa sổ tra cứu của nhà cung cấp, thời hạn khiếu nại thanh toán và nhu cầu kiểm toán vận hành. Hãy chọn thời gian theo hành vi đã được nhà cung cấp tài liệu hóa và rủi ro kinh doanh. ### API tương thích OpenAI có bảo đảm hành vi idempotency giống nhau giữa các mô hình video không? Không. Tính tương thích có thể chuẩn hóa lớp truyền tải, nhưng việc tạo tác vụ bất đồng bộ và hỗ trợ idempotency vẫn có thể phụ thuộc vào mô hình hoặc nhà cung cấp. Hãy kiểm tra tài liệu hiện hành của endpoint cụ thể.