Giới hạn số lượng yêu cầu

API Google Ads nhóm các yêu cầu giới hạn số lượng yêu cầu theo truy vấn mỗi giây (QPS) trên mỗi mã khách hàng của khách hàng (CID) và mã của nhà phát triển, nghĩa là định mức được thực thi độc lập trên cả mã khách hàng và mã của nhà phát triển. API Google Ads sử dụng thuật toán Bộ 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 thích hợp. Vì vậy, giới hạn chính xác sẽ khác nhau tuỳ thuộc vào tổng số tải máy chủ tại một thời điểm nhất định.

Mục đích của việc áp đặt giới hạn số lượng yêu cầu là để ngăn không cho 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 bằng một lượng lớn yêu cầu.

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 của mình 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 số lượng yêu cầu. Việc hiểu rõ các khái niệm về Mẫu tích hợp doanh nghiệp (EIP) như Nhắn tin, Phân phối lại và Điều tiết có thể giúp bạn xây dựng ứng dụng khách mạnh mẽ hơn.

Các phương pháp được đề xuất sau đây được sắp xếp theo mức độ 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 tinh vi hơn ở bên dưới:

Giới hạn các tác vụ đồng thời

Một nguyên nhân gốc khiến vượt quá giới hạn số lượng yêu cầu là ứng dụng khách đang tạo quá nhiều tác vụ song song. Mặc dù chúng tôi không giới hạn số yêu cầu song song mà một ứng dụng khách có thể đưa ra, nhưng điều này có thể dễ dàng vượt quá giới hạn Số yêu cầu mỗi giây ở cấp mã của nhà phát triển.

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ẽ đưa ra yêu cầu (trên tất cả các quy trình và máy), đồng thời điều chỉnh lên trê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 bài viết Đ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. Cách này phù hợp nhất cho các lệnh gọi MutateFoo. Ví dụ: nếu đang cập nhật trạng thái cho nhiều thực thể của AdGroupAd – thay vì gọi MutateAdGroupAds một lần cho mỗi AdGroupAd, bạn có thể gọi MutateAdGroupAds một lần và truyền vào nhiều operations. 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ù các yêu cầu theo lô giúp giảm tổng số yêu cầu và giảm giới hạn số lượng Yêu cầu mỗi phút, nhưng nó có thể kích hoạt giới hạn tốc độ Hoạt động mỗi phút nếu bạn thực hiện một số lượng lớn các thao tác trên một tài khoản.

Trình đ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 trình giới hạn tốc độ ở phía máy khách. Điều này có thể đảm bảo tất cả các luồng trong các quy trình và / hoặc cụm của bạn đề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.

Bạn có thể xem Trình giới hạn tốc độ Guava hoặc triển khai thuật toán dựa trên Bộ chứa mã thông báo của riêng mình trong một môi trường được phân cụm. Ví dụ: bạn có thể tạo mã thông báo và lưu trữ mã đó trong một bộ nhớ giao dịch dùng chung, chẳng hạn như cơ sở dữ liệu, đồng thời mỗi ứng dụng sẽ phải nhận và sử dụng mã thông báo trước khi xử lý yêu cầu. Nếu đã dùng hết mã thông báo, ứng dụng sẽ phải đợi cho đến khi lô mã thông báo tiếp theo được tạo.

Danh sách chờ

Hàng đợi thông báo là giải pháp để phân phối tải thao tác, đồng thời kiểm soát yêu cầu và giá tiêu dùng. Hiện có một số tuỳ chọn hàng đợi thông báo (một số nguồn mở, một số thuộc quyền sở hữu riêng) và nhiều tuỳ 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 sẽ xử lý các thông báo đó. Bạn có thể triển khai tính năng điều tiết ở phía người dùng bằng cách giới hạn số lượng người tiêu dùng đồng thời, hoặc triển khai trình giới hạn số lượng yêu cầu hoặc trình đ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ả về yêu cầu cho hàng đợi để được thử lại. Đồng thời, người tiêu dùng đó cũng có thể thông báo cho tất cả người tiêu dùng khác tạm dừng xử lý trong một vài giây để khôi phục sau lỗi.