高并发 on 姚玉亮的网络日志

分库分表设计：支付与认证场景的水平拆分经验

Fri, 12 Dec 2025 10:30:00 +0800

单表数千万行之后

统一支付平台的订单表和统一认证中心的登录日志表，都长到了单表数千万行。订单查询开始吃紧，日志写入也开始吃紧。

这两张表气质完全不同。订单是按商户维度的高并发写入，登录日志是按用户和时间的海量追加写入。访问模式不同，分片策略就不能套同一个模板。

按商户切订单，按用户切日志

订单表按 merchant_id 哈希，16 库 × 8 表，一共 128 张。商户维度的查询（订单列表、对账）天然落在一个分片内。跨商户的后台统计走 MySQL 到 StarRocks 的离线同步，不做强一致跨片 JOIN。

登录日志按 user_id 分库、再按月份分表。「查某用户最近的登录」落在单片；按月归档清理直接处理整月表，两头都方便。

主键统一用 Snowflake。订单号里嵌入了商户分片位，解析订单号就能直接路由，不用二次查路由表。

订单号里藏着路由

真实项目里我们用 GORM 的 sharding 插件加自研 Resolver，下面是核心路由逻辑的简化版：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


const (
 dbCount = 16
 tableCount = 8
)

func OrderShard(merchantID int64) (db, table int) {
 db = int(merchantID % dbCount)
 table = int(merchantID / dbCount % tableCount)
 return
}

type Order struct {
 ID int64 `gorm:"primaryKey"`
 OrderNo string `gorm:"size:32;uniqueIndex"`
 MerchantID int64 `gorm:"index"`
 Amount int64
 Status int
 CreatedAt time.Time
}

func (o *Order) TableName() string {
 _, t := OrderShard(o.MerchantID)
 return fmt.Sprintf("order_%02d", t)
}

业务侧解析订单号即可路由：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


// 订单号 = 13位毫秒时间戳 + 3位商户分片位 + 5位序列号
func GenOrderNo(merchantID, seq int64) string {
 return fmt.Sprintf("%d%03d%05d",
 time.Now().UnixMilli(), merchantID%1000, seq%100000)
}

func RouteOrderNo(orderNo string) (db, table int) {
 if len(orderNo) < 16 {
 return 0, 0
 }
 bucket, _ := strconv.ParseInt(orderNo[13:16], 10, 64)
 db = int(bucket % dbCount)
 table = int(bucket / dbCount % tableCount)
 return
}

登录日志按月分表：

1
2
3


func LoginLogTable(ts time.Time) string {
 return "login_log_" + ts.Format("200601")
}

坑一个一个说

第一个坑是分片键。一旦选错，代价极大。订单按 merchant_id 分片之后，C 端「查我的订单」会变成广播查询。我们的做法是订单再冗余一份按 user_id 分片到查询库（通过 Canal 同步），复杂检索直接走 ES。别指望一个分片键满足所有查询。

第二，跨片事务尽量避免。订单和账户余额落在同一商户分片内，本地事务就够；跨片的清结算用本地消息表保证最终一致，不上 XA。

第三，分库数量提前规划，但别过度。16 库是按未来几年容量估的，扩容用翻倍法（16→32），配合双写加数据校对平滑迁移。

第四，Snowflake 要防时钟回拨。NTP 同步打底，小幅回拨直接拒绝请求，宁可让调用方重试，也不能吐出重复 ID。

第五，跨片分页是噩梦。LIMIT 100000,20 会在每个分片都执行再归并，我们强制查询带时间范围和分片键，并限制深翻页。

第六，数据迁移必须能回滚。新流量双写新旧库，对账任务比对两边，一致后切读，最后停旧写。每一步都要退得回来。

后来

分库分表是「先苦后甜」，苦的不是中间件配置，是想清楚四件事：按什么维度分片、哪些查询必须落在单片、跨片查询去哪查、未来怎么扩容。统一支付平台和统一认证中心两个场景，这四件事的答案就完全不一样。

封面图：mikecogh / Flickr · CC BY-SA 2.0

Redis 分布式锁在高并发扣减场景的正确姿势

Tue, 11 Nov 2025 10:30:00 +0800

行锁先扛不住了

统一支付平台有个动态计费引擎，订单支付成功后要扣减商户的套餐额度。麻烦在于，PC、小程序、OpenAPI 三端都可能触发同一商户的扣减。最早用 SELECT ... FOR UPDATE 行锁，高并发下数据库连接很快被占满，接口 RT 抖动明显。

后来我们改成 Redis 分布式锁加 Lua 原子扣减，把并发压力从 MySQL 挪到 Redis。

锁按商户加，扣减走 Lua

锁的 key 按商户维度，lock:quota:{merchant_id}，不用全局锁。加锁用 SET key value NX PX 30000，value 是唯一 token（UUID）；释放锁用 Lua 脚本比对 value，防止误删别人的锁。

额度扣减本身也走一段 Lua，把"检查余额 + 扣减"做成原子操作，避免锁内再发多条 Redis 命令。

对执行时间可能超过 30 秒的对账导出任务，另有看门狗自动续期。

加锁、续期、释放

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42


const unlockScript = `
if redis.call("get", KEYS[1]) == ARGV[1] then
 return redis.call("del", KEYS[1])
else
 return 0
end`

type RedisLock struct {
 client redis.Cmdable
 key string
 token string
 ttl time.Duration
}

func (l *RedisLock) TryLock(ctx context.Context) (bool, error) {
 ok, err := l.client.SetNX(ctx, l.key, l.token, l.ttl).Result()
 if err != nil || !ok {
 return false, err
 }
 go l.watchdog(ctx)
 return true, nil
}

func (l *RedisLock) Unlock(ctx context.Context) error {
 return l.client.Eval(ctx, unlockScript, []string{l.key}, l.token).Err()
}

func (l *RedisLock) watchdog(parent context.Context) {
 ticker := time.NewTicker(l.ttl / 3)
 defer ticker.Stop()
 for {
 select {
 case <-parent.Done():
 return
 case <-ticker.C:
 ok, _ := l.client.Expire(parent, l.key, l.ttl).Result()
 if !ok {
 return
 }
 }
 }
}

扣减要原子

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


const deductScript = `
local remain = tonumber(redis.call("HGET", KEYS[1], "remain"))
local need = tonumber(ARGV[1])
if remain == nil or remain < need then
 return -1
end
redis.call("HINCRBY", KEYS[1], "remain", -need)
return remain - need`

func DeductQuota(ctx context.Context, rdb redis.Cmdable, merchantID string, amount int64) (int64, error) {
 key := "quota:" + merchantID
 res, err := rdb.Eval(ctx, deductScript, []string{key}, amount).Result()
 if err != nil {
 return 0, err
 }
 code, _ := res.(int64)
 if code < 0 {
 return 0, ErrQuotaNotEnough
 }
 return code, nil
}

一次事故：A 删了 B 的锁

早期释放锁用的是 GET 再 DEL 两步，出过一次事故：A 业务执行超过 TTL，锁自动过期，B 拿到了锁，A 结束时把 B 的锁删了。Lua 比对 value 这一步是拿事故换来的，不能省。

主从切换那点概率

单实例 Redis 锁在主从切换时有小概率丢锁。统一支付平台是资金场景，我们的兜底是：扣减 Lua 里仍然做余额判断，最终以数据库对账为准。锁只负责并发控制，不是唯一正确性来源。对强一致要求更高的场景，该考虑 etcd/ZooKeeper，而不是盲信 Redlock。

剩下几个细节

看门狗必须和 ctx 绑定，业务结束或 panic 时能退出，不然 goroutine 会泄漏。

锁粒度按 merchant_id，比全局锁吞吐高得多。但要注意单商户的热点 key，某个商户并发特别高的话，还要进一步分桶（quota:{merchant}:{shard}）再聚合。

TTL 取业务 P99 的两倍左右比较稳妥。太长，异常时阻塞；太短，提前过期。

后来

这套方案拢共几样东西：唯一 token 加 Lua 释放，合理 TTL 加看门狗，细粒度的 key。但更关键的是心态：承认 Redis 锁在主从切换等异常下不是强一致的。资金系统里，锁是性能优化，数据库唯一约束和定期对账，才是正确性的底线。

封面图：Horia Varlan / Flickr · CC BY 2.0

基于 Snowflake 的分布式 ID 生成与高并发数据一致性

Tue, 30 Jul 2024 10:30:00 +0800

自增主键先撑不住

统一认证中心要给用户、应用、团队、授权记录这些实体发全局唯一 ID。早期直接用 MySQL 自增主键，问题很快暴露：分库分表之后，自增 ID 在不同分片之间会冲突；业务方希望 ID 自带时间信息，好排序；批量写入时，自增锁还是个热点。

调研了一圈候选：UUID、号段模式（Leaf）、Snowflake。UUID 无序，InnoDB 页分裂严重；号段模式依赖 DB，还得额外部署一套；Snowflake 本地生成、趋势递增、就是个 64 位整型，最对我们的场景。

64 位怎么切，WorkerID 怎么分

经典位分配：1 位符号 + 41 位毫秒时间戳 + 10 位 WorkerID + 12 位序列号，单机每毫秒理论上能出 4096 个 ID。

要花心思的是 WorkerID 怎么分。我们跑在 KubeSphere 上，每个 Pod 用 StatefulSet 的下标派生 WorkerID（0-1023），再配合配置中心给不同服务预留号段范围，避免不同实例撞车。光这样还不放心，启动时把 WorkerID 连同 Pod IP、启动时间写进 Redis，做一次占用校验。

时钟回拨：等还是拒

NTP 同步可能让时间毫秒级倒退，直接生成就是重复 ID，这事没有商量余地。我们的策略分两档：小幅回拨（5ms 内）自旋等待；超过阈值直接拒绝服务并告警，宁可这单失败，不产脏数据。

核心的 NextID 长这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57


const (
 epoch int64 = 1704067200000 // 2024-01-01 00:00:00 UTC
 workerIDBits uint8 = 10
 seqBits uint8 = 12
 maxWorkerID int64 = -1 ^ (-1 << workerIDBits)
 maxSeq int64 = -1 ^ (-1 << seqBits)
)

type Snowflake struct {
 mu sync.Mutex
 lastStamp int64
 workerID int64
 seq int64
}

func NewSnowflake(workerID int64) (*Snowflake, error) {
 if workerID < 0 || workerID > maxWorkerID {
 return nil, fmt.Errorf("workerID %d out of range", workerID)
 }
 return &Snowflake{workerID: workerID}, nil
}

func (s *Snowflake) NextID() (int64, error) {
 s.mu.Lock()
 defer s.mu.Unlock()

 now := time.Now().UnixMilli()
 if now < s.lastStamp {
 offset := s.lastStamp - now
 if offset > 5 {
 return 0, fmt.Errorf("clock moved backwards %dms, refused", offset)
 }
 time.Sleep(time.Duration(offset) * time.Millisecond)
 now = time.Now().UnixMilli()
 if now < s.lastStamp {
 return 0, errors.New("clock still backwards after wait")
 }
 }

 if now == s.lastStamp {
 s.seq = (s.seq + 1) & maxSeq
 if s.seq == 0 {
 // 当前毫秒序列号耗尽，等到下一毫秒
 for now <= s.lastStamp {
 now = time.Now().UnixMilli()
 }
 }
 } else {
 s.seq = 0
 }

 s.lastStamp = now
 id := ((now - epoch) << (workerIDBits + seqBits)) |
 (s.workerID << seqBits) |
 s.seq
 return id, nil
}

业务层通过 Wire 注入单例 *Snowflake，DAO 在 BeforeCreate 钩子中填充主键：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


func (u *User) BeforeCreate(tx *gorm.DB) error {
 if u.ID == 0 {
 id, err := sf.NextID()
 if err != nil {
 return err
 }
 u.ID = id
 }
 return nil
}

五个坑

WorkerID 10 位看着够用，但我们最初把多个服务混在同一号段里，压测时出现跨服务 WorkerID 碰撞。后来按服务前缀切分号段，配置中心统一管。

时钟回拨的阈值不能设太大，也不能直接 panic。5ms 内等待，超过就返回错误让上游降级，比如重试到其他实例。

GORM 的 BeforeCreate 在批量 Create 时每条记录都会调一次，Snowflake 单例的锁竞争要留心。实测万级批量写入时锁等待可接受，再大的批量建议分片。

41 位时间戳能用大约 69 年，epoch 选 2024 年足够；系统要跑到 2090 年以后就得重新评估。

还有一条纪律：别把 WorkerID 写死在配置文件里。Pod 重建后复用了旧 WorkerID、旧实例还活着，就撞了。StatefulSet + 下标派生是目前我们最稳的方案。

后来

Snowflake 原理不复杂，难的是落地那几件事：WorkerID 分配、时钟回拨、批量写入的锁竞争。这套东西在统一认证中心跑了大半年，数千家机构的日常认证请求里没出过 ID 重复，趋势也没乱过。比起自增主键，分库分表和排序场景都省心不少。

封面图：yellowcloud / Flickr · CC BY 2.0