Nacos服务重试机制：失败自动重试-优快云博客

Nacos服务重试机制：失败自动重试

【免费下载链接】nacos Nacos是由阿里巴巴开源的服务治理中间件，集成了动态服务发现、配置管理和服务元数据管理功能，广泛应用于微服务架构中，简化服务治理过程。项目地址: https://gitcode.com/GitHub_Trending/na/nacos

引言：分布式系统中的服务调用痛点

在微服务架构中，服务间的网络通信面临着各种不确定性。服务不可用、网络抖动、超时等问题都可能导致服务调用失败。如果没有有效的容错机制，这些失败可能会级联传播，最终导致整个系统崩溃。Nacos（Dynamic Naming and Configuration Service，动态命名与配置服务）作为一款优秀的服务发现和配置管理中间件，提供了完善的服务重试机制，能够有效应对这些挑战，提高系统的稳定性和可靠性。

本文将深入剖析Nacos服务重试机制的实现原理、核心参数配置、使用场景以及最佳实践，帮助开发者全面了解并正确应用Nacos的重试功能，构建更加健壮的微服务系统。读完本文，您将能够：

理解Nacos服务重试机制的设计理念和工作流程。
掌握Nacos客户端和服务端重试相关参数的配置方法。
熟练运用Nacos重试机制解决实际项目中的服务调用问题。
了解Nacos重试机制的高级特性和最佳实践。

Nacos服务重试机制概述

Nacos的服务重试机制是指当客户端发起服务调用（如注册、发现、配置获取等操作）失败时，客户端或服务端会根据预设的策略自动进行重试，以期在后续的尝试中成功完成操作。这种机制是Nacos高可用设计的重要组成部分，旨在应对分布式环境中常见的瞬时故障。

重试机制的核心目标

提高操作成功率：通过自动重试，将瞬时故障导致的失败转化为成功。
增强系统稳定性：减少因单点故障或网络波动对整个系统造成的影响。
简化应用开发：将重试逻辑内置于中间件，减轻应用开发者的负担。

Nacos重试机制的应用范围

Nacos的重试机制广泛应用于其客户端与服务端交互的多个环节，主要包括：

配置中心：客户端获取配置、监听配置变更等操作的重试。
服务发现：服务注册、服务心跳、服务列表拉取等操作的重试。
命名服务：对服务实例的查询、订阅等操作的重试。
集群通信：Nacos集群节点间数据同步、选举等操作的重试（服务端内部机制）。

Nacos重试机制的实现原理

Nacos的重试机制主要在客户端实现，部分服务端同步逻辑也涉及重试。其核心思想是在检测到特定类型的失败后，按照预定的策略（如重试次数、重试间隔）再次发起请求。

重试触发条件

Nacos客户端会在以下几种情况下触发重试：

网络异常：如IOException、连接超时、读取超时等。
特定HTTP状态码：如500（Internal Server Error）、502（Bad Gateway）、503（Service Unavailable）、504（Gateway Timeout）等表示服务端暂时不可用或处理超时的状态码。Nacos客户端会认为这些错误是临时性的，因此会尝试更换服务器地址并重试。
服务端明确指示可重试：某些特定的业务异常，服务端可能会通过响应告知客户端可以重试。

重试策略

Nacos的重试策略主要包含以下几个关键要素：

最大重试次数（Max Retry Times）：允许重试的最大次数，超过此次数则停止重试并抛出异常。
重试间隔（Retry Interval）：两次重试之间的等待时间。Nacos通常采用指数退避（Exponential Backoff） 或固定间隔的策略。指数退避策略可以避免在服务恢复初期因大量重试请求而造成的瞬时压力。
重试退避算法：决定重试间隔如何增长。例如，tryTimes * 2L 秒，即第1次重试间隔2秒，第2次4秒，第3次6秒，以此类推。

重试流程

下面是Nacos客户端进行服务调用并触发重试的典型流程：

mermaid

服务端地址选择：Nacos客户端维护了一个服务端地址列表。当某个地址调用失败后，客户端会尝试使用列表中的下一个地址进行重试，这有助于分散负载和规避单点故障。

Nacos重试机制核心参数配置

Nacos提供了一系列可配置的参数，允许开发者根据实际需求调整重试行为。这些参数可以通过客户端属性（Properties对象或配置文件）进行设置。

核心重试参数

参数名 (NacosProperties)	环境变量/系统属性对应	描述	默认值	适用范围
`maxRetry`	`nacos.maxRetry`	客户端操作的最大重试次数。	3	通用
`configRetryTime`	`nacos.configRetryTime`	配置中心操作的重试间隔时间（毫秒）。	无	配置中心
`configLongPollTimeout`	`nacos.configLongPollTimeout`	配置中心长轮询超时时间（毫秒），超时后可能触发重试。	30000	配置中心

说明：

maxRetry 是一个比较通用的参数，在多个客户端模块中都有应用，例如维护者客户端（maintainer-client）的HTTP请求重试。
configRetryTime 主要用于配置拉取等操作的重试间隔。

参数解析与示例

`maxRetry` (最大重试次数)

该参数定义了客户端在放弃之前最多尝试的次数（不包括首次请求）。例如，如果maxRetry设置为3，则客户端最多会进行1次初始请求 + 3次重试请求，共4次尝试。

在Nacos的ParamUtil类中，可以看到其默认值的设置：

private static final int DEFAULT_MAX_RETRY_TIMES = 3;

在ClientHttpProxy类中，maxRetry参数被用于控制HTTP请求的重试逻辑：

private final int maxRetry = ParamUtil.getMaxRetryTimes();

// 在executeSyncHttpRequest方法中
int retryCount = maxRetry;
while (System.currentTimeMillis() <= endTime && retryCount >= 0) {
    try {
        // 执行HTTP请求...
        if (result.ok()) {
            return result;
        }
        throw new NacosException(result.getCode(), result.getMessage());
    } catch (Exception e) {
        // 处理异常...
        retryCount--; // 重试次数递减
        if (isFail(resultCode)) {
            currentServerAddr = serverListManager.genNextServer(); // 更换服务器地址
        }
        Thread.sleep(100); // 简单的固定小间隔等待
    }
}

`configRetryTime` (配置重试时间)

该参数指定了配置中心相关操作失败后的重试间隔时间。虽然在代码中直接设置该参数的场景未直接展示，但它通常会与maxRetry配合使用，共同决定重试策略。

客户端配置示例

以下是在Java客户端中配置重试参数的示例：

import com.alibaba.nacos.api.NacosFactory;
import com.alibaba.nacos.api.config.ConfigService;
import com.alibaba.nacos.api.exception.NacosException;

import java.util.Properties;

public class NacosConfigExample {
    public static void main(String[] args) throws NacosException {
        Properties properties = new Properties();
        properties.setProperty("serverAddr", "127.0.0.1:8848");
        properties.setProperty("namespace", "public");
        
        // 配置重试参数
        properties.setProperty("maxRetry", "5"); // 最大重试次数设为5
        properties.setProperty("configRetryTime", "1000"); // 配置重试间隔设为1000毫秒
        
        ConfigService configService = NacosFactory.createConfigService(properties);
        // 使用configService进行操作...
    }
}

Nacos重试机制关键代码解析

为了更深入地理解Nacos重试机制的实现，我们来分析几个关键的代码片段。

1. 维护者客户端的HTTP重试 (`ClientHttpProxy.java`)

ClientHttpProxy类中的executeSyncHttpRequest方法展示了一个典型的客户端HTTP请求重试逻辑：

public HttpRestResult<String> executeSyncHttpRequest(HttpRequest request) throws NacosException {
    long endTime = System.currentTimeMillis() + ParamUtil.getReadTimeout();
    String currentServerAddr = serverListManager.getCurrentServer();
    int retryCount = maxRetry; // 从ParamUtil获取maxRetry配置
    int resultCode = 0;
    NacosException requestException = null;

    while (System.currentTimeMillis() <= endTime && retryCount >= 0) {
        try {
            HttpRestResult<String> result = executeSync(request, currentServerAddr);
            if (result.isNoRight()) {
                reLogin(); // 权限问题，重新登录
            }
            if (result.ok()) {
                return result; // 成功，返回结果
            }
            throw new NacosException(result.getCode(), result.getMessage());
        } catch (NacosException nacosException) {
            requestException = nacosException;
            resultCode = nacosException.getErrCode();
        } catch (Exception ex) {
            LOGGER.error("[NACOS Exception] Server address: {}, Error: {}", currentServerAddr, ex.getMessage());
            resultCode = HttpURLConnection.HTTP_INTERNAL_ERROR;
        }

        // 判断是否需要重试
        if (isFail(resultCode)) {
            currentServerAddr = serverListManager.genNextServer(); // 选择下一个服务器地址
        }
        retryCount--; // 重试次数减一

        try {
            Thread.sleep(100); // 短暂休眠后重试
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }

    // 重试耗尽，抛出异常
    if (null != requestException) {
        throw new NacosException(requestException.getErrCode(),
                "No available server after " + maxRetry + " retries, last tried server: " + currentServerAddr
                        + ", last errMsg: " + requestException.getErrMsg());
    }
    throw new NacosException(NacosException.BAD_GATEWAY,
            "No available server after " + maxRetry + " retries, last tried server: " + currentServerAddr);
}

// 判断HTTP状态码是否表示需要重试的失败
private boolean isFail(int resultCode) {
    return resultCode == HttpURLConnection.HTTP_INTERNAL_ERROR || // 500
           resultCode == HttpURLConnection.HTTP_BAD_GATEWAY ||    // 502
           resultCode == HttpURLConnection.HTTP_UNAVAILABLE ||    // 503
           resultCode == HttpURLConnection.HTTP_GATEWAY_TIMEOUT;  // 504
}

关键点：

循环条件：System.currentTimeMillis() <= endTime && retryCount >= 0，确保在超时时间内且重试次数未耗尽。
服务器地址切换：当检测到isFail(resultCode)为true时，通过serverListManager.genNextServer()选择下一个可用的Nacos服务器地址。
重试计数递减：每次失败后retryCount--。
短暂休眠：Thread.sleep(100)，避免过于频繁的重试对服务器造成压力。

2. 配置推送任务的重试 (`FuzzyWatchSyncNotifyTask.java`)

在Nacos服务端，对于配置变更的推送（如FuzzyWatchSyncNotifyTask）也存在重试逻辑，并且采用了指数退避策略：

class FuzzyWatchSyncNotifyTask implements Runnable {
    // ... 其他成员变量和方法 ...

    /**
     * The maximum number of times to retry pushing the request.
     */
    int maxRetryTimes;

    /**
     * The current number of attempts made to push the request.
     */
    int tryTimes = 0;

    @Override
    public void run() {
        if (isOverTimes()) { // 检查是否达到最大重试次数
            // 如果超过最大重试次数，记录警告并注销客户端连接
            Loggers.REMOTE_PUSH.warn(
                    "Push callback retry failed over times. groupKeyPattern={}, clientId={}, will unregister client.",
                    notifyRequest.getGroupKeyPattern(), connectionId);
            connectionManager.unregister(connectionId);
        } else if (connectionManager.getConnection(connectionId) != null) {
            tryTimes++; // 尝试次数加一
            TpsCheckRequest tpsCheckRequest = new TpsCheckRequest();
            tpsCheckRequest.setPointName(CONFIG_FUZZY_WATCH_CONFIG_SYNC);
            if (!ControlManagerCenter.getInstance().getTpsControlManager().check(tpsCheckRequest).isSuccess()) {
                scheduleSelf(); // TPS检查失败，稍后重试
            } else {
                // 执行推送并注册回调
                rpcPushService.pushWithCallback(connectionId, notifyRequest, new FuzzyWatchSyncNotifyCallback(this),
                        ConfigExecutor.getClientConfigNotifierServiceExecutor());
            }
        }
    }

    void scheduleSelf() {
        // 指数退避策略：tryTimes * 2L 秒
        ConfigExecutor.scheduleClientConfigNotifier(this, tryTimes * 2L, TimeUnit.SECONDS);
    }

    /**
     * Checks if the maximum number of retry times has been reached.
     *
     * @return true if the maximum number of retry times has been reached, otherwise false
     */
    public boolean isOverTimes() {
        return maxRetryTimes > 0 && this.tryTimes >= maxRetryTimes;
    }
}

关键点：

指数退避重试：scheduleSelf()方法中，tryTimes * 2L 秒的延迟，意味着重试间隔会随着失败次数的增加而指数增长（2秒、4秒、6秒...）。
尝试次数跟踪：tryTimes变量记录当前重试次数，与maxRetryTimes比较判断是否终止。
TPS控制：在重试前进行TPS（Transactions Per Second）检查，防止重试请求过多导致服务过载。

3. 重试参数的获取与初始化 (`ParamUtil.java`)

ParamUtil类负责读取和初始化与重试相关的配置参数，例如maxRetryTimes：

public class ParamUtil {
    private static final String MAINTAINER_CLIENT_MAX_RETRY_TIMES_KEY = "MAINTAINER.CLIENT.MAX.RETRY.TIMES";
    private static final int DEFAULT_MAX_RETRY_TIMES = 3;

    static {
        // ... 其他参数初始化 ...
        maxRetryTimes = initMaxRetryTimes();
        LOGGER.info("[settings] [maintainer-http-client] max retry times:{}", maxRetryTimes);
        // ... 其他参数初始化 ...
    }

    private static int initMaxRetryTimes() {
        try {
            return Integer.parseInt(NacosClientProperties.PROTOTYPE.getProperty(MAINTAINER_CLIENT_MAX_RETRY_TIMES_KEY,
                    String.valueOf(DEFAULT_MAX_RETRY_TIMES)));
        } catch (NumberFormatException e) {
            final String msg = "[http-client] invalid max retry times:" + maxRetryTimes;
            LOGGER.error("[settings] {}", msg, e);
            throw new IllegalArgumentException(msg, e);
        }
    }

    public static int getMaxRetryTimes() {
        return maxRetryTimes;
    }

    // ... 其他方法 ...
}

关键点：

默认值：DEFAULT_MAX_RETRY_TIMES 设置为3。
配置读取：通过 NacosClientProperties.PROTOTYPE.getProperty 读取配置，如果配置无效则抛出异常。
对外提供：通过 getMaxRetryTimes() 方法供其他类获取最大重试次数。

Nacos重试机制的使用场景与最佳实践

Nacos的重试机制虽然强大，但并非在所有场景下都适用。合理配置和使用重试机制，需要结合具体的业务场景和系统特性。

适用场景

瞬时故障：重试机制最适合处理临时性、瞬时性的故障，如网络闪断、服务端短暂过载等。对于永久性故障（如服务彻底下线、接口变更），重试是无效的，反而会浪费资源。
幂等操作：重试的操作必须是幂等的。即多次执行同一个操作，产生的结果与执行一次是相同的。例如，读取配置、查询服务列表等都是天然幂等的。对于非幂等操作（如创建订单、扣减库存），需要格外小心，确保重试不会导致数据不一致或重复执行。
非实时性要求不高的操作：重试会增加操作的延迟。对于实时性要求极高的操作，可能需要结合熔断、降级等其他容错手段。

不适用场景

写操作无幂等性保证：如果重复执行写操作会导致不可预期的后果（如重复支付），则不应轻易重试。
已知服务端不可用：如果已经明确知道服务端长时间不可用（如维护期间），继续重试没有意义。
资源消耗巨大的操作：某些操作本身消耗大量资源（如CPU、内存、带宽），频繁重试可能加剧系统负担。

最佳实践

合理设置重试次数和间隔：
- maxRetry：不宜设置过大。过多的重试会增加系统响应时间，并可能导致重试风暴（Thundering Herd Problem）。一般建议设置为3-5次。
- 重试间隔：采用指数退避策略（如Nacos服务端推送任务）比固定间隔更优，可以有效分散重试请求，避免对服务端造成二次冲击。
结合超时时间设置：重试次数和单次请求超时时间需要配合。例如，单次超时时间为1秒，最大重试次数为3次，则总超时可能达到 1 + 2 + 4 = 7秒（假设指数退避）。需要确保总超时在业务可接受范围内。
确保操作幂等性：在使用重试机制前，务必确认被重试的操作是幂等的。对于非幂等写操作，可以考虑引入唯一ID（如UUID）或版本号机制来保证幂等性。
监控与告警：对重试次数、失败率等指标进行监控。如果某个服务的重试次数突然增加，可能预示着该服务存在潜在问题，需要及时排查。
与熔断降级配合使用：重试机制通常需要与熔断（Circuit Breaker） 和降级（Degradation） 机制配合使用，形成完整的容错体系。当失败次数达到阈值时，熔断器打开，暂时停止对该服务的调用，避免大量无效重试，待服务恢复后再关闭熔断器。Nacos客户端可以与Sentinel、Resilience4j等熔断降级组件集成。
区分可重试与不可重试异常：并非所有异常都值得重试。例如，NullPointerException、IllegalArgumentException等客户端自身的编程错误，重试是没有意义的。Nacos客户端会根据异常类型和HTTP状态码来判断是否重试（如ClientHttpProxy中的isFail方法）。

配置建议

通用配置：将 maxRetry 设置为3-5次。
配置中心：对于配置拉取，可以适当增加 configLongPollTimeout，减少不必要的短轮询重试。
服务发现：确保客户端能够及时获取最新的服务列表，以便重试时可以切换到健康的服务实例。
生产环境：建议在压测后根据实际性能表现调整重试参数，避免默认参数在高并发场景下不适用。

总结与展望

Nacos的服务重试机制是保障分布式系统稳定性的重要手段。通过自动重试，Nacos能够有效应对分布式环境中的瞬时故障，提高服务调用的成功率。本文从机制概述、实现原理、核心参数、代码解析、使用场景和最佳实践等多个方面，全面介绍了Nacos的服务重试机制。

核心要点回顾：

Nacos重试机制主要在客户端实现，部分服务端同步逻辑也有应用。
核心参数包括 maxRetry (最大重试次数) 和 configRetryTime (配置重试间隔)。
重试策略包括固定间隔和指数退避，后者能更好地避免重试风暴。
关键代码体现了循环重试、服务器地址切换、重试计数和退避算法等核心逻辑。
最佳实践强调幂等性、合理配置参数、与熔断降级配合以及监控告警。

随着微服务架构的不断发展，对中间件的高可用要求越来越高。未来，Nacos的重试机制可能会在以下方面进一步优化：

更智能的重试策略：结合机器学习或自适应算法，根据历史失败模式动态调整重试次数和间隔。
细粒度的重试控制：允许针对不同服务、不同操作类型配置差异化的重试策略。
与可观测性深度融合：提供更丰富的重试相关指标和日志，帮助开发者更好地定位和解决问题。

掌握Nacos的重试机制，并将其与实际项目结合，能够显著提升微服务系统的稳定性和容错能力。希望本文能为您在Nacos的实践之路上提供有益的参考。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

Nacos服务重试机制：失败自动重试