应避免直接对ticket_stock表加行锁扣减，而采用Redis预减（DECR）校验+数据库乐观锁（带版本号）二次校验的混合方案，并辅以令牌桶限流、幂等队列和补偿机制保障状态一致。
抢票请求进来时，如何避免数据库行锁争抢
直接对 ticket_stock 表做 UPDATE ... SET stock = stock - 1 WHERE id = ? AND stock > 0 是最常见也最危险的做法——高并发下大量请求会卡在同一条记录的行锁上，造成排队阻塞甚至超时。这不是性能问题，是锁粒度设计错误。
- 用 Redis 做前置库存校验：把余票数缓存在
ticket:123:stock，用DECR原子减；仅当返回值 ≥ 0 时才走 DB 扣减流程 - DB 扣减必须带版本号或乐观锁字段（如
version），避免重复扣减：UPDATE tickets SET stock = stock - 1, version = version + 1 WHERE id = ? AND version = ? AND stock > 0 - 禁止在事务里做 HTTP 调用、日志写入等耗时操作——事务越短越好，否则锁持有时间被意外拉长
用户排队怎么不丢不重不乱序
用 Redis 的 LPUSH + BRPOP 搭配单消费者模型，看似简单，但实际容易漏掉超时重试、重复入队、断连恢复三类问题。
- 每个用户请求生成唯一
req_id（如uuid或user_id:timestamp:seq），入队前先用SETNX ticket:queue:dedup:{req_id} 1 EX 60去重 - 队列项必须包含完整上下文：
{"req_id":"abc","user_id":1001,"ticket_id":123,"created_at":1717023456}，不能只存 ID - 消费者进程需支持优雅退出：收到信号后不再取新任务，处理完当前
BRPOP返回的任务再退出；重启时检查 last_processed_id 避免跳过任务
怎么控制每秒放行多少人进 DB 扣减
令牌桶不是可选优化，是防止下游 DB 瞬间被打爆的刚性防线。硬限流（如 Nginx limit_req）只能控入口，无法适配不同票种、不同场次的差异化速率。
- 为每个
ticket_id维护独立令牌桶：Redis 中用ticket:123:rate_limiter存剩余令牌数和上次刷新时间，每次请求用 Lua 脚本原子计算并更新 - 令牌填充逻辑要防穿透：用
INCR+EXPIRE组合模拟“懒加载”填充，而不是定时任务主动刷——后者在低峰期浪费资源，高峰期可能延迟 - 拒绝时必须返回明确错误码（如
429 Too Many Requests）和Retry-After头，前端据此做退避重试，而不是立刻轮询
超时和失败后状态怎么兜住
用户看到“排队中”，不代表系统真能一直守着这个状态。网络抖动、服务重启、Redis 故障都会导致中间态丢失，此时必须有补偿机制，而不是靠重试硬扛。
立即学习“go语言免费学习笔记（深入）”；
- 所有排队请求写入 MySQL 的
queue_log表（含status、updated_at），哪怕只是临时落盘；Redis 队列只作高速通道，不作唯一状态源 - 启动时扫描
status = 'queued'且updated_at 的记录，触发补偿：查 Redis 是否已出队，未出则重推，已出则查 DB 是否扣成功 - 用户端轮询接口必须返回幂等结果：同一
req_id多次查询，要么返回排队中，要么返回成功/失败，绝不出现“刚刚还排队，现在变失败”这种状态跳跃
真正难的不是并发数字，而是各种异常路径下的状态一致性——Redis 掉了、DB 主从延迟了、消费者进程 OOM 了……这些场景下，日志、补偿、幂等三者缺一不可。
