Google Ads API thực thi giới hạn số lượng yêu cầu theo số truy vấn mỗi giây (QPS) trên cả mã khách hàng và dự án trên đám mây của Google một cách độc lập. Ngoài số yêu cầu mỗi phút (đo lường tần suất của lệnh gọi API), Google Ads API cũng thực thi giới hạn về số thao tác mỗi phút (đo lường tổng số thao tác API trên các yêu cầu). Google Ads API sử dụng thuật toán thùng đựng thẻ để đo lường các yêu cầu và xác định giới hạn QPS thích hợp, vì vậy, giới hạn chính xác sẽ thay đổi tuỳ thuộc vào tổng tải của máy chủ tại bất kỳ thời điểm nào.
Mục đích của việc áp đặt giới hạn tần suất là để ngăn một người dùng làm gián đoạn dịch vụ cho những người dùng khác bằng cách (cố ý hoặc vô tình) gửi một lượng lớn yêu cầu đến máy chủ Google Ads API.
Những yêu cầu vi phạm giới hạn số lượng yêu cầu sẽ bị từ chối kèm theo lỗi:
RESOURCE_TEMPORARILY_EXHAUSTED.
Bạn có thể kiểm soát ứng dụng và giảm thiểu giới hạn số lượng yêu cầu bằng cách chủ động giảm số lượng yêu cầu và điều tiết QPS từ phía máy khách.
Có một số cách để giảm khả năng vượt quá giới hạn tốc độ. Việc làm quen với các khái niệm Mẫu tích hợp doanh nghiệp (EIP) như nhắn tin, gửi lại và điều tiết có thể giúp bạn xây dựng một ứng dụng khách mạnh mẽ hơn.
Các phương pháp hay nhất sau đây được sắp xếp theo độ phức tạp, với các chiến lược đơn giản hơn ở trên cùng và các cấu trúc mạnh mẽ nhưng phức tạp hơn ở phía sau:
- Thuật toán thời gian đợi luỹ thừa
- Giới hạn số lượng tác vụ đồng thời
- Yêu cầu theo lô
- Điều tiết và giới hạn tốc độ
- Đang xếp hàng
Thuật toán thời gian đợi luỹ thừa
Khi ứng dụng của bạn nhận được lỗi RESOURCE_TEMPORARILY_EXHAUSTED, hãy sử dụng chính sách thời gian đợi luỹ thừa có độ trễ ngẫu nhiên trước khi thử lại yêu cầu không thành công. Thuật toán thời gian đợi tăng theo cấp luỹ thừa sẽ tăng dần thời gian chờ giữa các lần thử lại (ví dụ: chờ 2 giây, sau đó là 4 giây, sau đó là 8 giây, cộng với một độ trễ ngẫu nhiên nhỏ), cho phép tải máy chủ và bộ chứa hạn mức khôi phục, đồng thời ngăn chặn các mức tăng đột biến thử lại đồng bộ trên các phiên bản ứng dụng.
Giới hạn số tác vụ đồng thời
Một nguyên nhân gốc rễ của việc vượt quá giới hạn tốc độ là ứng dụng khách đang tạo ra quá nhiều tác vụ song song. Mặc dù chúng tôi không giới hạn số lượng yêu cầu song song mà một ứng dụng khách có thể có, nhưng số lượng này có thể vượt quá giới hạn số yêu cầu mỗi giây ở cấp dự án trên đám mây của Google Cloud.
Bạn nên đặt giới hạn trên hợp lý cho tổng số tác vụ đồng thời sẽ thực hiện yêu cầu (trên tất cả quy trình và máy), đồng thời điều chỉnh tăng lên để tối ưu hoá công suất mà không vượt quá giới hạn số lượng yêu cầu.
Hơn nữa, bạn có thể cân nhắc việc điều tiết QPS từ phía máy khách (xem phần Điều tiết và giới hạn tốc độ).
Yêu cầu theo lô
Hãy cân nhắc việc gộp nhiều thao tác vào một yêu cầu. Điều này thường áp dụng cho các cuộc gọi Mutate cho nhiều dịch vụ. Ví dụ: nếu đang cập nhật trạng thái cho nhiều thực thể của AdGroupAd, bạn có thể gọi MutateAdGroupAds một lần và truyền nhiều operations thay vì gọi MutateAdGroupAds một lần cho mỗi AdGroupAd. Hãy tham khảo hướng dẫn về thao tác hàng loạt của chúng tôi để biết thêm một số ví dụ.
Mặc dù việc gửi yêu cầu theo lô giúp giảm tổng số lệnh gọi API và giảm bớt giới hạn về số lượng yêu cầu mỗi phút, nhưng việc này có thể kích hoạt giới hạn về số lượng thao tác mỗi phút nếu bạn thực hiện nhiều thao tác đối với một tài khoản.
Điều tiết và giới hạn tốc độ
Ngoài việc giới hạn tổng số luồng trong ứng dụng, bạn cũng có thể triển khai bộ giới hạn tốc độ ở phía máy khách. Điều này đảm bảo tất cả các luồng trong quy trình, cụm hoặc cả hai đều chịu sự điều chỉnh của một giới hạn QPS cụ thể từ phía máy khách.
Hãy xem Guava RateLimiter hoặc triển khai thuật toán thùng đựng thẻ của riêng bạn cho môi trường theo cụm. Ví dụ: bạn có thể quản lý mã thông báo trong kho dữ liệu trong bộ nhớ phân tán, có độ trễ thấp như Redis hoặc Memcached, trong đó mỗi ứng dụng khách lấy và sử dụng một mã thông báo trước khi xử lý yêu cầu. Nếu hết mã thông báo, ứng dụng sẽ đợi cho đến khi đợt mã thông báo tiếp theo được bổ sung.
Danh sách chờ
Hàng đợi thông báo là giải pháp để phân phối tải hoạt động, đồng thời kiểm soát tỷ lệ yêu cầu và tỷ lệ người tiêu dùng. Có một số lựa chọn hàng đợi thông báo, một số là nguồn mở, một số là độc quyền và nhiều lựa chọn trong số đó có thể hoạt động với nhiều ngôn ngữ.
Khi sử dụng hàng đợi thông báo, bạn có thể có nhiều nhà sản xuất đẩy thông báo vào hàng đợi và nhiều người tiêu dùng xử lý các thông báo đó. Bạn có thể triển khai cơ chế điều tiết ở phía người tiêu dùng bằng cách giới hạn số lượng người tiêu dùng đồng thời hoặc bằng cách triển khai bộ giới hạn tốc độ hoặc bộ điều tiết cho nhà sản xuất hoặc người tiêu dùng.
Ví dụ: nếu người dùng thông báo gặp lỗi giới hạn tốc độ, thì người dùng đó có thể trả lại yêu cầu cho hàng đợi với độ trễ thử lại được chuẩn hoá (sử dụng thuật toán đợi luỹ thừa) và cập nhật vòng hồi tiếp giới hạn tốc độ dùng chung để tất cả người dùng tự động giảm tốc độ xử lý trong khi khôi phục sau lỗi.