Google Maps APIs 网络服务的使用限额

此页面仅适用于拥有旧版 Maps APIs for Work 或 Maps API for Business 许可的客户。此页面不适用于拥有新版 Google Maps APIs Premium Plan2016 年 1 月上市发售)的客户。

2011 年 12 月

使用 Google Maps APIs 网络服务需遵循针对 24 小时内请求数量的具体限制。如果发送的请求超过这些限制,将收到错误消息。

使用限制记录在旧版许可的 Google Maps APIs for Work 常见问题解答中。

本文旨在帮助达到这些限制,并且需要优化应用以更高效地使用网络服务的 Google Maps APIs for Work 客户。

基础知识

Google Maps 提供网络服务作为接口,用于请求 Google Maps 数据以在您的应用中使用。这些服务可能只能与 Google Maps 搭配使用;使用来自这些服务的数据,而不在 Google Maps 上显示这些数据的行为受到禁止。如需了解完整详情,请查阅 Google Maps APIs 服务条款许可限制

限制 Google Maps APIs 网络服务使用的配额有两种类型:长期(每日配额)和短期(请求率配额)。如果您超过了使用限制或者以其他方式滥用了服务,Web 服务将返回特定错误消息。如果您继续超过限制,可能会禁止您访问 Web 服务。还可能收到“403 Forbidden”响应。

注意:客户端 API 应用不同的限制。Maps JavaScript API 的每个地图会话设有请求率限制,以便让请求散布于所有用户。这可以使基于浏览器的使用量能够随用户数量的增加而扩展。如需有关如何选择服务器端网络服务以及客户端网络服务的信息,请参阅地理编码策略文档。

问题

下列情况可能导致您超过 Google Maps APIs 网络服务使用限制:

  • 每天发送的请求数量过多。
  • 发送请求的速度过快,即每秒请求数量过多。
  • 发送请求速度过快的情况持续过久,或者以其他方式滥用了 Web 服务。
  • 超过其他使用限制,例如Google Maps Elevation API 中每次请求的点数。

超过使用限制

如果您超过了使用限制,作为响应,您会收到 OVER_QUERY_LIMIT 状态代码

这意味着 Web 服务将停止提供正常响应,并切换到只返回状态代码 OVER_QUERY_LIMIT,直至再次获得更多使用量。这可能会在下列时段内发生:

  • 几秒内,前提是由于您的应用每秒发送的请求数量过多而收到错误。
  • 未来 24 小时内,前提是由于您的应用每天发送的请求数量过多而收到错误。每日配额将在太平洋时间午夜重置。

此抓屏提供适当请求限制和错误处理的分步解释,适用于所有网络服务。

接收到状态代码为 OVER_QUERY_LIMIT 的响应后,您的应用应对确定超出了哪一类限制。可通过暂停 2 秒并重新发送相同请求的方法实现此目的。如果状态代码仍为 OVER_QUERY_LIMIT,则表示您的应用每天发送的请求数量过多。否则,则表示您的应用每秒发送的请求数量过多。

以下是 Python 中的实现示例:

url = "MAPS_API_WEBSERVICE_URL"
attempts = 0
success = False

while success != True and attempts < 3:
  raw_result = urllib.urlopen(url).read()
  attempts += 1
  # The GetStatus function parses the answer and returns the status code
  # This function is out of the scope of this example (you can use a SDK).
  status = GetStatus(raw_result)
  if status == "OVER_QUERY_LIMIT":
    time.sleep(2)
    # retry
    continue
  success = True

if attempts == 3:
  # send an alert as this means that the daily limit has been reached
  print "Daily limit has been reached"

注:还可能收到 OVER_QUERY_LIMIT 错误:

在发送请求之前,应用需确保没有达到这些限制。

HTTP 403 响应

向网络服务发送的请求也可能收到“HTTP 403 (Forbidden)”错误。大多数情况下,这是由于网址签名无效造成的。要验证这一点,请移除 clientsignature 参数,然后重试。

  • 如果响应为“HTTP 200 (OK)”,则表示签名存在问题。
    这与使用限制无关,请参考 Google Maps APIs for Work 文档中网络服务一章中的解决身份验证问题以了解详情。
  • 如果响应仍为“HTTP 403 (Forbidden)”错误,则主要问题不在于签名,而可能在于使用限制。
    这通常意味着由于您的应用已超过使用限制太长时间,或以其他方式滥用网络服务,系统已阻止您访问网络服务。如果您遇到此问题,请访问 Google Cloud Support Portal。您也可以在支持和资源页面中找到联系信息。

对所有网络服务的请求均需要网址签名。如果请求中包含 client 参数,但缺少 signature 参数,则请求将同样会遭到拒绝,并出现“HTTP 403 (Forbidden) ”错误,反之亦然。

解决方法

上述问题可通过结合以下两种方法来解决:

  1. 优化应用以更加高效地使用网络服务,从而降低使用量。
  2. 如果可能的话,为您的 Google Maps APIs for Work 许可购买额外的限额,增加使用限制。

本文将主要说明如何优化应用以更加高效地使用网络服务。

健全性检查

在详细了解如何更高效地使用网络服务之前,应先花点时间检查是否使用了正确的服务和许可。

验证您的用例

Google Maps APIs 网络服务最适用于缺少最终用户实时输入或其网络浏览器不可用的应用。这种情况通常会在您获取的数据集与用户输入无关时发生。例如,您的数据库中有一些需要地理编码的固定地址集,如在房地产网站上供销售的一组属性或一组商店位置。

使用 Google Maps APIs 网络服务时,所有请求都会计入您的客户端 ID 的(每日和每秒)配额。不管请求来自多少个 IP 地址,此配额适用于每个客户端 ID。

在浏览器中使用客户端 Maps JavaScript API 服务时,系统对每个地图会话设有请求率限制。这意味着请求散布于所有用户,并随着用户数量的增长而扩展。因此,在可能的情况下,客户端 API 始终是首选项。如需从需要实时进行地理编码的用户收集地址(例如对用户家庭地址附近的商店执行搜索),则它们是最佳匹配项。

如需更详细地了解此主题,请参阅地理编码策略文档。尽管本文档专门面向地理编码,但其中的建议同样适用于所有网络服务。本文档说明了何时应使用服务器端网络服务以及何时应使用客户端网络服务。

使用 Google Maps APIs for Work 许可

如果您拥有 Google Maps APIs for Work 许可,请确保您的请求中包含正确的客户端 ID。

为 Google Maps APIs for Work 客户提供的 Google Maps APIs 网络服务使用限制高于为免费 API 用户提供的使用限制。要从中受益,您必须按照本指南网络服务一章中的内容,正确设置应用中的 client 参数。

未能正确使用 Google Maps APIs for Work 客户端 ID 的应用将不会被视为“商家”、不会从仅限商家的功能与限额中收益、不会涵盖在 Google Maps APIs for Work SLA 中、无法获得技术支持,并将受常规Google Maps APIs服务条款许可限制的约束。

如何进行优化

更高效地使用网络服务可总结为两个主要目标:仅在确实需要时发送请求以降低使用量;均衡散布使用量,使其不超过限制。

缓存结果

Google Maps APIs 服务条款的 10.5.d 部分规定,您只能出于为应对网络延迟而对 Google Maps APIs 实现的性能进行改善这一目的存储有限数量的内容(不得用于阻止 Google 准确跟踪使用情况),且此存储行为需满足以下条件:是临时的(任何情况下不得超过 30 个日历天);是安全的;不篡改或聚合内容或服务的任何部分;以及不以任何方式修改属性。

这意味着您可以暂时缓存网络服务响应,以避免在短时间内发送重复的请求。网络服务的响应始终包含 Cache-Control HTTP 标头,以指示结果可缓存的时长,当前为 24 小时。

Cache-Control: public, max-age=86400

此标头应始终有效。您可以使用网络代理实现缓存,其中网络代理实现缓存时可以用它自己的默认设置,也可以使用您自己的实现。需要指出的是,部分客户端内容库也可以缓存 HTTP 响应。

如需增加缓存命中率,应通过四舍五入至 6 位小数将 LatLng 坐标标准化,从而提供绕赤道约 11 厘米的精度。增加更多小数位数并不会使网络服务的结果有什么不同,而这样做反而会降低缓存命中率。

对请求数量进行限制

应用应对请求数量进行限制,以避免超出使用限制。需记住的是,使用限制适用于每一个客户端 ID,不论请求来自多少个 IP 地址。

您可以通过将请求置于跟踪请求发送时间的队列中来对请求进行限制。在使用率限制为 10 QPS(每秒查询数)的情况下,在发送第 11 个请求时,应用应检查第 1 个请求的时间戳,并等待 1 秒钟。此方法也同样适用于每日限制。

即使正确实现了限制,应用仍需要密切注意状态代码为 OVER_QUERY_LIMIT 的响应。如果收到此类响应,请使用上述超过使用限制部分中说明的“暂停并重试”机制检测超过了哪个限制。

处理积压的请求

正确实现限制后,发送至网络服务的请求将不会超过使用限制。但是,应用接收输入的数量和速度可能会高于网络服务允许的使用限制。这可能导致限制队列的规模越来越庞大,造成待处理请求积压。

在处理大量积压请求时,您的应用可能会达到每日使用限制。如果已对每日限制正确实现限制,则应用应停止发送请求,否则发送额外的请求将会遇到状态代码为 OVER_QUERY_LIMIT 的响应。在这两种情况下,积压的请求都不会减少。

如果一整天或一周的平均请求数量仍低于使用限制,则您的应用应该能够在请求输入流量较低时处理掉积压的请求。否则,您可能需要增加 Google Maps APIs for Work 许可的每日限额(请参考下一部分)。

优化程度不足

如果您已实现上述所有优化操作,而积压的请求仍然持续增加,则不管是以天为单位,还是在一天中的所有时间,您都确实需要增加 Google Maps APIs for Work 许可的每日或每秒使用限制。这种情况下,请与我们的 Google Maps APIs for Work 客户经理联系,以探讨可选择的方案。