共计 2193 个字符,预计需要花费 6 分钟才能阅读完成。
背景痛点
在分布式系统中,我们经常会遇到两个棘手的难题:操作幂等性和跨服务状态同步。这两个问题在以下场景中尤为突出:

- 分布式事务处理:当一个事务需要跨多个服务执行时,网络抖动可能导致重试,产生重复操作
- 消息队列消费:消费者可能因超时等原因重复收到同一条消息
- API 接口调用:客户端重试机制可能导致服务端重复处理请求
这些重复操作如果不加以控制,可能会导致:
- 资金损失:重复扣款或转账
- 数据不一致:库存超卖或数据重复插入
- 系统资源浪费:重复计算消耗 CPU 和 IO 资源
技术对比
传统解决方案各有优劣:
- UUID 方案
- 优点:实现简单,无需存储
- 缺点:无法判断请求顺序,无法实现过期控制
-
性能:生成速度快 (约 100,000 TPS)
-
数据库唯一索引
- 优点:强一致性保证
-
缺点:IO 开销大 (约 1,000 TPS),增加数据库负担
-
Activity Token 方案
- 优点:轻量级 (约 50,000 TPS),内置过期机制,支持状态查询
- 缺点:需要额外存储 (但内存占用小)
核心设计
Activity Token 采用三层结构设计:
- 前缀 (2- 3 字符):标识业务域,如 ”PAY” 表示支付
- 时间戳 (8 字节):毫秒级 Unix 时间戳
- 随机数 (4 字节):防止冲突
完整 Token 格式示例:PAY_1625097600000_AbCd
状态流转图:
stateDiagram-v2
[*] --> Pending: 创建 Token
Pending --> Completed: 业务处理成功
Pending --> Expired: 超时未处理
Completed --> [*]
Expired --> [*]
Redis 实现关键原子操作:
- SETNX:确保 Token 唯一性
- EXPIRE:设置自动过期
- GETSET:状态更新
代码实现 (Go)
Token 生成
func GenerateToken(prefix string, ttl time.Duration) (string, error) {timestamp := time.Now().UnixNano() / 1e6
randStr := RandomString(4)
token := fmt.Sprintf("%s_%d_%s", prefix, timestamp, randStr)
// Redis 原子操作
ok, err := redisClient.SetNX(context.Background(), token, "pending", ttl).Result()
if err != nil {return "", fmt.Errorf("redis error: %v", err)
}
if !ok {return "", errors.New("token already exists")
}
return token, nil
}
Token 验证 (Lua 脚本)
var verifyScript = redis.NewScript(`
local token = KEYS[1]
local newStatus = ARGV[1]
local current = redis.call("GET", token)
if not current then
return {"err", "token not found or expired"}
end
if current ~= "pending" then
return {"err", "invalid status:"..current}
end
redis.call("SET", token, newStatus)
return {"ok", ""}
`)
func VerifyToken(token string) error {result, err := verifyScript.Run(context.Background(),
redisClient, []string{token}, "completed").Result()
// 错误处理...
}
生产环境考量
时钟漂移应对
- 所有节点使用 NTP 同步
- Token 中时间戳采用服务器时间而非客户端时间
- 设置合理的时钟漂移容忍窗口 (如±500ms)
Redis 热点 Key 解决方案
- 分片策略:根据业务前缀分到不同 Redis 实例
- 本地缓存:对已完成的 Token 本地缓存结果
- 读写分离:Completed 状态的 Token 可读从库
监控指标
- Prometheus 指标示例:
tokenCounter = prometheus.NewCounterVec(prometheus.CounterOpts{ Name: "activity_token_total", Help: "Activity token statistics", }, []string{"status"})
关键指标:
– 生成速率
– 过期率 (expired/pending)
– 冲突率 (reject/total)
避坑指南
- 未设置合理 TTL
- 问题:Token 堆积导致内存溢出
-
解决:根据业务最长处理时间设置 TTL(如支付业务设置 30 分钟)
-
忽略网络分区
- 问题:脑裂情况下可能出现状态不一致
-
解决:增加状态机版本号,恢复后校验
-
缺乏重试机制
- 问题:临时 Redis 故障导致合法请求被拒绝
- 解决:实现指数退避重试策略
总结
Activity Token 方案在我们的支付系统中成功将重复交易率从 0.1% 降至 0.001% 以下。实现时需要注意:
- 根据业务特点调整 Token 结构
- 监控关键指标及时发现异常
- 设计完善的灾备方案
这个方案特别适合需要保证操作幂等性但又不想引入复杂分布式事务的中型系统。对于超大规模系统,可以考虑结合分片策略或改用更专业的分布式 ID 服务。
正文完
发表至: 分布式系统
近一天内
