API Google Ads thực thi việc giới hạn tốc độ theo số truy vấn mỗi giây (QPS) trên cả mã khách hàng và dự án trên Google Cloud 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 các lệnh gọi API), API Google Ads cũng thực thi các 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). API Google Ads sử dụng thuật toán vùng chứa mã thông báo để đo lường các yêu cầu và xác định giới hạn QPS phù hợp. Vì vậy, giới hạn chính xác sẽ thay đổi tuỳ thuộc vào tải tổng thể 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ốc độ 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) làm quá tải các máy chủ API Google Ads với số lượng lớn yêu cầu.
Các yêu cầu vi phạm giới hạn tốc độ sẽ bị từ chối và báo lỗi:
RESOURCE_TEMPORARILY_EXHAUSTED.
Bạn có thể kiểm soát ứng dụng của mình và giảm thiểu giới hạn tốc độ bằng cách chủ động giảm số lượng yêu cầu và điều tiết QPS từ phía ứng dụng.
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 về Mẫu tích hợp doanh nghiệp (EIP) chẳng hạn 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 mạnh mẽ hơn.
Các phương pháp được đề xuấ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 kiến 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ố tác vụ đồng thời
- Yêu cầu theo lô
- Bộ điều tiết và bộ giới hạn tốc độ
- Danh sách chờ
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 với độ 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 luỹ thừa sẽ tăng dần thời gian chờ giữa các lần thử lại (ví dụ: đợi 2 giây, sau đó 4 giây, sau đó 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 trong khi ngăn các mốc tăng đột biến thử lại được đồng bộ hoá trên các thực thể ứ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 đ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 có thể có, nhưng điều 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 Google Cloud.
Bạn nên đặt một giới hạn trên hợp lý cho tổng số tác vụ đồng thời sẽ đưa ra yêu cầu (trên tất cả các quy trình và máy) và điều chỉnh tăng lên để tối ưu hoá thông lượng mà không vượt quá giới hạn tốc độ.
Ngoài ra, bạn có thể cân nhắc việc điều tiết QPS từ phía ứng dụng (xem phần Bộ điều tiết và bộ giới hạn tốc độ).
Yêu cầu theo lô
Hãy cân nhắc việc tạo lô nhiều thao tác thành một yêu cầu. Điều này áp dụng nhiều nhất cho các lệnh gọi Mutate đối với nhiều dịch vụ. Ví dụ: nếu bạn đ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ề các thao tác theo lô để xem một số
ví dụ khác.
Mặc dù việc tạo lô các yêu cầu giúp giảm tổng số lệnh gọi API và giảm thiểu giới hạn tốc độ đối với số yêu cầu mỗi phút, nhưng thao tác này có thể kích hoạt giới hạn tốc độ số thao tác mỗi phút nếu bạn thực hiện một số lượng lớn thao tác đối với một tài khoản.
Bộ điều tiết và bộ 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 ứng dụng. Điều này đảm bảo rằng tất cả các luồng trên các 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 ứng dụng.
Hãy xem Guava RateLimiter hoặc triển khai thuật toán vùng chứa mã thông báo của riêng bạn cho môi trường được phân cụm. Ví dụ: bạn có thể quản lý mã thông báo trong một kho lưu trữ dữ liệu trong bộ nhớ có độ trễ thấp và được phân phối, chẳng hạn như Redis hoặc Memcached, trong đó mỗi ứng dụng sẽ thu thập và sử dụng một mã thông báo trước khi xử lý một yêu cầu. Nếu hết mã thông báo, ứng dụng sẽ đợi cho đến khi lô mã thông báo tiếp theo được bổ sung.
Danh sách chờ
Hàng đợi tin nhắn là giải pháp phân phối tải thao tác, đồng thời kiểm soát tốc độ yêu cầu và tốc độ người dùng. Có một số lựa chọn về hàng đợi tin nhắn – một số là mã 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 tin nhắn, bạn có thể có nhiều nhà sản xuất đẩy tin nhắn vào hàng đợi và nhiều người dùng xử lý các tin nhắn đó. Bạn có thể triển khai bộ điều tiết ở phía người dùng bằng cách giới hạn số lượng người 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 dùng.
Ví dụ: nếu một người dùng tin nhắn gặp lỗi giới hạn tốc độ, thì người dùng đó có thể trả yêu cầu về hàng đợi với độ trễ thử lại được chuẩn hoá (sử dụng thuật toán thời gian đợi luỹ thừa) và cập nhật vòng hồi tiếp bộ giới hạn tốc độ được chia sẻ để tất cả người dùng tự động giảm tốc độ xử lý trong khi khôi phục sau lỗi.