游戏登录服务遭遇连接耗尽时的限流设计，不能把所有压力都归结为某个来源地址请求太多。游戏开服、版本更新后集中登录，可能同时占满入口连接、认证工作线程和数据库连接池；只按 IP 限流，既可能误伤学校、网吧等共享出口玩家，也挡不住分散来源的自动化请求。
先辨明“耗尽”的是哪类资源，再决定在哪一层拒绝、延后或降速。目标不是让登录请求全部通过，而是在容量有限时，优先保住可恢复的服务和正常用户的公平性。
先定位瓶颈：连接数不等于登录请求量
查看入口代理的活动连接、等待队列和超时数，再对照认证服务的工作线程、CPU、下游连接池使用率及登录耗时。若入口连接持续增长但认证请求不多，可能是客户端连接保持过久；若请求已进入认证服务、数据库池却长期占满，继续放宽入口只会把故障传递到下游。
例如，游戏更新结束后，客户端可能集中重连。连接池不足时，登录请求会排队并拖长响应；反之，若认证服务处理正常而入口连接数先触顶，就应优先检查连接空闲超时、请求体读取和连接上限。日志应记录限流原因和分层计数，避免只看到一个总失败率。
按多个维度限流，避免单一门槛误伤
以令牌桶控制短时突发、以并发上限限制正在处理的请求，是两类互补手段：前者允许有限突发后按设定速率恢复，后者直接保护同时占用的工作资源。具体额度要根据压测结果和下游可用容量设置，不能照搬固定数字。
- 全局容量：为认证服务保留明确的并发预算，并给健康检查、必要的内部操作留出空间。下游连接池接近饱和时，及时收紧入口放行量。
- 账号维度：限制单账号短时间内的失败尝试和并发登录，减少撞库及重复提交；不要因一次错误密码就长时间封禁，以免攻击者借此锁住他人账号。
- 设备与会话维度：使用可轮换的设备标识、会话状态识别重复重试。标识应谨慎处理并遵守隐私要求，不能把它当成不可伪造的身份凭证。
- 来源网络维度：IP 或网段限额可作为补充信号，而不是唯一规则。共享出口设较宽松阈值并结合账号行为判断；来源分散但行为相同的请求，则应由账号、设备和全局规则共同约束。
把排队与拒绝设计成玩家可恢复的结果
过载时，短暂登录队列通常比所有请求同时冲击认证后端更可控。队列长度应受限，并为请求设置等待上限；超时后明确返回稍后重试，而不是让客户端无限保持连接。对于入口层的速率限制，可返回 HTTP 429；服务自身暂时无法处理时，可按接口约定返回 503，并提供合理的重试提示。
客户端也要配合：采用指数退避并加入随机抖动，避免大量设备在同一秒重试。若登录包含短信或其他外部验证步骤，应单独限制触发频率，防止登录流量转化为验证资源滥用。运维侧可用 Prometheus 等监控连接数、队列长度、认证耗时、限流命中率和连接池占用；每次调整后观察这些指标是否同步改善。
可执行的上线顺序
- 用监控和日志确认先触顶的是入口连接、认证并发还是下游连接池，并记录正常时段与高峰时段基线。
- 先设置全局并发保护和有上限的登录队列，再增加账号、设备、来源网络等分层规则；逐项启用，便于判断误伤来自哪一层。
- 在压测或小流量阶段验证突发登录、错误密码、共享出口和重试场景，检查正常玩家的失败率、排队时间与后端资源。
- 设置告警和回退开关。若限流命中突然升高而后端仍健康，复核规则是否过紧；若连接池持续饱和，则降低放行量并排查认证链路。
可靠的游戏登录服务遭遇连接耗尽时的限流设计，应让每个限制对应一种可观测的资源或风险：全局规则保容量，账号与设备规则控异常行为，来源规则补充识别，有限队列和退避则减少重试风暴。这样比只按 IP 一刀切更能保护正常登录，也更容易在故障时调整。
常见问题
只按 IP 限流为什么不够？
多个正常玩家可能共用同一出口，攻击请求也可能分散到许多来源。IP 适合作为辅助维度，不能单独代表用户或行为。
令牌桶和并发限制应该选哪种？
它们解决的问题不同。令牌桶控制一段时间内的请求速率，并发限制控制同时占用的资源；保护认证服务时通常需要结合使用。
登录队列越长越好吗？
不是。队列过长会增加等待和连接占用，应按可接受的等待时间及后端恢复能力设置上限，超出后尽早提示重试。
限流后客户端应怎样重试？
采用逐步延长间隔并加入随机抖动，避免所有客户端同时重试；同时遵守服务端返回的重试提示。
