Kratos框架怎么做复杂业务场景下的接口幂等设计-Golang-PHP中文网

Kratos框架虽不内置幂等中间件，但凭借其中间件链、路由分组与依赖注入能力，可分层植入Redis校验、DB兜底、状态机响应三层幂等逻辑；须避免将校验写入handler内部，而应通过外层中间件统一拦截、原子校验与defer终态管理，并强制组合幂等key、设置合理TTL、DB层SELECT确认状态以保障一致性。

kratos框架怎么做复杂业务场景下的接口幂等设计

Kratos 框架本身不内置幂等中间件，但它的中间件链、HTTP 路由分组和依赖注入能力，天然适合分层植入幂等逻辑——关键不是“Kratos 有没有”，而是“你怎么把 Redis 校验、DB 兜底、状态机响应这三层塞进请求生命周期里”。

为什么不能只在 handler 里写 if redis.Exists(...)

常见翻车点：把幂等校验写在业务 handler 内部，比如 func(createOrderHandler) 开头就查 Redis。这样会导致三个问题：

重复代码散落在每个接口里，改 TTL 或 key 规则要改十几处
校验失败时返回逻辑不统一（有的 return 409，有的 panic，有的吞掉 error）
无法拦截已通过校验但 DB 写入失败的请求——因为 handler 已经执行了一半，下游 MQ、日志、监控可能已触发

正确做法是用 Kratos 中间件，在 handler 执行前完成完整校验闭环，并能主动中断后续链路。

用 Kratos middleware 实现三态幂等拦截

核心是写一个中间件，按顺序做三件事：解析幂等 Key → Redis SetNX 拦截 → 注册 defer 清理/回滚钩子。示例结构如下：

func IdempotentMiddleware(rdb *redis.Client, ttl time.Duration) middleware.Middleware {
    return func(handler middleware.Handler) middleware.Handler {
        return func(ctx context.Context, req any) (reply any, err error) {
            // 1. 从 ctx 或 req 提取 idempotencyKey，拼成业务唯一 key，如 "idempotent:order:create:uid123:abc456"
            key := buildIdempotentKey(ctx, req)
<pre class="brush:php;toolbar:false;">        // 2. 原子写入，必须用 SetNX + EX 一条命令
        ok, err := rdb.SetNX(ctx, key, traceIDFromCtx(ctx), ttl).Result()
        if err != nil {
            return nil, errors.New("redis unavailable") // 真错误，不能忽略
        }
        if !ok {
            // 3. 已存在：查 DB 确认真实状态，返回缓存结果或 202
            return queryCachedResult(ctx, key)
        }

        // 4. 新请求：注册 defer，在 handler 执行完后根据结果决定是否删 key 或设终态
        defer func() {
            if err != nil {
                // handler 报错，key 留着，下次重试仍可查 DB 确认
                return
            }
            // handler 成功，但注意：不能直接 DEL，要存终态（success / failed），供重试时返回
            rdb.Set(ctx, key+":result", reply, ttl)
        }()

        return handler(ctx, req)
    }
}

}

这个中间件必须注册在最外层（比如全局或路由分组），否则事务内写 DB 成功但 Redis 失败，会导致后续重试被永久拦截。