API EMM của Google Play có giới hạn mặc định là 60.000 lượt truy vấn mỗi phút cho mỗi EMM.
Nếu bạn vượt quá hạn mức, thì API Google Play EMM sẽ trả về HTTP 429 Too Many Requests.
Để giúp đả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 dưới đây.
Đề xuất duy trì dưới mức giới hạn 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 khoảng thời gian và khoảng thời gian bắt đầu
Các hoạt động như đồng bộ hóa hoặc đăng ký thiết bị cùng 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 định kỳ, bạn có thể phân phối tải yêu cầu của mình bằng cách sắp xếp ngẫu nhiên các khoảng thời gian này. Ví dụ: thay vì đồng bộ hoá từng thiết bị 24 giờ một lần, bạn có thể đồng bộ hoá từng thiết bị trong khoảng thời gian nhất định được chọn từ 23 đến 25 giờ. Điều này giúp mở rộng số lượng yêu cầu.
Tương tự như vậy, 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 việc gửi nhiều 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 đợi lũy tuyến để 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 để đạt đến hạn mức. Thuật toán thời gian đợi lũy thừa là một thuật toán thử lại các yêu cầu theo cấp số nhân. Quy trình mẫu triển khai thuật toán thời gian đợi lũy thừa đơn giản như sau:
- Gửi yêu cầu đến API Google Play EMM.
- Nhận phản hồi
HTTP 429. - Đợi 2 giây +
random_time, sau đó thử lại yêu cầu. - Nhận phản hồi
HTTP 429. - Đợi 4 giây +
random_time, sau đó thử lại yêu cầu. - Nhận phản hồi
HTTP 429. - Đợi 8 giây +
random_time, sau đó 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ờ. Hãy xác định lại một random_time mới mỗi lần bạn thử lại yêu cầu. Bạn có thể thử gửi lại các lệnh gọi API cần thiết để hoàn tất các thao tác đối với người dùng theo lịch thường xuyên hơn (ví dụ: 0,5 giây, 1 giây và 2 giây).
Xử lý hàng loạt giới hạn tốc độ
Mỗi khi một quy trình theo lô đạt đến hạn mức, độ trễ của hành động 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ả trong việc duy trì độ trễ thấp cho hành động của người dùng.
Để tránh việc nhiều lần đạt đến giới hạn sử dụng API và làm tăng độ trễ đối với các hành động mà người dùng trực tiếp sử dụng, hãy cân nhắc sử dụng giới hạn tốc độ cho các quy trình theo lô (xem RateLimiter của Google). Với giới hạn tốc độ, bạn có thể điều chỉnh tỷ lệ các yêu cầu API để luôn duy trì dưới mức 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. Hãy tăng giới hạn tốc độ (1% mỗi phút) miễn là API không trả về lỗi. Mỗi khi bạn đạt đến hạn mức, hãy giảm 20% tỷ lệ yêu cầu. Phương pháp thích ứng này giúp tỷ lệ yêu cầu trở nên tối ưu hơn, đồng thời giảm độ trễ cho các thao tác mà người dùng nhìn thấy.