线上接口超时是家常便饭，但乱写重试会导致雪崩、重复提交。给你一套生产可用的思路：
- 设置合理的重试次数：一般 2-3 次，别无限重试。
- 使用指数退避：第一次 1s，第二次 2s，第三次 4s，给服务恢复时间。
- 接口必须幂等：用唯一请求号、数据库唯一索引，避免重复扣款 / 重复创建数据。
- 熔断降级：结合 Sentinel/Hystrix，失败率过高直接切断，保护主链路。
- 设置超时时间：设置合理超时时间，根据业务需要。
小技巧：远程调用优先用 Resilience4j，轻量好用，适配 SpringBoot 生态。
在当今高度数字化且业务交互频繁的线上环境中，线上接口超时已然成为一种极为常见的现象，如同家常便饭一般普遍。随着互联网业务的飞速发展，系统架构日益复杂，服务之间的依赖关系盘根错节，接口调用的频率和复杂度也不断攀升。网络状况的不稳定、服务器负载的波动、代码逻辑的潜在问题等诸多因素，都可能导致接口在调用过程中出现超时情况。
然而，在处理接口超时问题时，如果缺乏合理的重试策略，随意编写重试逻辑，将会引发一系列严重的后果，其中最为突出的就是雪崩效应和重复提交问题。雪崩效应就像是一场可怕的连锁反应，当一个接口出现超时，若不断进行无节制的重试，会使该接口所依赖的下游服务承受巨大的压力。一旦某个下游服务不堪重负而崩溃，就会像多米诺骨牌一样，引发整个服务链的崩溃，最终导致整个系统陷入瘫痪。而重复提交问题也不容忽视，在金融交易、订单处理等业务场景中，重复提交可能会导致重复扣款、重复创建订单等严重后果，给用户和企业带来巨大的损失。
为了有效应对线上接口超时问题，以下为大家提供一套在生产环境中切实可行的思路：
设置合理的重试次数
合理设置重试次数是避免系统陷入恶性循环的关键。一般来说，将重试次数设定在 2 - 3 次是比较科学的做法。从概率学的角度来看，很多接口超时可能是由于临时性的网络抖动、服务器瞬间负载过高等原因导致的。在这种情况下，第一次重试往往有较大的概率使接口恢复正常。如果第一次重试失败，第二次重试仍有一定的机会成功。但如果经过 2 - 3 次重试后接口仍然超时，那么很可能是出现了较为严重的问题，如服务器硬件故障、代码逻辑错误等。此时若继续进行无限重试，不仅无法解决问题，还会给系统带来巨大的额外负担，进一步加剧系统的不稳定。就好比我们在寻找丢失的物品时，尝试了几次仍未找到，就应该考虑换一种方式或者寻求其他帮助，而不是一味地在同一个地方反复寻找。
使用指数退避策略
指数退避策略是一种非常有效的重试机制，它通过在每次重试之间设置逐渐递增的时间间隔，为服务提供足够的恢复时间。具体来说，第一次重试等待 1 秒，第二次重试等待 2 秒，第三次重试等待 4 秒。这种策略的原理在于，当接口出现超时，服务可能处于高负载或者内部出现了一些小故障，需要一定的时间来自我修复和调整。如果每次重试的间隔时间过短，服务还未从之前的请求压力中恢复过来，就又收到新的请求，会导致服务的负担进一步加重，问题更加难以解决。就像一个人在剧烈运动后需要适当的休息时间来恢复体力，如果刚跑完步马上又进行高强度运动，身体很容易出现问题。通过指数退避策略，我们可以让服务在每次重试之间有足够的时间来恢复，提高重试成功的概率。
确保接口幂等性
接口的幂等性是保障系统数据一致性和稳定性的重要特性。幂等性意味着无论对同一操作进行多少次请求，所产生的影响都和执行一次请求是相同的。为了实现接口的幂等性，可以采用多种方法。其中，使用唯一请求号是一种简单而有效的方式。在每次发起请求时，为该请求分配一个唯一的标识符，服务端在接收到请求后，首先检查这个唯一请求号是否已经处理过。
如果已经处理过，就直接返回之前的处理结果，而不再进行重复处理。例如，在电商系统的订单创建接口中，每个订单都有一个唯一的订单号，当用户提交订单时，系统会根据这个订单号来判断是否已经创建过该订单，避免重复创建。另一种常用的方法是利用数据库的唯一索引。在数据库表中设置唯一索引，当插入重复的数据时，数据库会自动进行拦截，从而避免重复创建数据。以支付系统为例，通过在交易记录中设置唯一的交易号索引，就可以防止重复扣款的情况发生。
实施熔断降级
熔断降级是保障系统主链路稳定运行的重要手段。可以结合 Sentinel 或者 Hystrix 等开源框架来实现。当接口的失败率过高时，意味着服务可能出现了严重的问题，如果继续让大量的请求涌入，会进一步恶化服务的状态。此时，熔断机制会自动触发，直接切断对该接口的请求，就像电路中的保险丝在电流过大时会自动熔断，保护整个电路系统一样。
在处理线上接口调用时，设置合理的超时时间是保障系统稳定运行和业务正常流转的重要环节。超时时间的设定并非随意为之，而是需要紧密依据业务的实际需求来进行精准规划。
设置合理超时时间
不同的业务场景对于接口响应时间有着不同的容忍度和要求。以实时性要求极高的金融交易业务为例，如股票交易、在线支付等场景，用户期望在极短的时间内得到交易结果反馈。在这种情况下，超时时间就需要设置得相对较短，可能仅为几百毫秒到数秒不等。这是因为金融交易的时效性直接关系到用户的资金安全和收益情况，过长的等待时间不仅会影响用户体验，还可能导致交易机会的丧失。例如，在股票市场中，行情瞬息万变，一笔交易的延迟可能会使投资者错过最佳的买卖时机，造成经济损失。所以，为了确保交易的及时性和准确性，系统需要快速判断接口是否能够正常响应，如果在短时间内没有得到有效反馈，就应及时判定为超时，采取相应的处理措施，如提示用户重新操作或进行错误处理。
而对于一些对实时性要求相对较低的业务场景，如批量数据处理、报表生成等，超时时间则可以适当延长。这些业务通常涉及大量的数据计算和处理，可能需要较长的时间才能完成。例如，企业在生成月度财务报表时，系统需要从多个数据源中提取数据，进行复杂的计算和汇总，这个过程可能会花费几分钟甚至几十分钟。此时，如果将超时时间设置得过短，很可能在报表尚未生成完成时就判定为超时，导致任务失败。因此，根据业务的特点和处理时间的预估，合理地延长超时时间，能够保证业务的顺利完成，避免不必要的重试和错误。
此外，业务的并发量也是影响超时时间设置的重要因素。在高并发的情况下，系统资源会被大量占用，接口的响应时间可能会变长。例如，在电商平台的促销活动期间，大量用户同时进行下单操作，服务器的负载会急剧增加，接口的处理速度会相应变慢。此时，如果仍然按照平时的超时时间进行设置，可能会导致大量的超时错误。因此，需要根据业务的并发情况，动态地调整超时时间，以适应系统的实际运行状态。
同时，还需要考虑业务的稳定性和容错性。对于一些关键业务，为了确保其稳定性，可能会设置相对较长的超时时间，以给予系统足够的时间来处理异常情况和进行自我修复。而对于一些非关键业务，为了提高系统的整体效率，可以适当缩短超时时间，快速放弃那些可能出现问题的请求，避免资源的浪费。
设置合理的超时时间需要综合考虑业务的实时性要求、处理复杂度、并发量、稳定性和容错性等多个因素。只有这样，才能在保证系统性能的同时，满足业务的实际需求，为用户提供更加优质、稳定的服务。
评论区说说你们项目用的哪种重试方案？
