MQ 客户端连接管理

概述

连接是 MQ 客户端与 Broker 之间的通信通道，连接管理的好坏直接影响消息收发的稳定性和性能。本文深入探讨长连接与心跳机制、重连策略、Consumer Rebalance、客户端容错以及多数据中心路由等话题。

正文

长连接 vs 短连接

MQ 客户端几乎都使用长连接，原因有三：

建立连接成本高：TCP 三次握手 + MQ 协议握手 + 认证鉴权，一次连接建立可能耗时几十到几百毫秒。如果每发一条消息都建一次连接，性能无法接受。
连接状态维护：消费者需要维持 Offset、订阅关系等状态，这些状态绑定在连接上。
推送模式依赖长连接：Broker 需要通过已有连接向 Consumer 推送消息（或通知拉取），短连接无法实现。

短连接的唯一优势是不需要保活，适合极低频的调用场景。但 MQ 显然不是这种场景。

心跳机制

长连接需要心跳来维持。心跳有两个作用：

保活检测：防止中间设备（NAT、防火墙、LB）因连接空闲超时而断开。
故障发现：Broker 通过心跳超时检测客户端是否存活，及时清理资源。

// 心跳管理器
type HeartbeatManager struct {
    interval   time.Duration
    timeout    time.Duration
    conn       net.Conn
    lastAck    time.Time
    mu         sync.RWMutex
}

func (h *HeartbeatManager) Start(ctx context.Context) {
    ticker := time.NewTicker(h.interval)
    defer ticker.Stop()

    for {
        select {
        case <-ctx.Done():
            return
        case <-ticker.C:
            // 发送心跳
            if err := h.sendPing(); err != nil {
                log.Warn("heartbeat failed", zap.Error(err))
                h.onHeartbeatFailed()
            }
        }
    }
}

func (h *HeartbeatManager) sendPing() error {
    h.conn.SetWriteDeadline(time.Now().Add(h.timeout))
    _, err := h.conn.Write([]byte{0x01}) // 心跳包
    if err == nil {
        h.mu.Lock()
        h.lastAck = time.Now()
        h.mu.Unlock()
    }
    return err
}

典型的配置：

心跳间隔：3-30 秒
Broker 超时：通常为心跳间隔的 3 倍（比如心跳 10 秒，超时 30 秒）
Kafka 默认心跳间隔 3 秒，session timeout 45 秒

重连策略

网络不可避免会抖动，客户端必须有健壮的重连机制。核心是指数退避 + 抖动：

type ReconnectPolicy struct {
    BaseDelay    time.Duration // 初始延迟，如 1s
    MaxDelay     time.Duration // 最大延迟，如 60s
    MaxRetries   int           // 最大重试次数，0 表示无限
    Multiplier   float64       // 退避倍数，通常 2.0
    JitterFactor float64       // 抖动因子，通常 0.1-0.3
}

func (p *ReconnectPolicy) NextDelay(attempt int) time.Duration {
    // 指数退避：delay = base * multiplier^attempt
    delay := float64(p.BaseDelay) * math.Pow(p.Multiplier, float64(attempt))
    if delay > float64(p.MaxDelay) {
        delay = float64(p.MaxDelay)
    }
    // 加入抖动：避免多客户端同时重连造成"惊群效应"
    jitter := delay * p.JitterFactor * (rand.Float64()*2 - 1)
    return time.Duration(delay + jitter)
}

为什么需要抖动？ 如果 1000 个客户端同时断线，没有抖动的话会在同一时刻全部重连，形成"惊群效应"，直接把 Broker 打崩。抖动让重连时间分散开，平滑了压力。

Consumer Rebalance 深入

Rebalance 是 Consumer Group 中最重要的机制之一。当 Group 成员变化时（新加入、离开、心跳超时），需要重新分配 Partition。

触发条件：

新 Consumer 加入 Group
Consumer 主动离开（关闭）
Consumer 心跳超时（被认为宕机）
Topic 的 Partition 数量变化

分配策略：

Range：按 Topic 分区连续分配，简单但容易不均。
RoundRobin：轮询分配，更均匀但实现复杂。
Sticky：尽量保持原有分配不变，只调整必要的部分，减少 Rebalance 开销。
CooperativeSticky（Kafka 2.4+）：增量式 Rebalance，不需要 Stop-The-World。

静态成员（Static Membership）：Kafka 2.3 引入。给每个 Consumer 分配一个固定的 group.instance.id，短暂离线后重新加入时保持原来的 Partition 分配，避免不必要的 Rebalance。

// 静态成员配置
config := sarama.NewConfig()
config.Consumer.Group.InstanceId = "consumer-pod-1" // 固定 ID
config.Consumer.Group.Rebalance.Strategy = sarama.BalanceStrategySticky
config.Consumer.Group.Rebalance.Timeout = 60 * time.Second

[!question] Consumer Rebalance 期间消费会暂停，如何实现"零停顿"的 Rebalance？提示：想想 CooperativeSticky 策略的工作方式。

客户端容错

客户端需要感知 Broker 层的变化：

Broker 故障转移：Producer 连接的 Broker 宕机时，需要自动切换到其他 Broker。
分区 Leader 迁移：某个 Partition 的 Leader 变了，客户端需要感知并更新路由。
元数据刷新：定期从 Broker 拉取最新的元数据（Topic 列表、分区信息、Leader 位置）。

// 元数据自动刷新
type MetadataRefresher struct {
    client     KafkaClient
    interval   time.Duration
    topics     []string
}

func (m *MetadataRefresher) Start(ctx context.Context) {
    ticker := time.NewTicker(m.interval)
    defer ticker.Stop()
    for {
        select {
        case <-ctx.Done():
            return
        case <-ticker.C:
            metadata, err := m.client.RefreshMetadata(m.topics)
            if err != nil {
                log.Error("metadata refresh failed", zap.Error(err))
                continue
            }
            m.updateRoutingTable(metadata)
        }
    }
}

多数据中心客户端路由

全球化部署时，客户端需要智能路由：

就近连接：优先连接同区域的 Broker，降低延迟。
故障转移：本地 Broker 不可用时，自动切换到远端 Broker。
读写分离：本地集群负责读写，远端集群只作为灾备。

stateDiagram-v2
    [*] --> Idle
    Idle --> Connecting: "发起连接"
    Connecting --> Connected: "握手成功"
    Connecting --> Reconnecting: "连接失败"
    Connected --> Heartbeating: "启动心跳"
    Heartbeating --> Connected: "心跳正常"
    Heartbeating --> Reconnecting: "心跳超时"
    Connected --> Reconnecting: "连接断开"
    Reconnecting --> Connecting: "退避结束"
    Reconnecting --> Closed: "超过最大重试"
    Connected --> Closing: "优雅关闭"
    Closing --> Closed: "资源释放完成"
    Closed --> [*]

6.8 KiB Raw Blame History Unescape Escape