Hạn mức sử dụng

API EMM của Google Play có giới hạn mặc định là 60.000 truy vấn mỗi phút cho mỗi EMM.

Nếu bạn vượt quá hạn mức, thì API EMM của Google Play sẽ trả về HTTP 429 Too Many Requests. Để đảm bảo bạn không vượt quá hạn mức sử dụng đã nêu và mang lại trải nghiệm tối ưu cho người dùng, hãy cân nhắc triển khai một số phương pháp hay nhất được mô tả trong phần bên dưới.

Đề xuất để luôn ở dưới hạn mức sử dụng API

Khi sử dụng API EMM của Google Play, bạn có thể triển khai một số phương pháp hay nhất để phân phối yêu cầu và giảm nguy cơ vượt quá hạn mức sử dụng.

Sắp xếp ngẫu nhiên thời gian bắt đầu và khoảng thời gian

Các hoạt động như đồng bộ hoá hoặc đăng ký thiết bị cùng một lúc có thể làm tăng đáng kể số lượng yêu cầu. Thay vì thực hiện các hoạt động này theo khoảng thời gian định kỳ, bạn có thể phân phối tải yêu cầu bằng cách tạo các khoảng thời gian này một cách ngẫu nhiên. Ví dụ: thay vì đồng bộ hoá từng thiết bị mỗi 24 giờ, bạn có thể đồng bộ hoá từng thiết bị theo khoảng thời gian được chọn ngẫu nhiên từ 23 đến 25 giờ. Điều này giúp phân bổ số lượng yêu cầu.

Tương tự, nếu bạn chạy một công việc hằng ngày thực hiện nhiều lệnh gọi API liên tiếp, hãy cân nhắc việc bắt đầu công việc đó vào một thời điểm ngẫu nhiên mỗi ngày để tránh tạo ra một lượng lớn yêu cầu cho tất cả khách hàng doanh nghiệp cùng một lúc.

Sử dụng thuật toán thời gian đợi luỹ thừa để thử lại các yêu cầu

Nếu bạn chạy các công việc bao gồm nhiều lệnh gọi API, hãy sử dụng chiến lược thời gian đợi luỹ thừa để phản hồi việc đạt đến hạn mức. Thời gian đợi luỹ thừa là một thuật toán thử lại các yêu cầu theo luỹ thừa. Sau đây là ví dụ về quy trình triển khai thuật toán thời gian đợi luỹ thừa đơn giản:

  1. Gửi yêu cầu đến API EMM của Google Play.
  2. Nhận phản hồi HTTP 429.
  3. Đợi 2 giây + random_time, rồi thử lại yêu cầu.
  4. Nhận phản hồi HTTP 429.
  5. Đợi 4 giây + random_time, rồi thử lại yêu cầu.
  6. Nhận phản hồi HTTP 429.
  7. Đợi 8 giây + random_time, rồi thử lại yêu cầu.

random_time thường là một số ngẫu nhiên trong khoảng từ -0,5 * thời gian chờ đến +0,5 * thời gian chờ. Xác định lại random_time mới mỗi khi bạn thử lại yêu cầu. Bạn có thể thử lại các lệnh gọi API cần thiết để hoàn tất các thao tác mà người dùng thực hiện theo lịch trình thường xuyên hơn (ví dụ: 0,5 giây, 1 giây và 2 giây).

Giới hạn tốc độ cho các quy trình xử lý hàng loạt

Mỗi khi một quy trình xử lý hàng loạt đạt đến hạn mức, độ trễ của các hành động của người dùng gọi API sẽ tăng lên. Trong những trường hợp như vậy, các chiến lược như thời gian đợi luỹ thừa có thể không đủ hiệu quả để duy trì độ trễ thấp cho các thao tác của người dùng.

Để tránh liên tục đạt đến giới hạn sử dụng của API và tăng độ trễ cho các thao tác mà người dùng thực hiện, hãy cân nhắc sử dụng bộ giới hạn tốc độ cho các quy trình xử lý hàng loạt (xem RateLimiter của Google). Với bộ giới hạn tốc độ, bạn có thể điều chỉnh tốc độ của các yêu cầu API để luôn duy trì ở mức dưới giới hạn sử dụng.

Ví dụ: bắt đầu một quy trình theo lô với giới hạn tốc độ mặc định là 50 QPS. Miễn là API không trả về lỗi, hãy tăng dần giới hạn tốc độ (1% mỗi phút). Mỗi khi bạn đạt đến hạn mức, hãy giảm 20% tốc độ yêu cầu. Phương pháp thích ứng này giúp tăng tốc độ yêu cầu một cách tối ưu hơn, đồng thời giảm độ trễ cho các thao tác mà người dùng thực hiện.