分布式ID

Mon, 03 Aug 2026 00:00:00 +0000

一句话定义

分布式 ID 就是在分库分表、微服务这些场景下，各节点不靠单库自增，自己生成全局唯一、趋势递增的 ID。

为什么需要它

单机时代，MySQL 自增主键 AUTO_INCREMENT 足够。到了分布式场景：

分库分表：多个库各自自增，ID 必然冲突。
微服务：用户服务、订单服务各自独立部署，不能共享一个 auto_increment。

所以得自己搞一套 ID 生成机制，不依赖单库自增。

先记住三句话：

全局唯一是底线，趋势递增是加分项。 唯一性不满足直接炸；不趋势递增只是索引性能差，不会出错。
雪花算法去中心化但怕时钟回拨，号段模式性能好但依赖 DB。 没有银弹，只有权衡。
生产环境优先用现成的轮子。 美团 Leaf、百度 UIDGenerator 都比自己手写靠谱。

方案概览

方案	全局唯一	趋势递增	纯数字	依赖外部
UUID	Y	无序	N	无
数据库自增	Y	Y	Y	DB
号段模式	Y	Y	Y	DB（低频）
雪花算法	Y	Y	Y	无
Redis 自增	Y	Y	Y	Redis

UUID：最简单的方案

import "github.com/google/uuid"

id := uuid.New().String() // 550e8400-e29b-41d4-a716-446655440000

一句话： UUID 随手生成、几乎不可能冲突，但有两个致命伤——字符串太长（128 位，存成字符串 36 字节）且完全无序，做 MySQL InnoDB 主键时页分裂非常严重。

微服务中请求的幂等方案

Thu, 23 Jul 2026 00:00:00 +0000

幂等的意思是：同一个请求无论执行一次还是多次，产生的副作用都和只执行一次一样。

在微服务架构中，网络是不可靠的。客户端超时重试、消息队列重复投递、用户手抖连点两次按钮，都会导致同一笔业务操作被重复提交。如果不做幂等，扣款可能扣两次，订单可能创建两条——这比服务挂了还危险。

先记住三句话：

幂等不是性能优化，是正确性保障。 它保证在重试场景下业务结果唯一，不保证性能。
幂等键的设计决定了方案的可靠程度。 键选错了，整个幂等机制形同虚设。
没有万能方案，只有适合你场景的方案。 Redis 快但有丢失风险，数据库稳但性能有限，删 Token 简单但只适合一次性的场景。

方案一：Redis 幂等键

原理

在请求到达业务层之前，用唯一请求 ID（通常是客户端生成的 UUID）去 Redis 里查一次：

键不存在 → 执行业务，执行完后 SET key 1 EX 300
键已存在 → 说明是重复请求，直接返回已有的结果或拒绝

func (s *OrderService) CreateOrder(ctx context.Context, reqId string, req CreateOrderReq) (*Order, error) {
 // 1. 幂等检查
 key := fmt.Sprintf("idempotent:order:%s", reqId)
 ok, err := s.redis.SetNX(ctx, key, "processing", 5*time.Minute).Result()
 if err != nil {
 return nil, err
 }
 if !ok {
 // 重复请求，直接返回已有结果
 result, _ := s.redis.Get(ctx, key+":result").Result()
 return s.parseOrderResult(result)
 }

 // 2. 执行业务
 order, err := s.create(ctx, req)
 if err != nil {
 // 业务失败要释放锁，允许重试
 s.redis.Del(ctx, key)
 return nil, err
 }

 // 3. 缓存结果
 result, _ := json.Marshal(order)
 s.redis.Set(ctx, key+":result", result, 5*time.Minute)
 return order, nil
}

关键细节

用 SETNX 而非先查后设，避免并发下的竞态。SETNX 是原子操作。
必须设过期时间，否则死 key 会撑爆内存。过期时长要大于单次请求的最长处理时间。
业务失败要删除幂等键，否则客户端想重试都没机会。也可以用状态机：processing → success/failed。
值里存处理状态，而不是只存 1。这样并发请求进来时可以根据状态做更精细的判断。

适用场景

请求量大的读写服务
能接受极低概率的 Redis 数据丢失（可配合持久化策略降低风险）
幂等键由客户端生成（UUID），不依赖业务数据

方案二：数据库防重表

原理

在数据库里建一张专门的防重表，利用数据库的唯一索引 + INSERT 来拦截重复请求。

分布式 on giftiaのblog