Swoole中Server->stats统计信息的区别

Server->stats() 返回的是分层、分角色、有时效性的快照值，字段对应不同层级（Reactor/Worker/Task）和生命周期（进程级/全局级），混用易致监控失真。

stats统计信息的区别">

很多人在用 Server->stats() 时都会犯一个错——以为它不过就是一张简单的统计表，把几个字段拿出来算一下就完事了。但实际情况要复杂得多。这个接口返回的可不是单一维度的数据，而是一组分了层、分了角色、甚至有实效性的快照值。不同字段背后是不同的层级（比如 Reactor、Worker、Task），生命周期也不一样（有的是进程级的，有的是全局级的）。如果你把这些混在一起解读，那监控得出的结论十有八九是失真的。

connection_num、accept_count、close_count 这三个连接数为什么对不上

这三个字段虽然都跟“连接”有关，但统计口径完全不一样，千万别想着拿它们做数学平衡。具体来看：connection_num 是当前活跃的 TCP 连接数，由 Reactor 层维护；accept_count 是服务启动以来成功执行 accept() 的总次数；close_count 是已经触发 close() 或超时断开的连接总次数。三者之间不是等号关系，而是一条状态流转链，关键得看差值背后的含义：

• accept_count 在涨，但 connection_num 不动？大概率是连接刚建立就被断开了——可能是客户端异常、SSL 握手失败，或者协议头不对。
• accept_count 减去 close_count 一直在增大，但 connection_num 却不匹配？这基本就是连接泄漏的信号。常见原因：onReceive 回调里忘了调 $server->close()，或是协程没有正确结束。
• connection_num 长期贴着 max_connection 跑？别急着看差值，先看看 accept_count 还在不在增长。如果已经停滞，说明新连接已经被内核拒之门外——大概率是 ulimit -n 设置不够，或者被防火墙拦截了。

worker_request_count 和 request_count 的适用场景差异

这两个计数器经常被人当 QPS 来用，但它们俩的语义和重置时机差异很大，混用的话很容易踩坑。

request_count 是整个 Server 收到的所有协议层请求总数，不管是什么协议——HTTP 的每个 request、TCP 的每个包、UDP 的每个 packet，只要触发了 onReceive、onRequest 或 onPacket，就会算一次。而且这个数在整个主进程生命周期里持续累加，不会自动重置。

worker_request_count 则是当前 Worker 进程自启动以来处理的请求数，一旦 Worker 进程重启，这个值就会归零。它的真正用途，是让你判断单个 Worker 是否过载，配合 max_request 来触发优雅重启时尤其好用。

这里有个常见的坑：有人拿 worker_request_count 来做全局 QPS 估算。一旦 Worker 频繁重启，这个值就会跳变，根本没法用。真想算真实的 QPS，应该用 request_count 做时间窗口差值——当然，时间戳得自己补。

tasking_num、task_queue_num、task_push_count 容易混淆的边界

Task 相关的几个字段，描述的是三个阶段的不同状态，不能直接相加，也不能简单比较大小。

• tasking_num：当前有多少个 task 正在被 task_worker 执行中。换句话说，就是从任务队列里 pop 出来、正在跑回调的那部分。
• task_queue_num：当前等待被 pop 的任务数量，可以理解为内存队列的长度。如果这个值持续走高，说明消费者（task_worker）已经跟不上生产者的节奏了。
• task_push_count：自服务启动以来，成功 push 到队列的任务总数。这包含了已经被 pop 的、正在执行的、还在排队的——所有任务都在里面。

需要警惕一种边界情况：如果 task_push_count - task_pop_count > task_queue_num，说明有任务被丢弃了。常见于队列满了、又没有开启协程回调（task_enable_coroutine=false）的配置下。

stats() 返回值没有时间戳，也不能跨进程聚合

最后说一个很容易被忽略的问题：Server->stats() 本质上是轻量快照，返回的全是整型数值，没有任何上下文信息。

首先，它不记录采集时间，你得自己用 time() 补上，否则没法做速率计算——比如每秒新建连接数，总不能全靠猜吧。

其次，它只反映调用时刻本 Worker 进程看到的状态。在多 Worker 的场景下，worker_request_count、tasking_num 这些字段在每个 Worker 里都是各自独立的，不能简单求和。要想汇总全局数据，你得从 Manager 进程或者外部 HTTP 接口统一拉取各 Worker 的 stats，手动合并。

另外还有个细节：字段是否出现，取决于编译选项和运行时配置。比如没有开启 task 功能，tasking_num 就不会返回；没开 SSL，ssl_accept_count 也不会出现。写监控脚本的时候，最好先判断一下字段是否存在，避免程序跑着跑着就崩了。