新版与旧版Place API配额超限差异及自动限流机制疑问

一、新旧版API配额差异的原因 #

• 配额规则收紧：新版Place API对GetPlaceRequest的每分钟请求配额（QPM）设置比旧版严格很多。旧版Legacy接口要么给这个请求类型的阈值更高，要么根本没单独拆分限制，新版把请求类型细分后，给GetPlaceRequest定了更低的上限。
• 计数方式变了：旧版可能把一些批量请求或者复用请求合并计数，新版则是每个独立的GetPlaceRequest都算一次配额，导致同样的业务操作，新版的请求计数直接翻倍甚至更多。
• 资源评估更精细：Google对新版API的资源占用评估更严格，GetPlaceRequest被判定为消耗资源较多的请求类型，所以给的配额上限更保守。

二、开了自动限流还超限的原因 #

• 客户端限流和云端配额不匹配：SDK的自动限流是按Google公布的默认QPM来的，但如果你的项目在Cloud Console里实际配置的GetPlaceRequest配额比这个默认值低，哪怕SDK按默认值限流，也会触发云端的配额限制。
• 多实例/客户端叠加：如果你的服务跑了多个实例，或者用多个客户端同时发请求，每个客户端的限流是单独算的，加起来的总请求数很容易超过云端的全局配额。
• 限流有误差或延迟：SDK的限流是本地计算的，遇到网络延迟、请求队列堆积的时候，短时间内实际发出去的请求可能比预期多，直接突破分钟级的配额上限。
• 部分请求没被限流统计：比如重试请求、批量接口里的子请求，可能没被SDK的限流逻辑算进去，这些额外的请求悄悄消耗了配额，最后导致超限。

内容的提问来源于stack exchange，提问作者cpd1