重要提示：我们不再接受 Play EMM API 的新注册。
了解详情。
使用限制
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
Google Play EMM API 的默认上限为每个 EMM 每分钟 6 万次查询。
如果您超出了配额，Google Play EMM API 会返回 HTTP 429 Too Many Requests。
为确保您不会超出规定的使用限制，并为用户提供最佳体验，不妨考虑采用下一部分中介绍的一些最佳实践。
关于如何确保不超过 API 用量限额的建议
使用 Google Play EMM API 时，您可以实施一些最佳做法来分发请求，并降低超出用量限额的风险。
随机设置开始时间和间隔时间
同时进行同步或签入设备等活动可能会导致请求量大幅增加。您可以通过对这些间隔时间进行随机化处理，而不是按定期安排的时间间隔执行这些活动，从而分散请求负载。例如，您可以选择在 23 到 25 小时之间随机选择的时间段同步每部设备，而不是每 24 小时同步一次。这有助于分散请求数量。
同样，如果您运行的每日作业会快速连续进行多次 API 调用，请考虑每天在随机时间启动该作业，以免同时向所有企业客户发出大量请求。
使用指数退避算法重试请求
如果您运行的作业包含许多 API 调用，请使用指数退避策略来应对达到配额的情况。指数退避算法是一种以指数方式重试请求的算法。实现简单指数退避算法的示例流程如下：
- 向 Google Play EMM API 发出请求。
- 收到
HTTP 429 响应。
- 等待 2 秒 +
random_time，然后重试该请求。
- 收到
HTTP 429 响应。
- 等待 4 秒 +
random_time，然后重试请求。
- 收到
HTTP 429 响应。
- 等待 8 秒 +
random_time，然后重试该请求。
random_time 通常是一个随机数，介于 -0.5 * 等待时间 和 +0.5 * 等待时间 之间。每次重试请求时，都要重新定义新的 random_time。完成面向用户的操作所需的 API 调用可以按更频繁的时间表（例如 0.5 秒、1 秒和 2 秒）重试。
速率限制批处理
每当批处理流程达到配额时，调用 API 的用户操作的延迟时间都会增加。在这种情况下，指数退避等策略可能不足以有效地缩短用户操作的延迟时间。
为避免反复达到 API 的使用限制并增加面向用户的操作的延迟时间，请考虑为批处理流程使用速率限制器（请参阅 Google 的 RateLimiter）。
借助速率限制器，您可以调整 API 请求的速率，以便始终保持在用量限制以下。
例如，启动一个批处理进程，默认速率限制为 50 QPS。只要 API 未返回错误，请缓慢提高速率限制（每分钟 1%）。每次达到配额时，请将请求速率降低 20%。这种自适应方法可实现更优的请求速率，同时缩短面向用户的操作的延迟时间。
如未另行说明，那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可，并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情，请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2024-11-09。
[null,null,["最后更新时间 (UTC)：2024-11-09。"],[[["\u003cp\u003eThe Google Play EMM API has a default limit of 60,000 queries per minute per EMM, exceeding which results in an HTTP 429 Too Many Requests error.\u003c/p\u003e\n"],["\u003cp\u003eTo avoid exceeding the usage limit, randomize device sync intervals and job start times to distribute the request load.\u003c/p\u003e\n"],["\u003cp\u003eImplement exponential backoff to retry requests with increasing wait times after receiving HTTP 429 errors.\u003c/p\u003e\n"],["\u003cp\u003eFor batch processes, utilize a rate limiter to adjust the request rate dynamically and prevent consistently hitting the usage limit, ensuring low latency for user actions.\u003c/p\u003e\n"]]],[],null,["# Usage Limits\n\nThe Google Play EMM API has a default limit of 60,000 queries per minute for each EMM.\n\nIf you exceed the quota, then the Google Play EMM API returns `HTTP 429 Too Many Requests`.\nTo help ensure that you don't exceed the stated usage limits and offer an optimal experience for\nyour users, consider implementing some of the best practices described in the section below.\n\nRecommendations for staying below the API usage limits\n------------------------------------------------------\n\nWhen using the Google Play EMM API, there are some best practices that you can implement to\ndistribute requests and reduce your risk of exceeding the usage limits.\n\n### Randomize start times and intervals\n\nActivities such as syncing or checking-in devices at the same time are likely to result in a\nsignificant increase in request volume. Instead of performing these activities at regularly\nscheduled intervals, you can distribute your request load by randomizing these intervals. For\nexample, rather than syncing each device every 24 hours, you can sync each device at a randomly\nchosen time period between 23 and 25 hours. This helps spread out the number of requests.\n\nSimilarly, if you run a daily job that makes many API calls in quick succession, consider\nstarting the job at a random time each day to prevent making a high volume of requests for all\nyour enterprise customers at the same time.\n\n### Use exponential backoff to retry requests\n\nIf you run jobs that consists of many API calls, use an exponential backoff strategy in\nresponse to reaching the quota. Exponential backoff is an algorithm that retries requests\nexponentially. An example flow for implementing simple exponential backoff is as follows:\n\n1. Make a request to the Google Play EMM API.\n2. Receive an `HTTP 429` response.\n3. Wait 2 seconds + `random_time`, then retry the request.\n4. Receive an `HTTP 429` response.\n5. Wait 4 seconds + `random_time`, then retry the request.\n6. Receive an `HTTP 429` response.\n7. Wait 8 seconds + `random_time`, then retry the request.\n\nThe `random_time` is typically a random number ranging from ***-0.5 \\* wait time***\nto ***+0.5 \\* wait time*** . Redefine a new `random_time` each time you retry your\nrequest. API calls that are required to complete user-facing actions can be retried on a more\nfrequent schedule (0.5s, 1s, and 2s, for example).\n\n### Rate-limit batch processes\n\nEach time a batched process reaches the quota, the latency of user actions that call the API\nincreases. In situations like these, strategies such as exponential backoff may not be effective\nenough in maintaining low latency for user actions.\n\nTo avoid reaching the API's usage limits repeatedly and increasing latency for user-facing\nactions, consider using a rate limiter for your batched processes (see [Google's RateLimiter](https://google.github.io/guava/releases/19.0/api/docs/index.html?com/google/common/util/concurrent/RateLimiter.html)).\nWith a rate limiter you can adjust the rate of your API requests so that you consistently remain\nbelow the usage limits.\n\nFor example, start a batched process with a default rate limit of 50 QPS. As long as the API\ndoesn't return an error, increase the rate limit slowly (1% every minute). Each time you reach\nthe quota, reduce your request rate by 20%. This adaptive approach results in a more optimal\nrequest rate while reducing latency for user-facing actions."]]
