4. 重连策略设计：指数退避、随机窗口、次数限制与状态机

设备掉线不可怕，可怕的是不知道怎么重连。更可怕的是——所有设备都在同一时间疯狂重连，把网络冲垮。

我早期做的一个智能照明项目就吃过这个亏。几十个灯同时断电又同时上电，结果每个灯都在拼命发重连请求，网关直接卡死。从那以后，我彻底明白了：重连策略不是「要不要重连」的问题，而是「怎么重连」的问题。

这一章，我们就把重连策略拆开揉碎。四个核心要素：指数退避算法、随机延迟窗口、重连次数限制、重连状态机。一个一个讲透。

核心观点：重连策略的本质，是在「尽快恢复连接」和「避免网络风暴」之间找平衡。没有策略的重连，就是一场灾难。

重连策略四要素 重连策略 指数退避算法 随机延迟窗口 重连次数限制 重连状态机 四个要素协同工作：退避算法控制间隔，随机窗口避免冲突， 次数限制防止死循环，状态机管理整个流程。

4.1 指数退避算法：别急着冲，越冲越慢

指数退避，说白了就是「每次重连失败后，等的时间越来越长」。第一次等1秒，第二次等2秒，第三次等4秒，第四次等8秒……以此类推。

为什么这么设计？你想想看，如果设备连不上，大概率不是它一个人的问题。可能是网关挂了，可能是网络拥堵，也可能是大批设备同时掉线。这时候所有设备都拼命重连，只会让情况更糟。

指数退避给网络留出了「喘息时间」。第一次重连失败后，等一小会儿；还不行，再多等一会儿。网络压力自然就分散开了。

4.1.1 基础公式

指数退避的核心公式很简单：

delay = base_delay × (2 ^ retry_count) + jitter

其中：

  • base_delay：基础延迟，通常设为1秒或2秒
  • retry_count：当前已重试次数（从0开始）
  • jitter：随机抖动，后面会讲

举个例子，base_delay = 1秒：

重试次数退避时间（无抖动）退避时间（±50%抖动）
01秒0.5 ~ 1.5秒
12秒1.0 ~ 3.0秒
24秒2.0 ~ 6.0秒
38秒4.0 ~ 12.0秒
416秒8.0 ~ 24.0秒
532秒16.0 ~ 48.0秒

看到没？到第5次重试，最坏情况要等48秒。这看起来很久，但恰恰是这种「久」，救了你的网络。

4.1.2 上限截断

指数退避不能无限增长。否则第10次重试要等1024秒，快20分钟了，用户早把设备砸了。

我一般设一个最大退避时间，比如60秒或120秒。超过这个值就不再翻倍，固定用最大值。

#define MAX_BACKOFF_MS  60000  // 最大退避60秒
#define BASE_DELAY_MS   1000   // 基础延迟1秒

uint32_t calculate_backoff(uint8_t retry_count) {
    uint32_t delay = BASE_DELAY_MS * (1 << retry_count);
    if (delay > MAX_BACKOFF_MS) {
        delay = MAX_BACKOFF_MS;
    }
    // 加上随机抖动
    delay += (rand() % (delay / 2)) - (delay / 4);
    return delay;
}

经验之谈：我习惯把最大退避时间设成60秒。太短了起不到分散效果，太长了用户体验差。60秒是个不错的折中点。

4.2 随机延迟窗口：别让设备们「约好」一起重连

指数退避解决了「越等越久」的问题，但还有一个坑：如果所有设备同时掉线，它们的退避时间完全一样，那就会在同一时刻发起重连。这叫什么？这叫「同步风暴」。

随机延迟窗口就是用来打破这种同步的。在每次计算出的退避时间上，加一个随机偏移量。让每个设备的重连时间点都不一样。

4.2.1 抖动范围怎么选

常见的做法是±50%抖动。比如退避时间是4秒，实际等待时间在2秒到6秒之间随机。

也有用±25%的，更保守一些。我个人偏好±50%，分散效果更好。

// 带随机抖动的退避计算
uint32_t get_reconnect_delay(uint8_t retry_count) {
    uint32_t base = BASE_DELAY_MS * (1 << retry_count);
    if (base > MAX_BACKOFF_MS) {
        base = MAX_BACKOFF_MS;
    }
    // ±50% 随机抖动
    int32_t jitter = (rand() % (base + 1)) - (base / 2);
    return base + jitter;
}

注意：随机抖动不能导致延迟为0或负数。代码里要加保护，确保最小延迟不小于某个值（比如100ms）。否则设备可能瞬间发起大量重连请求。

4.3 重连次数限制：不能无限重试下去

指数退避加随机窗口，已经能解决大部分问题。但还有一个关键点：不能无限重试。

你想想看，如果设备真的连不上（比如网关彻底坏了），它还在那里一遍一遍地重试，浪费电量、浪费网络资源、浪费CPU。用户还觉得这设备「卡死了」。

所以，必须设一个最大重试次数。

4.3.1 次数设多少合适

这个没有标准答案，取决于你的应用场景：

场景建议最大重试次数说明
智能灯泡5 ~ 8次用户期望快速响应，重试太久体验差
传感器节点10 ~ 15次可以容忍较长时间离线，但需要省电
网关设备20 ~ 30次网关是核心，应该尽可能重试
门锁/安防无限（带冷却期）安全设备不能放弃连接，但要有冷却机制

我做过的一个智能家居项目，灯泡设了6次重试。6次之后如果还连不上，就进入「离线模式」——只响应本地开关，不再尝试重连，直到用户手动触发。

4.3.2 超过次数后怎么办

超过最大重试次数，不代表永远放弃。常见的做法是：

  • 进入深度休眠：省电，等定时唤醒后再试
  • 上报错误状态：通过其他通道（比如本地指示灯）告诉用户
  • 等待用户干预：用户按一下按键，触发一次新的重连尝试
  • 冷却期后重置：等30分钟或1小时后，重置重试计数器
#define MAX_RETRY_COUNT  6

typedef enum {
    RECONNECT_ACTIVE,    // 正在重连
    RECONNECT_PAUSED,    // 暂停重连（冷却期）
    RECONNECT_IDLE       // 空闲（等待触发）
} reconnect_state_t;

void on_reconnect_failed(uint8_t retry_count) {
    if (retry_count >= MAX_RETRY_COUNT) {
        // 进入冷却期，30分钟后再试
        enter_cooling_period(30 * 60 * 1000);
        return;
    }
    // 继续重连
    schedule_next_reconnect(retry_count + 1);
}

关键原则：重连次数限制不是「放弃设备」，而是「有策略地暂停」。给设备一个冷静期，也给网络一个恢复期。

4.4 重连状态机：把策略变成代码

前面讲了三个策略，怎么把它们组合起来？答案是：状态机。

状态机把重连过程拆成几个清晰的阶段，每个阶段做什么、什么时候切换，一目了然。我习惯用四个状态：

  • IDLE（空闲）：设备在线，不需要重连
  • WAITING（等待）：掉线了，正在等待退避时间结束
  • CONNECTING（连接中）：正在发起重连请求
  • COOLDOWN（冷却）：重试次数用完了，进入冷却期
重连状态机 IDLE（空闲） WAITING（等待） CONNECTING（连接中） COOLDOWN（冷却） 掉线 退避结束 连接成功 失败且未超限 失败且超限 冷却结束

4.4.1 状态机实现示例

下面是一个简化版的状态机实现，把前面讲的三个策略都整合进去了：

typedef enum {
    STATE_IDLE,
    STATE_WAITING,
    STATE_CONNECTING,
    STATE_COOLDOWN
} reconnect_state_t;

typedef struct {
    reconnect_state_t state;
    uint8_t retry_count;
    uint32_t wait_until_ms;
} reconnect_machine_t;

void reconnect_tick(reconnect_machine_t *m, uint32_t now_ms) {
    switch (m->state) {
        case STATE_IDLE:
            // 检测到掉线时触发
            if (is_disconnected()) {
                m->retry_count = 0;
                m->state = STATE_WAITING;
                m->wait_until_ms = now_ms + calculate_backoff(0);
            }
            break;
            
        case STATE_WAITING:
            if (now_ms >= m->wait_until_ms) {
                m->state = STATE_CONNECTING;
                start_connect();
            }
            break;
            
        case STATE_CONNECTING:
            if (is_connected()) {
                m->state = STATE_IDLE;
                m->retry_count = 0;
            } else if (connect_timed_out()) {
                m->retry_count++;
                if (m->retry_count >= MAX_RETRY_COUNT) {
                    m->state = STATE_COOLDOWN;
                    m->wait_until_ms = now_ms + COOLDOWN_PERIOD_MS;
                } else {
                    m->state = STATE_WAITING;
                    m->wait_until_ms = now_ms + calculate_backoff(m->retry_count);
                }
            }
            break;
            
        case STATE_COOLDOWN:
            if (now_ms >= m->wait_until_ms) {
                m->retry_count = 0;
                m->state = STATE_WAITING;
                m->wait_until_ms = now_ms + calculate_backoff(0);
            }
            break;
    }
}

我的习惯：状态机里不要做阻塞操作。WAITING状态用定时器触发，CONNECTING状态用异步回调。这样整个重连过程不会卡住主循环。

4.5 实战中的避坑指南

讲完了理论，说说我在项目中踩过的坑。嗯，每一个都是真金白银换来的教训。

4.5.1 坑一：随机数种子没初始化

我曾经在一个项目里，所有设备的重连延迟一模一样。查了半天，发现是随机数种子没初始化。所有设备都用默认种子，rand()出来的值完全一样。

解决方案：用设备MAC地址或芯片唯一ID做种子。

// 用设备唯一ID初始化随机数种子
void init_random_seed(void) {
    uint32_t seed = get_device_unique_id();
    srand(seed);
}

4.5.2 坑二：退避时间没考虑连接耗时

退避时间是从「开始等待」到「发起连接」的时间。但连接本身也需要时间，可能几百毫秒甚至几秒。如果忽略这个时间，实际重连间隔会比预期短。

我现在的做法：在WAITING状态结束时记录时间戳，连接完成后才计算下一次退避。

4.5.3 坑三：冷却期被意外打断

设备在冷却期里，如果收到用户操作（比如按了开关），要不要立即重连？我的建议是：可以打断冷却期，但不要重置重试计数器。否则用户频繁操作会导致设备永远无法进入冷却期。

重要提醒：重连策略不是写一次就完事的。不同硬件平台、不同网络环境，参数都需要调。我建议在产品开发阶段就留出参数配置接口，方便后期优化。

4.6 小结

这一章我们讲了重连策略的四个核心要素。指数退避让重连间隔越来越长，随机窗口打破设备间的同步，次数限制防止无限重试，状态机把这一切组织起来。

说实话，重连策略看起来简单，但真正做好不容易。我见过太多产品，要么重连太激进把网络打崩，要么重连太消极用户觉得设备坏了。找到那个平衡点，就是你的产品稳定性的分水岭。

← 上一章 📖 返回目录 下一章 →