几乎所有做过支付的同学都写过“幂等”两个字，但真正把它做对的人并不多。一个常见的误区是：给请求加个 request_id、建张唯一索引，就以为万事大吉。可当网络抖动、用户狂点、回调乱序同时发生时，系统依然会重复扣款。

幂等的本质不是“去重”，而是“让同一个业务意图，在任意重试次数下只产生一次副作用”。

一、先分清三种“重复”

在动手之前，我们必须区分三种不同层面的重复，它们的解法完全不同：

• 传输层重复：客户端超时重试，同一个 HTTP 请求到达多次。
• 业务层重复：用户真的点了两次“支付”，生成了两个不同的请求。
• 回调层重复：上游渠道的通知被重复推送，或乱序到达。

把这三者混为一谈，是大多数线上事故的根源。传输层重复靠 request_id 解决；业务层重复要靠业务幂等键；回调层重复则必须依赖状态机。

二、用状态机约束一切

支付单的生命周期天然是一个状态机。任何一次状态跃迁，都必须满足前置条件，并且只能沿着合法边进行。这样即使回调重复到达，第二次也会因为“状态已终态”而被安全丢弃。

UPDATE payment
SET status = 'SUCCESS', updated_at = NOW()
WHERE order_no = ?
  AND status = 'PROCESSING';   -- 前置状态约束

-- affected_rows = 0 说明已经被处理过，直接返回成功即可

注意最后一行：重复请求应当返回与首次相同的结果，而不是报错。很多团队在这里返回“重复请求”，结果客户端以为失败又重试了一次。

三、去重表：别把幂等键塞进业务表

如果所有幂等逻辑都挂在业务表上，表结构会迅速腐化。更好的做法是引入一张独立的幂等去重表，它只做一件事：记录“这个幂等键处理到哪一步了”。

CREATE TABLE idempotency_record (
  idem_key     VARCHAR(128) PRIMARY KEY,  -- 幂等键
  biz_type     VARCHAR(32)  NOT NULL,
  status       TINYINT      NOT NULL,     -- 0处理中 1成功 2失败
  response     TEXT,                      -- 首次结果快照
  expire_at    DATETIME     NOT NULL
);

四、小心“处理中”这个中间态

上面的方案有个经典陷阱：如果首次请求在处理中途宕机，幂等键会永远停在“处理中”，后续请求全部被拒。这就是所谓的僵尸锁。解决办法是给“处理中”加一个租约（lease），超时后允许其他请求接管。

永远假设“处理到一半就崩溃”是常态，而不是异常。

五、一个可落地的检查清单

• 幂等键由谁生成？—— 推荐服务端基于业务语义生成。
• 幂等键的粒度是什么？—— 必须与“一次不可分割的业务意图”对齐。
• 重复请求返回什么？—— 首次结果的快照，而不是错误码。
• 中间态有超时机制吗？—— 必须有租约与接管逻辑。
• 有没有对账兜底？—— 幂等防重复，对账防遗漏，两者缺一不可。

幂等不是一个函数，而是一整套围绕状态与副作用建立的纪律。当你把状态机、去重表、租约和对账组合起来，支付链路才真正称得上“可靠”。

凌晨两点，告警群炸了。P99 延迟飙到 3 秒，但 CPU、内存、磁盘看起来都正常。于是三个人开始 grep 日志，半小时后有人猜到了原因，一小时后才确认。这不是某次事故，这是我见过的大多数团队的日常。

可观测性不是“有日志”，而是“能从系统外部推断出内部状态”，并且这个推断要快。

一、三个支柱，三种问题

• Metrics（指标）：系统现在“怎么样”？适合发现异常、触发告警。
• Tracing（链路）：请求“走到哪卡住了”？适合定位跨服务的瓶颈。
• Logging（日志）：这个请求“为什么失败”？信息最全，但最贵、最难查。

关键在于查询顺序：指标发现异常 → 链路定位到具体服务 → 日志解释原因。如果你总是从日志开始，说明前两者没做好。

二、Metrics：只采集“能指导行动”的指标

// 1. 流量
http_requests_total{service, method, status}
// 2. 错误
http_errors_total{service, code}
// 3. 延迟：直方图，而不是平均值
http_request_duration_seconds_bucket{le}
// 4. 饱和度
worker_pool_in_use / worker_pool_size

特别强调：延迟一定要用直方图看分位。平均值会骗人——999 个请求 10ms、1 个请求 10s，平均值依然很好看，但那个 1 才是事故。

三、Tracing：让 trace_id 贯穿全链路

分布式追踪的价值，在于把“一次用户请求”在不同服务里的片段串起来。接入 OpenTelemetry 之后，跨服务调用会自动传递上下文，你要做的只有两件事：入口生成或透传 trace_id，并在日志里始终打印 trace_id。

logger.Info("payment settled",
    zap.String("trace_id", span.SpanContext().TraceID().String()),
    zap.String("order_no", orderNo),
    zap.Duration("latency", time.Since(start)),
)

当用户说“我这笔订单卡住了”，你只要拿到 trace_id，就能直接看到它在哪个服务、哪次数据库调用上花了 2.8 秒。这才是 30 秒定位。

四、Logging：结构化 + 采样

• ERROR 级别：100% 采集。
• INFO 级别：按 trace_id 哈希采样（比如 10%），但保证同一链路全采或全不采。
• DEBUG 级别：默认关闭，需要时动态开启并设置 TTL。

五、告警：对症状告警，而不是对原因

很多团队对 CPU 使用率告警，结果天天误报。CPU 高不一定是问题，用户体验变差才是问题。对“错误率超过 1% 持续 5 分钟”告警，而不是对“某台机器 CPU 高”。每个告警都配一个 Runbook，哪怕只有三行字。

可观测性是一项需要提前投资的能力，它不会在事故当天凭空出现。真正优秀的系统，不是从不故障，而是故障时你依然从容。

Go 让并发变得太容易了，容易到你写下 go func(){...}() 时，根本没想过它什么时候会结束。直到某天服务的内存曲线缓慢爬升，线上 pprof 显示几万个 goroutine 卡在同一个 channel 上。

goroutine 泄漏的可怕之处，在于它不会立刻崩，而是慢慢把内存吃干。

一、泄漏的三种经典形态

1. 向无人接收的 channel 发送

func leak() {
    ch := make(chan int)   // 无缓冲
    go func() {
        ch <- 42           // 永远阻塞，没人接收
    }()
    // 函数返回，ch 无人引用，但 goroutine 永远活着
}

2. 从无人发送的 channel 接收

func leak2() {
    ch := make(chan int)
    go func() {
        v := <-ch          // 永远等不到数据
        _ = v
    }()
}

3. 忘记取消 context

ctx, cancel := context.WithCancel(context.Background())
defer cancel()   // 这一行经常被忘记

二、模式一：Worker Pool（限制并发）

func workerPool(ctx context.Context, jobs <-chan Job, n int) {
    var wg sync.WaitGroup
    for i := 0; i < n; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            for {
                select {
                case <-ctx.Done():
                    return
                case job, ok := <-jobs:
                    if !ok { return }
                    process(ctx, job)
                }
            }
        }()
    }
    wg.Wait()
}

注意两个退出条件：ctx.Done()（外部取消）和 !ok（channel 关闭）。漏掉任何一个，都会泄漏。

三、模式二：errgroup（带错误的并发）

g, ctx := errgroup.WithContext(ctx)
g.Go(func() error { return fetchUser(ctx, id) })
g.Go(func() error { return fetchOrders(ctx, id) })
g.Go(func() error { return fetchCoupons(ctx, id) })
if err := g.Wait(); err != nil {
    return err   // 任意失败，ctx 取消，其余任务自动退出
}

四、模式三：超时与熔断

ctx, cancel := context.WithTimeout(parent, 800*time.Millisecond)
defer cancel()
resp, err := client.Do(req.WithContext(ctx))
if errors.Is(err, context.DeadlineExceeded) {
    metrics.Timeout.Inc()
    return nil, err
}

五、模式四：扇出 / 扇入（Fan-out / Fan-in）

go func() {
    wg.Wait()
    close(out)      // 由唯一的拥有者关闭
}()

六、防泄漏检查清单

• 每个 go 语句，我都能说出它何时退出吗？
• channel 由谁关闭？—— 只由发送方关闭，且只有一个拥有者。
• 有没有 context 贯穿整条链路？cancel 是否被调用？
• 阻塞操作是否都有超时？
• 上线前是否用 goleak 在测试里断言无泄漏？

func TestMain(m *testing.M) {
    goleak.VerifyTestMain(m)   // 测试结束自动检测泄漏
}

把“何时退出”当作写每一个 goroutine 时的第一问，再配合 worker pool、errgroup、超时和 goleak，你就能从“能跑”走向“跑得稳”。