【数据存储】Redis 登录排队与令牌缓冲：开服洪峰的缓冲层

完整课程入口：996 全套课程体系 ｜ Lua 学习路径 ｜ 幂尔框架 mirs.cn

实战应用：用在哪里

新服开放或合服维护后的几分钟内，登录请求是平时几十倍的洪峰。MySQL 直连模式在洪峰下排队堆积、超时重试进一步放大压力。Redis 在登录链路里承担两个角色：排队队列（削峰）与令牌缓冲（会话数据前置），让 MySQL 只承受匀速的稳定负载。

排队队列：LPUSH + 定时消费

-- 客户端请求进入排队
redis:LPUSH("login_queue", playerToken)
-- 服务器定时消费（每秒固定数量）
for i = 1, rateLimit do
    local token = redis:RPOP("login_queue")
    if not token then break end
    processLogin(token)
end

消费速率按数据库承载能力设定（如每秒 200 个），超出的请求留在队列中，客户端显示"排队中，前方还有 N 人"——可见的排队比无响应的等待体验好得多。

令牌缓冲：会话数据前置

登录成功后，会话数据（token、账号 id、角色列表索引、过期时间）写入 Redis 并设置 TTL，游戏服与登录服共享读取。Redis 的读性能（单机 10 万 QPS 级）让高频的会话校验完全不触碰 MySQL。TTL 到期自动清理，配合续期逻辑（活跃会话每次操作刷新 TTL）。

数据一致与容灾

Redis 与 MySQL 之间保持单向依赖：Redis 只存可重建的临时数据（令牌、排队序号），MySQL 存永久数据。Redis 宕机的降级路径：登录切换为直连模式（限流保护数据库），排队功能临时关闭。部署上建议 Redis 开启 AOF 持久化，重启后排队队列可恢复。实测某新服开放场景：每秒 1400 个登录请求经排队消峰后，数据库负载稳定在安全线内，全体玩家在 4 分钟内完成登录，无一例数据异常。

排队体验的三个细节：队列位置每 10 秒刷新一次给客户端；预计等待时间按近一分钟的消费速率滚动计算；玩家主动断开排队时要清理队列中的 token，避免幽灵位置拖慢后续玩家。三处都做到，高峰期的客诉量会明显下降。