Trong bài viết này
Từ được đánh dấu có giải thích. Di chuột hoặc chạm để xem, hay mở từ điển AI.
Một yêu cầu tạo bản tóm tắt bị giới hạn lưu lượng. Ứng dụng lập tức gửi lại, rồi gửi lại tiếp. Những khách hàng khác cũng làm tương tự. Thay vì chờ dịch vụ hồi phục, hệ thống tạo thêm tải đúng lúc dịch vụ đang thiếu năng lực xử lý.
Retry chỉ hữu ích khi lỗi có khả năng hết và việc thử lại còn nằm trong ngân sách thời gian, chi phí, tác động cho phép.
Phân loại trước khi thử lại
Đầu vào sai schema thường cần sửa dữ liệu, không cần lặp nguyên yêu cầu. Lỗi xác thực cần kiểm tra cấu hình. Lỗi tạm thời do mạng hoặc phía dịch vụ có thể phù hợp để thử lại. Giới hạn lưu lượng cần giảm nhịp gửi và tôn trọng hướng dẫn chờ từ nhà cung cấp nếu có.
Theo AWS Builders’ Library về timeout và retry, thử lại có thể làm tăng tải; lỗi hoặc timeout cũng không chứng minh thao tác có tác dụng phụ chưa diễn ra. Hai nhận xét này đặc biệt quan trọng khi AI gọi công cụ ghi dữ liệu.
Giữ mã lỗi gốc trong nhật ký nội bộ. Nếu mọi lỗi đều biến thành “AI bận”, nhóm vận hành không biết đang gặp đầu vào sai, mạng chậm hay giới hạn tài khoản.
Dùng một hạn chót cho cả công việc
Giả sử sản phẩm đặt ngân sách giả định là một khoảng chờ tối đa cho việc tạo nháp. Mỗi lần gọi, thời gian chờ và lần thử lại đều phải nằm trong cùng khoảng đó. Đặt timeout riêng cho từng lần nhưng không có hạn chót tổng có thể khiến người dùng đợi mãi.
Pseudocode minh họa:
khi còn thời gian và chưa hết số lần thử:
gọi dịch vụ với thời gian còn lại
nếu thành công: trả kết quả
nếu lỗi không thể thử lại: dừng
chờ backoff có độ lệch ngẫu nhiên, trong ngân sách còn lại
trả trạng thái chưa hoàn thành và đường xử lý tiếpBackoff tăng khoảng chờ giữa các lần. Độ lệch ngẫu nhiên, thường gọi là jitter, tránh nhiều khách hàng thức dậy đúng cùng một thời điểm. Đừng ngủ quá hạn chót chỉ vì công thức backoff trả ra một khoảng dài.
Không nhân retry ở mọi tầng
Trình duyệt, máy chủ ứng dụng, SDK và hàng đợi đều có thể tự thử lại. Nếu mỗi tầng không biết tầng dưới đang làm gì, số lần gọi thực tế tăng nhanh ngoài dự kiến.
Chọn nơi sở hữu chính sách retry cho từng thao tác. Ghi số lần thử và mã công việc xuyên suốt các tầng để thấy tổng số yêu cầu. Khi dùng SDK, kiểm tra chính sách mặc định trước khi bọc thêm vòng lặp của riêng bạn.
Đối với tác vụ nền, hàng đợi có thể giữ công việc chờ thay vì buộc người dùng mở màn hình. Tuy nhiên, cần trạng thái có thể truy vấn và giới hạn tuổi công việc; một bản nháp đến sau khi người dùng đã đổi yêu cầu có thể không còn hữu ích.
API chuyển phần vận hành mô hình cho nhà cung cấp; tự vận hành đưa thêm trách nhiệm về phía đội ngũ của bạn. Cả hai lựa chọn đều cần kiểm tra quyền sử dụng, dữ liệu và chất lượng trên công việc cụ thể.
↔ Vuốt ngang để xem toàn bộ sơ đồ.
01 / Dùng API
Ứng dụng gửi yêu cầu tới dịch vụ vận hành mô hình. Cần kiểm tra điều khoản và chính sách xử lý dữ liệu.
02 / Tự vận hành
Mô hình chạy trên hạ tầng do bạn quản lý, nếu giấy phép và phần mềm cho phép.
03 / Rõ trách nhiệm
Với tự vận hành, đội ngũ lo tài nguyên, cập nhật và giám sát. Cả hai cách vẫn cần kiểm soát luồng dữ liệu của ứng dụng.
04 / Thử đúng công việc
Đo chất lượng tiếng Việt, thời gian, tổng chi phí và công sức sửa lỗi trên cùng nhiệm vụ trước khi chọn.
Đây là khung so sánh, không phải kết luận về một nhà cung cấp hay cấu hình cụ thể. Tải được trọng số không tự động đồng nghĩa với mã nguồn mở.
Phân biệt sinh lại với thực thi lại
Sinh lại văn bản có thể tạo nội dung khác và phát sinh chi phí. Thực thi lại công cụ đặt lịch có thể tạo thêm cuộc hẹn. Hai loại thử lại cần chính sách khác nhau.
Với thao tác ghi, dùng định danh công việc và cơ chế idempotency phía dịch vụ. Khi timeout sau khi gửi lệnh, tra trạng thái theo định danh đó trước khi tạo lệnh mới. “Chưa nhận phản hồi” phải được biểu diễn như chưa xác định, không tự đổi thành thất bại.
Lỗi thường gặp là tạo một mã idempotency mới ở mỗi lần retry. Khi ấy dịch vụ nhìn thấy các yêu cầu độc lập và không thể chống lặp. Mã phải gắn với hành động mà người dùng đã yêu cầu, trong phạm vi thời gian và ngữ nghĩa được thiết kế.
Bài tập: ba lỗi, ba quyết định
Mô phỏng ba tình huống: đầu vào thiếu trường bắt buộc, dịch vụ trả giới hạn lưu lượng và đặt phòng timeout sau khi máy chủ đã lưu. Viết quyết định xử lý cùng trạng thái hiển thị cho từng trường hợp.
Tiêu chí đạt: không retry đầu vào sai nguyên trạng, có nhịp chờ hữu hạn khi bị giới hạn, và kiểm tra kết quả đặt phòng trước khi gửi lại. Cuối cùng, đếm tổng lượt gọi qua mọi tầng để xác nhận ngân sách thực tế khớp thiết kế.