系统架构 · 通用机制知识图谱

场景 1 · 结算任务 10 个副本, 每天 0 点发了 10 份工资单

定时任务多副本部署却没有选主, 谁的 cron 先到谁执行 → 数据重复处理。用 etcd 租约 + Election 选出唯一执行者。

// 结算任务部署 10 副本, 只允许 1 个执行: etcd lease + election
sess, err := concurrency.NewSession(cli, concurrency.WithTTL(15))
if err != nil { log.Fatal(err) }
e := concurrency.NewElection(sess, "batch/settle/leader")

go func() {
    for {
        if err := e.Campaign(ctx); err != nil { continue } // 竞选, 阻塞到当选
        runDailySettle(ctx)                                // 当选: 唯一执行批任务
        e.Resign(ctx)                                      // 主动让位, 发布时平滑换主
    }
}()
<-ctx.Done()  // 关键: 进程死→会话死→lease 过期, 其他副本 15s 内自动补位

上线后 10 副本每天只有 leader 跑批, 主宕机切换窗口 = 会话 TTL 15 秒。

场景 2 · Leader 一次 Full GC 停 20 秒, 双主双写坏数据

心跳 5s 超时即切主 → 旧主 GC 结束醒来继续写, 新旧两主并存。修法: client-go 的 lease 选举参数放宽 + 存储层校验 fencing。

lock := &resourcelock.LeaseLock{
    LeaseClient: coordClient,
    LeaseMeta:   metav1.ObjectMeta{Namespace: "prod", Name: "batch-runner"},
    Identity:    id,
}
leaderelection.RunOrDie(ctx, leaderelection.LeaderElectionConfig{
    Lock:          lock,
    LeaseDuration: 15 * time.Second, // 15s 没续约才判死 — 别设 3s, 一次 GC 就误切
    RenewDeadline: 10 * time.Second,
    RetryPeriod:   2 * time.Second,
    Callbacks: leaderelection.LeaderCallbacks{
        OnStartedLeading: runSettle,
        OnStoppedLeading: func() { log.Fatal("lost leadership, exit") }, // 失主即自杀防双主
    },
})
// 关键: 下游存储仍要校验 fencing token — GC 20s 的旧主写进来直接 409 拒绝

场景 3 · 订单表 4 亿行, 4 库扩到 8 库不停机

hash(orderID) % 4 改成 % 8, 3/4 的行路由全变, 停机迁移要 3 天。换成一致性哈希环, 只有新旧路由不一致的行才搬。

type Ring struct{ vnodes []vnode }  // 每个物理库挂 200 个虚拟节点

func (r *Ring) Get(key string) *DB {
    h := crc32.ChecksumIEEE([]byte(key))
    i := sort.Search(len(r.vnodes), func(i int) bool { return r.vnodes[i].hash >= h })
    return r.vnodes[i%len(r.vnodes)].db // 关键: 顺时针第一个 >= h 的 vnode
}

// 迁移期双写: 新旧库都写, 读走旧库, 后台只搬 route 变化的行, 校验后切读
for _, order := range backlog {
    if ring8.Get(order.ID) == ring4.Get(order.ID) { continue }
    migrate(ctx, order)
}
// 收益: 4 亿行只搬约 1/8, 迁移窗口从 3 天缩到 4 小时

场景 4 · 用户改完头像刷新还是旧图 — 主从延迟 3 秒

写主库、读从库, 复制延迟 3s 内用户看到旧数据, 工单刷屏。做"读己之写": 记住写操作的 GTID, 从库追上才读, 追不上读主。

// 写: 记录本次写入的全局事务序
db.Exec("UPDATE users SET avatar=? WHERE id=?", avatar, uid)
gtid, _ := queryScalar(db, "SELECT @@GLOBAL.gtid_executed")
session.Set("w_gtid", gtid)

// 读: 从库先追上这个 GTID 才服务本次读, 1s 追不上降级读主
err := replica.QueryRow(
    "SELECT WAIT_FOR_EXECUTED_GTID_SET(?, 1)", gtid).Err()
if err != nil {
    row = master.Query("SELECT avatar FROM users WHERE id=?", uid)
}
// 关键: 只对"写后立刻读"的请求付出这个代价, 其余照走从库

场景 5 · Kafka 消费组 5 分钟一次重平衡, 堆积 2000 万条

单条消息处理慢, 两次 poll 间隔超过 max.poll.interval.ms → 被踢出组 → 全组停止消费重新分配 → 雪崩式堆积。调参 + 换增量重平衡。

# consumer.properties — 重平衡风暴的三板斧
session.timeout.ms=30000          # 30s 没心跳判死 (broker 侧判定)
heartbeat.interval.ms=3000        # 心跳间隔 ≈ session/3
max.poll.interval.ms=600000       # 两次 poll 上限: 给慢处理留足时间
max.poll.records=500              # 关键: 少拉快提, 别一次 5000 条噎死自己
partition.assignment.strategy=CooperativeStickyAssignor
# 增量重平衡 (2.4+): 只挪动受影响的分区, 其余消费者不停

重平衡从每天 288 次降到 0 次(只在新消费者加入时增量发生), 消费延迟稳定在 3 万条以内。

场景 6 · 库存服务一抖, 整条下单链路陪葬

无超时无熔断: 下游 P99 3s, 上游线程池 200 被慢慢占满, 最后全站 503。三件套: 超时递减 + gobreaker 熔断 + 兜底返回。

cb := gobreaker.NewCircuitBreaker(gobreaker.Settings{
    Name:     "inventory",
    Interval: 10 * time.Second,  // Closed 态错误统计窗口
    Timeout:  30 * time.Second,  // Open 冷却 30s 后进 Half-Open
    ReadyToTrip: func(c gobreaker.Counts) bool {
        return c.Requests >= 50 && float64(c.TotalFailures)/float64(c.Requests) > 0.5
    },
})
resp, err := cb.Execute(func() (any, error) {
    ctx, cancel := context.WithTimeout(ctx, 800*time.Millisecond) // 上游剩 1s, 我只花 0.8s
    defer cancel()
    return invClient.Reserve(ctx, req)
})
if errors.Is(err, gobreaker.ErrOpenState) {
    return fallbackEstimate(req) // 关键: 熔断走兜底, 不是把错误抛给用户
}

场景 7 · 秒杀 5 万 QPS, 数据库连接池先阵亡

限流做在应用内存里, 20 台机器 = 20 份配额互不知晓; 改成 Redis + Lua 把"判定+扣减"做成原子操作, 集群级精确限流。

-- KEYS[1]=令牌桶  ARGV: rate 令/秒, capacity 桶容量, now(ms), 本次请求 n
local rate, cap = tonumber(ARGV[1]), tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local b = redis.call('HMGET', KEYS[1], 'tokens', 'ts')
local tokens = math.min(cap, (tonumber(b[1]) or cap) +
    (now - (tonumber(b[2]) or now)) / 1000 * rate)
local allowed = 0
if tokens >= tonumber(ARGV[4]) then
    tokens = tokens - tonumber(ARGV[4]); allowed = 1
end
redis.call('HMSET', KEYS[1], 'tokens', tokens, 'ts', now)
redis.call('PEXPIRE', KEYS[1], 60000)
return allowed  -- 关键: 判定+扣减一个原子脚本, 多机也不会放超

场景 8 · 支付回调重复推送, 用户被扣两次钱

第三方支付 at-least-once 重试回调是常态, 处理函数不幂等就会重复加钱。模板: 唯一索引挡重, 重复回调直接回成功止住对方重试。

func HandlePayCallback(req PayNotify) error {
    // 幂等闸门: 回调带 order_no, 唯一索引挡重
    res, err := db.Exec(
        `INSERT IGNORE INTO pay_callback(order_no, amount, status)
         VALUES (?, ?, 'paid')`,
        req.OrderNo, req.Amount)
    if err != nil { return err }
    if n, _ := res.RowsAffected(); n == 0 {
        return nil  // 关键: 重复回调当成功返回, 上游就不再重试
    }
    return creditUser(req)  // 只有首个回调走到真加钱
}

场景 9 · 订单写成功、库存没扣 — 双写不一致

先写订单库再发 MQ, 中间服务崩溃就永久丢事件。Outbox 模式: 业务数据与事件同事务落库, relay 异步投递, 用至少一次 + 消费幂等换最终一致。

func CreateOrder(o Order) error {
    tx, _ := db.Beginx()
    defer tx.Rollback()
    tx.Exec("INSERT INTO orders(order_no, sku, qty) VALUES(?,?,?)", o.No, o.Sku, o.Qty)
    tx.Exec("INSERT INTO outbox(topic, payload) VALUES('order.created', ?)",
        toJSON(o))  // 关键: 业务表和事件同生共死, 同一事务提交
    return tx.Commit()
}
// relay 轮询投递 MQ (至少一次), 消费端用去重表兜住重复:
// SELECT * FROM outbox WHERE sent=0 ORDER BY id LIMIT 100 FOR UPDATE SKIP LOCKED

场景 10 · JVM 服务 K8s 发版, 滚动更新雪崩 5 分钟

大堆 JVM 启动要 4 分钟, 默认探针 30s 判死 → Pod 被反复杀 → 越杀越慢。三层探针各司其职: startup 给启动预算, readiness 摘流量, liveness 只查进程自身。

# deployment.yaml — 启动慢的应用必须配 startupProbe
startupProbe:
  httpGet: { path: /healthz, port: 8080 }
  periodSeconds: 5
  failureThreshold: 60      # 5s × 60 = 300s 启动预算, 期间不杀不摘
readinessProbe:
  httpGet: { path: /ready, port: 8080 }
  periodSeconds: 5
  failureThreshold: 3       # 未就绪只摘流量不重启 — 扛住预热窗口
livenessProbe:
  httpGet: { path: /live, port: 8080 }
  periodSeconds: 10          # 关键: 只查"自己还能动吗", 不碰 DB/下游