配置客户端重试机制提高业务可用性
ELB的高可用机制
为了实现提高ELB服务的高可用性，推荐用户购买多可用区的实例，同时开启对后端服务器的健康检查功能。
- 系统高可用部署机制：ELB实例采用多AZ多活的集群化部署，消除了单AZ机房故障的影响，同时实现了AZ内的会话同步，消除了ELB集群单AZ内的服务器单点故障的影响，保证了服务的系统稳定性。
- 健康检查机制： ELB实例基于用户配置的健康检查探测策略，对后端服务器进行健康检查，能够保证新连接能够转发到健康的后端服务器。
客户端重试应用场景
通常情况下，ELB的高可用机制能够应对核心业务的容灾场景。然而，在极端场景下，可能会出现连接reset或超时等问题，影响业务的连续性和用户体验。建议您配置客户端重试机制，通过重试发起新的连接，特别是支持连接超时、连接reset等异常的重试能力，以提高系统的容错性和稳定性。
在如下的业务场景中，建议配置客户端支持重试的能力：
- 后端服务器健康检查失败：ELB实例的后端服务器健康失败，对于异常后端服务器上存量的四层连接，在会话保持/延迟注销时间内，有报文到达ELB后，仍会转发到异常后端服务器。
- ELB实例跨可用区流量的高可用切换：极端场景下如果ELB实例所在的集群发生单可用区整体故障，多可用区部署的ELB实例会将故障可用区内的流量切换到其他正常的可用区。此时，故障可用区内正在传输数据的长连接无法恢复，需要客户端重新发起连接。
重试的重要性
无论是客户端还是服务端，都有可能受到基础设施或者运行环境的影响，遇到暂时性的故障（例如瞬时的网络抖动/磁盘抖动，服务暂时不可用或者调用超时等），从而导致业务访问的超时。
通过设计完备的客户端自动重试机制可以大幅降低此类故障对业务的影响，保障操作最终能成功执行。
后端服务不可用的场景
|
场景 |
说明 |
|---|---|
|
后端服务器异常 |
后端服务器（ECS/容器），因业务进程夯住、业务进程故障、硬件故障、虚拟化迁移失败、网络不可达等多种故障场景，导致后端服务器健康检查失败。 |
|
复杂的网络环境 |
由于客户端与ELB以及后端服务器之间复杂网络环境引起，可能出现偶发的网络抖动、数据重传等问题，此时，客户端发起的请求可能会出现暂时性失败。 |
|
复杂的硬件问题 |
由于客户端所在的硬件偶发性故障引起，例如虚拟机HA，磁盘时延抖动等场景，此时，客户端发起的请求可能会出现暂时性失败。 |
推荐的客户端重试准则
|
重试准则 |
说明 |
|---|---|
|
重试触发条件 |
连接超时、连接reset等异常场景。 |
|
仅重试幂等的操作 |
推荐仅重试支持幂等性的业务。 执行重试可能导致某个操作被重复执行，因此不是所有操作均适合设计重试机制。 |
|
适当的重试次数与间隔 |
根据业务需求和实际场景调整适当的重试次数与间隔，否则可能引发下述问题：
常见的重试间隔方式包括立即重试、固定时间重试、指数退避时间重试、随机时间重试等。 |
|
避免重试嵌套 |
重试嵌套可能导致重试时间被指数级放大。 |
|
记录重试异常并打印失败报告 |
在重试过程中，建议在WARN级别上打印重试错误日志，同时，仅在重试失败时打印异常信息。 |
|
复用成熟开源生态库重试机制 |
如成熟的开源中间件软件，有丰富的Client端库，基于其连接池的保活机制和探测机制，设置合理的重试间隔和重试次数、以及退避策略等。 自定义重试机制，可以参考开源生态连接池的保活机制和探测机制。 |
