由于网络问题、系统或者服务内部的 Bug、服务器宕机、操作系统崩溃等问题的不确定性，我们的系统或者服务永远不可能保证时刻都是可用的状态。
尤其是对于微服务系统来说，正确设置超时和重试非常重要。单体服务通常只涉及数据库、缓存、第三方 API、中间件等的网络调用，而微服务系统内部各个服务之间还存在着网络调用。
一、超时机制
一个请求超过指定的时间（比如 1s）还没有被处理的话，这个请求就会直接被取消并抛出指定的异常或者错误（比如?504 Gateway Timeout）。
1.1 分类：
- 连接超时（ConnectTimeout）?：客户端与服务端建立连接的最长等待时间。
- 读取超时（ReadTimeout）?：客户端和服务端已经建立连接，客户端等待服务端处理完请求的最长时间。实际项目中，我们关注比较多的还是读取超时。
1.2 后果
- 如果没有设置超时的话，就可能会导致服务端连接数爆炸和大量请求堆积的问题。
- 这些堆积的连接和请求会消耗系统资源，影响新收到的请求的处理。
- 我们也可以将超时弄成可配置化的参数而不是固定的，比较简单的一种办法就是将超时的值放在配置中心中。
1.3 时间设置
- 设置过长
????????超时时间过?容易引起降级失效、系统崩溃、连接池爆满等问题。如下图，内容服务是?向?户直接提供知识内容的核?服务。收藏服务返回?户对内容的是否收藏，属于低优先级服务。如果内容服务请求收藏服务设置超时时间过?，如图中，虽然设置 1S 超时，但是重试累计 3S，则?旦收藏服务发?宕机（通常是由于上游 QPS 异常导致），则内容服务会失效，?法返回给?户数据，甚?发?串联雪崩。
- 设置过短
????????超时时间设置过短，实际?产中容易因?络抖动?告警频繁，造成服务不稳定等?户体验问题。如内容服务调?资源服务超时时间设置 200ms，资源服务调?ID 发号器服务超时时间设置为 300ms，?旦?络抖动后，资源服务 200ms 即超时返回，资源服务对下游的调? 300ms 超时也?实际意义。
1.4 合理设定
合理设置超时时间，对系统的稳定来?，非常重要，我们可以从以下?度来考虑设置值：
- ?户?度
。微服务最终为服务对象是?户，从?户交互数据来讲，服务响应时间在 300ms 内最佳， 2000ms 内仍可接受。通常情况下，建议超时的上限值为 2000ms，超过 2000ms 的非重要请求，则有必要被降级处理。
- 技术?度
。同时考虑到 TCP 算法中 Delayed ACK + Nagle 算法开启的场景，最小 delay 值 40 ms，建议下限值设定为 50ms； 在 RTT 较?的正常网络环境中，TCP 数据包丢包，超时重传的最?值，200 ms，因此我们建议 300ms 可以视为超时设置的最佳选择，为重传保留?定的余量。
- 资源消耗?度
。依据资源消耗的分析，超时时间?短应当和 QPS 成反?例。我们设定基础值超时设定为 300ms、100QPS，并根据实际 QPS 做调整。
二、重试机制
2.1 什么是重试机制？
重试机制：一般配合超时机制一起使用，指的是多次发送相同的请求来避免瞬态故障和偶然性故障。
核心思想：通过消耗服务器的资源来尽可能获得请求更大概率被成功处理。由于瞬态故障和偶然性故障是很少发生的，因此，重试对于服务器的资源消耗几乎是可以被忽略的。
挑战：分布式应?的挑战之?就是如何管理远程服务的可用性和它们的响应。
资源消耗：由于瞬态故障和偶然性故障是很少发生的，因此，重试对于服务器的资源消耗几乎是可以被忽略的。
次数：重试的次数通常建议设为 3 次，次数不宜过多，否则依然会对系统负载造成比较大的压力。
服务消费方
- 协议消耗，每次发起 TCP 连接请求时，通常会让系统选取?个空闲的本地端?（local port），该端?是独占的，不能和其他 TCP 连接共享。TCP 端?的数据类型是 unsigned short，因此可?端?最多只有 65535，所以在全部作为 client 端的情况下，最?TCP 连接数 65535。
- 除端?消耗外，发起调?的业务进程、线程、协程等待过程中，?法释放其所消耗的内存、CPU 等，是服务消费?发起调?的主要消耗。
服务提供方
- 协议消耗，主要是建?连接的消耗，每接收每?个 tcp 连接都要占?个?件描述符，理论上是 server 端单机最?tcp 连接数约为 2 的 48 次方。
- 业务逻辑消耗。在复杂的业务逻辑、机器资源和?络带宽条件下，最?并发 tcp 连接数远不能达到理论上限，有时候会发现，单机 1w 并发往往也是?较困难。因此，服务提供?主要是业务逻辑的?量资源消耗，如 CPU、?络带宽、磁盘 IO 等。
2.2 重试幂等
防止因为错误的判断超时而采用重试
客户端等待服务端完成请求完成超时但此时服务端已经执行了请求，只是由于短暂的网络波动导致响应在发送给客户端的过程中延迟了。
举个例子：用户支付购买某个课程，结果用户支付的请求由于重试的问题导致用户购买同一门课程支付了两次。对于这种情况，我们在执行用户购买课程的请求的时候需要判断一下用户是否已经购买过。这样的话，就不会因为重试的问题导致重复购买了。
2.3 幂等性：
一个接口被调用，不管几次，产生一样的效果，一样返回结果。
1、业务表唯一索引：
- 对于数据插入的场景来说，这是最常见的方案。
- 核心业务字段设置为唯一索引，多次插入就会报错，从而保证幂等性。
2、状态流转控制：
- 状态流转也是最常见的幂等性保证手段。
- 如配送业务中，骑手的操作肯定会对业务流转状态进行校验。如果骑手已经提货，那就肯定不能再次提货的。
3、乐观锁版本号：
- 在业务表中新建一个字段version，int类型。
- 服务A调用服务B需要更新的时候，需要提前查询到version，然后作为参数传过去。
- 如果数据更新的时候将version + 1，接口如果发生重试的时候，version已经发生变更，那么也能保证幂等性。