系统架构 · 节点协调与集群控制

场景 1 · 结算定时任务 10 副本, 只能有一个实例真的在跑

结算 job 按 Deployment 部了 10 个副本, 全都执行一遍 = 重复扣款。用 etcd concurrency 选主: 只有 leader 进任务, 其余 9 个在 Campaign 上排队, 会话断开自动让位。

cli, _ := clientv3.New(clientv3.Config{
    Endpoints:   []string{"etcd-1:2379", "etcd-2:2379", "etcd-3:2379"},
    DialTimeout: 5 * time.Second,
})
sess, _ := concurrency.NewSession(cli, concurrency.WithTTL(15)) // 15s 会话租约
e := concurrency.NewElection(sess, "jobs/settle/leader")
if err := e.Campaign(ctx); err != nil {
    log.Fatal(err)                    // 阻塞, 直到多数派承认当选
}
defer e.Resign(context.Background())  // 退出主动让位, 不等 TTL
runSettlement(ctx)                    // 只有 leader 走到这里, 其余 9 个还堵在 Campaign
<-sess.Done()                          // etcd 端会话失效(暴毙/网络断)才返回, 进程退出

收益: 从「分布式锁 + 重试轮询」的 40 行轮询代码收敛成 10 行, 且进程被 kill -9 后接管耗时 ≤ TTL(15s)。

场景 2 · 元数据服务 Master 高可用, 直接用 client-go 的 leaderelection

自研元数据服务要求秒级接管, 手写心跳最容易写歪(忘记 renewDeadline、忘记失主回调)。k8s.io/client-go 的 leaderelection 包把三个超时和回调都定好了。

lock := &resourcelock.LeaseLock{
    LeaseMeta:  metav1.ObjectMeta{Namespace: "infra", Name: "meta-master"},
    Client:     kube.Client(),
    LockConfig: resourcelock.ResourceLockConfig{Identity: hostname},
}
leaderelection.RunOrDie(ctx, leaderelection.LeaderElectionConfig{
    Lock:          lock,
    LeaseDuration: 15 * time.Second, // 主失联后 15s 内其他副本可接管
    RenewDeadline: 10 * time.Second, // 每 10s 内必须完成一次续约
    RetryPeriod:   2 * time.Second,  // 续约失败的重试间隔
    Callbacks: leaderelection.LeaderCallbacks{
        OnStartedLeading: startServing, // 当选: 先 warmup 再对外服务
        OnStoppedLeading: drainAndExit, // 失主: 停写 + 退出进程, 防赖着不走
    },
})

经验值: LeaseDuration > RenewDeadline > RetryPeriod × 2, 这个配比在 K8s 自家组件(kube-scheduler/controller-manager)里已验证多年。

场景 3 · 运维平台并发下发配置, Redis 锁防重复推送

配置平台 8 个实例都可能触发「下发到网关」, 并发下发造成版本交错。SET NX PX + Lua 校验 owner 释放, 三件套一个不能少。

owner := uuid.NewString() // 每个持锁者唯一身份
ok, err := rdb.SetNX(ctx, "lock:cfg-push", owner, 30*time.Second).Result()
if !ok { return ErrLocked }              // 别人持有中, 直接拒绝而不是排队
defer func() {
    // 释放必须原子: 校验 owner 后再删, 防止 A 超时后误删 B 的锁
    rdb.Eval(ctx, `if redis.call("GET", KEYS[1]) == ARGV[1] then
        return redis.call("DEL", KEYS[1]) end return 0`,
        []string{"lock:cfg-push"}, owner)
}()
pushConfig(ctx) // 锁内只做下发动作; 超过 30s 的活要靠 watchdog 续期

场景 4 · 网关配置热更新: 从 1s 全量轮询改成 Watch 推送

300 个网关实例每秒全量 GET etcd, 读 QPS 300+ 且变更生效慢 1s。改成 Watch 事件流, etcd CPU 从 60% 降到 8%, 生效从秒级变毫秒级。

var lastRev int64
for { // 外层循环只处理「Watch 断了」, 内层消费事件
    wch := cli.Watch(ctx, "cfg/gateway/",
        clientv3.WithPrefix(), clientv3.WithRev(lastRev+1))
    for wresp := range wch {
        for _, ev := range wresp.Events {
            apply(ev.Kv.Key, ev.Kv.Value)  // PUT/DELETE 都会推过来
            lastRev = ev.Kv.ModRevision    // 记进度, 断线从这继续
        }
    }
    // 走到这里 = Watch 断了; 带 lastRev 重连, 断连窗口内的事件不丢
}

场景 5 · 控制面/数据面分离: 网关规则下发不再拖垮转发

曾把「每请求查一次 etcd 拿路由」写进数据面, etcd 一次 200ms 抖动 = 全站请求 +200ms。改成控制面维护本地快照, 数据面零依赖。

// 控制面(低频): Watch 到变更 → 解析 → 原子替换快照, 不加锁
func onConfigChange(ev *clientv3.Event) {
    tbl := parseRules(ev.Kv.Value)
    atomic.StorePointer(&routes, unsafe.Pointer(&tbl))
}
// 数据面(高频): 每请求只读快照 — etcd 故障时继续用最后已知配置
func route(req *Request) *Target {
    tbl := (*RoutingTable)(atomic.LoadPointer(&routes))
    return tbl.Match(req)
}

量化: 数据面 p99 从 42ms 降到 3ms; etcd 停机演练 10 分钟, 转发成功率 100%(用旧快照)。

场景 6 · 调度器单活: kube-scheduler 的 leaderElection 配置模板

调度器必须单活(两个调度器抢同一个 pod 会绑定两次)。K8s 官方做法是 Lease 资源锁, 双实例部署也只有一个在工作, 直接抄组件配置即可。

# kube-scheduler.yaml — 单活由 Lease 实现, 主失联后备位自动接管
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
leaderElection:
  leaderElect: true
  resourceLock: "leases"       # Lease 对象; 1.14 前的 endpoints/configmap 已废弃
  resourceName: "kube-scheduler"
  resourceNamespace: "kube-system"
  leaseDuration: 15s           # 失联 15s 后其他副本可接管
  renewDeadline: 10s           # 10s 内续不上就主动退出, 不赖位
  retryPeriod: 2s              # 续约重试间隔

场景 7 · 自研 Operator 的 Reconciliation 调谐循环

事件会丢、回调会乱序, 一旦依赖「变更触发」逻辑就会漏。改成对账式: 每 5s 全量 diff 期望与实际, 任何单轮失败都被下一轮自愈。

func (c *Controller) reconcile(ctx context.Context) error {
    want, err := c.listSpec(ctx)   // 期望状态: 用户声明的 replicas=5
    if err != nil { return err }
    got, err := c.listActual(ctx)  // 实际状态: 现在活着的实例
    if err != nil { return err }
    for _, inst := range missing(want, got) {
        c.create(ctx, inst)        // 少了就补
    }
    for _, inst := range extra(want, got) {
        c.delete(ctx, inst)        // 多了就删
    }
    return nil // 不重试不补偿: 下一轮 ticker 会再 diff 一次
}

场景 8 · 事故排查: 续期协程 panic 被吞, 主位静默易主任务双跑

凌晨对账 job 双跑告警。排查发现 KeepAlive 协程在 etcd 重连期间 panic, 被顶层 recover 吞掉 — 没有报错、没有让位, 租约 30s 后过期, 备位无感接管, 两个实例同时跑批。

// 现场日志: lease keep alive failed: etcdserver: requested lease not found
// 根因: etcd 重连期间续期报错 → 防御性 recover() 吞掉 → 无人续期 → 静默失约
go func() {
    defer func() {
        if r := recover(); r != nil {
            log.Fatalf("keepalive died: %v", r) // 修法: 续期死了必须退出进程
        }
    }()
    for range kaCh { } // 正常时每约 TTL/3 收到一次续期回执
    log.Fatal("session closed, resign")  // 通道关闭 = 会话失效 → 让位退出
}()

修复后补了一条黄金指标: lease 秒数剩余量, 剩余 < 5s 告警, 再也没发生过静默失约。

场景 9 · 协调服务选型速查: etcd / ZooKeeper / Consul / Redis

选型不是背参数, 是对齐「互斥强度」和「一致性承诺」。给团队的选型注释, 贴在架构文档里。

# 选型速查(以各官方文档为准):
# etcd      : Raft 强一致 + Watch + Lease; K8s 原生, 客户端最成熟, 首选默认
# ZooKeeper : ZAB 强一致 + 临时节点 + 一次性 Watch; 老牌稳定, 客户端 API 偏啰嗦
# Consul    : LAN/WAN Gossip, 服务发现/多数据中心强; KV 一致性语义弱于 etcd
# Redis     : SET NX PX 只能做「能容忍失效」的弱互斥, 无一致性保证, 必须配 fencing
# 规则: 选主/元数据 → etcd/ZK; 服务发现 → Consul/K8s SVC; 弱锁 → Redis + fencing

场景 10 · 事故排查: 脑裂 4 分钟后, 用 GTID 找出孤儿写

机房网络分区 4 分钟, 降级失败的旧主与新主都收过写。恢复后主从复制报冲突, 第一步永远是: 对比两侧 gtid_executed 的差集, 找出只在旧主上的孤儿事务。

-- 现场定位(新主上执行), MySQL 8.0, gtid_mode=ON
SELECT @@GLOBAL.gtid_executed;   -- 新主: 3E11FA47-...:1-82001
-- 在旧主上执行: 差集 = 只在旧主落过盘的孤儿事务
SELECT GTID_SUBTRACT('3E11FA47-...:1-81990', '3E11FA47-...:1-82001');
-- → '3E11FA47-...:81991-82001' 这 11 个事务就是脑裂窗口的孤儿写
-- 处置: 旧主先钉死只读, 孤儿事务按业务语义人工核对后补写/丢弃
SET GLOBAL read_only = ON;  SET GLOBAL super_read_only = ON;

复盘结论: 事故根因是旧主降级失败(read_only 未生效), 终极解法是存储层 fencing, 而不是更快的切换。