AWS API Gateway集成Kinesis Data Stream的重试及错误处理机制咨询

文档解读正确性确认 #

你之前对API Gateway官方文档的解读存在偏差：

文档中提到的「每个支持Amazon API Gateway的AWS SDK都实现了自动重试逻辑」，针对的是调用API Gateway接口的客户端侧SDK，也就是你的业务服务调用API Gateway时用的SDK自带的重试能力，和API Gateway自身调用后端Kinesis的服务侧逻辑完全无关，二者不会互相影响。

API Gateway服务侧调用Kinesis的重试规则 #

API Gateway和AWS服务原生集成时，对可重试的错误响应有固定的内置处理逻辑：

• 针对Kinesis返回的ProvisionedThroughputExceeded异常、服务端5xx类异常，API Gateway默认最多执行3次重试
• 重试采用标准指数退避加抖动策略，首次重试间隔为100ms，之后逐次翻倍
• 整体重试耗时受API Gateway集成超时配置限制（可配置范围为50ms~29秒），如果累计调用+重试耗时超过超时阈值，API Gateway会直接向客户端返回504网关超时错误，不会继续重试

AWS.Kinesis.maxRetries参数说明 #

你搜索的AWS.Kinesis.maxRetries是AWS SDK面向开发者提供的Kinesis客户端配置项，和API Gateway服务侧逻辑没有关联：

• 该参数仅在你自己的业务代码中直接调用Kinesis SDK时生效，不同语言版本的SDK默认重试次数不同，比如JavaScript SDK v2的Kinesis客户端默认最大重试次数为5次，同样采用指数退避策略
• API Gateway服务内部调用Kinesis的逻辑不使用该公开SDK配置，不受这个参数影响

吞吐量超限异常的优化建议 #

如果要降低ProvisionedThroughputExceeded异常对业务的影响，可以参考以下方案：

• 优先根据业务峰值流量调整Kinesis的分片数量，或者直接启用Kinesis按需容量模式，从根源避免容量超限
• 在API Gateway中配置自定义集成响应，将Kinesis返回的ProvisionedThroughputExceeded异常映射为客户端可识别的429状态码，由业务侧实现适配业务逻辑的重试机制
• 高并发写入场景可以在客户端侧先做批量聚合，减少Kinesis的请求次数

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