消息队列积压 Mailbox / job queue backlog

原因 ID sp-queue · 主责 研发团队·服务器开发

请求进来的速度超过处理速度、在队列里堆积时，排在后面的请求要过几秒才被处理，或者被丢弃。

起因请求到达的速度超过处理速度 → 结果队列越来越长，超过上限就丢弃 → 画面表现 技能、交易反应慢或被吞

症状: 操作延迟, 吞操作/回档
因素: 延迟, 丢包
谁会遇到: 特定地点/分线, 仅特定功能
何时出现: 人多的时候
负责方: 主责 研发团队·服务器开发
研发团队要做的事: 监控队列长度；采用优先丢弃过时请求的策略；并行处理。
监控图上: 触顶后走平 · 队列长度、最旧消息的滞留时长，每秒处理数
查看位置: 服务器记录的各队列长度、最旧消息的滞留时长、每秒进入数、处理数、丢弃数。没有代码指标时，用 ss（或 netstat）看游戏 socket 的 Recv-Q（内核已收下但进程尚未读取的量）
确认依据: 进入数超过处理数期间，处理数停在某个值上不再上升，队列长度、滞留时长和丢弃数持续增加
排除依据: 队列很短、滞留时长也短，反应却慢，看线路延迟或 tick 本身的延迟
确认手段: 需要游戏服务器/客户端的日志和指标
真实案例: CCP Games 2014: EVE Online HED-GP 大规模舰队战中的服务器过载

出处

Avoiding insurmountable queue backlogs AWS
Amazon Builders' Library。用排队消息的滞留时长监控积压；实时系统先处理新数据（接近 LIFO），旧消息有时直接丢弃
Site Reliability Engineering, Chapter 22: Addressing Cascading Failures Google
请求比处理速度快时队列填满、延迟增加；用 LIFO 或 CoDel 代替 FIFO，去掉已经没用的旧请求
ss(8) — Linux manual page iproute2
显示 socket 统计的工具（信息与 netstat 类似），-p 显示使用 socket 的进程
netstat(8) — Linux manual page net-tools
Recv-Q：已连接 socket 中用户程序尚未取走的字节数