Google Load Balancer超时后重复请求Tomcat问题咨询

这事儿我之前帮团队排查过类似情况，来给你拆解下问题根源和解决办法：

问题根源 #

Google Load Balancer（GLB）在触发超时返回502后，之所以会给Tomcat发重复请求，核心是它的重试机制在起作用：当GLB在设定的超时时间内没收到Tomcat的响应，它会默认认为请求可能没被后端成功接收/处理，于是会自动重试一次相同请求。另外，如果Tomcat自身的超时配置比GLB短，导致Tomcat提前断开连接，也会加剧这个问题。

具体解决步骤 #

• 调整GLB的重试策略
  登录云控制台找到你的GLB配置，定位到「重试策略」（Retry Policies）选项：

  • 关闭针对「超时/502状态码」的自动重试，或者把重试触发条件限制为明确的网络错误（比如连接重置、拒绝），而不是只要超时就重试。
  • 区分开GLB的「请求超时」和「空闲超时」：请求超时是整个请求的最大处理时间，空闲超时是连接空闲无数据的时间，别把两者设置混淆导致误触发重试。

• 对齐Tomcat与GLB的超时配置
  修改Tomcat的server.xml配置文件：

  • 把Connector节点的connectionTimeout值设置得大于等于GLB的超时时间（比如GLB设30秒，Tomcat就设35秒），确保Tomcat不会在GLB超时前主动断开连接，避免GLB误判请求未处理。
  • 如果你的服务用到了异步处理，同步调整asyncTimeout参数，保证异步请求的超时时间也长于GLB的设置。

• 给请求添加幂等兜底
  如果业务场景下没法完全杜绝重试（比如极端网络波动），那就得保证Tomcat的请求处理是幂等的：

  • 让前端或GLB给每个请求带上唯一的X-Request-ID标识。
  • 在Tomcat里写一个全局Filter，处理请求前先检查这个ID是否已经在缓存（比如Redis）中存在：如果存在，直接返回之前的处理结果；如果不存在，再执行业务逻辑，处理完把ID存入缓存并设置合理的过期时间（比如比超时时间长1分钟）。

• 排查GLB健康检查配置
  确认GLB的健康检查参数和请求超时不冲突：比如健康检查的超时设为5秒、间隔10秒，不要让健康检查的频率或超时时间干扰正常请求的判断，避免GLB误判后端不可用而触发重试。

总结 #

优先从调整GLB的重试策略入手，这是最直接解决重复请求的方式；然后对齐两边的超时配置，从根源减少重试触发的可能；最后用幂等处理做兜底，确保即使有重试也不会影响业务逻辑。

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