从轮询到长连接：在线人数统计的完整技术方案与避坑指南

做站点运维或者独立开发的人，几乎都会在某个阶段冒出一个念头：现在到底有多少人正在看我的页面？这个需求听起来简单，真动手做的时候却会发现坑一个接一个——统计口径怎么定、数据存在哪、页面关掉的那一刻怎么通知服务端、多标签页算一个人还是两个人、刷新一下人数会不会突然翻倍。我前后在几个不同类型的站点上折腾过在线人数统计，从最初用定时轮询硬扛，到后来换成基于长连接的方案，中间踩的坑足够写一篇完整的复盘。这篇就把"查询网站在线人数"这件事从头到尾拆开讲清楚，包括技术选型的取舍逻辑、核心实现的关键细节、以及那些文档里基本不会写但实际一定会遇到的问题。

需要先说明的是，在线人数统计本质上是一个"状态维护"问题，而不是简单的计数问题。很多人第一反应是搞一个全局变量加一减一，本地跑起来没问题，一上线就发现数字乱跳。原因在于HTTP本身是无状态的，服务端根本不知道一个用户什么时候"离开"。你看到的每一个在线人数，背后都是一套关于"如何定义在线"的约定。理解这一点，后面的所有技术选择都会变得顺理成章。

1. 在线人数到底在统计什么：先想清楚口径再动手

动手写代码之前，最该花时间的是把统计口径定下来。我见过太多项目，功能上线了，运营问"这个数字准不准"，开发自己也说不清楚。在线人数的口径差异，直接决定了技术方案的选择和最终数字的含义。

1.1 三种常见口径的差异与适用场景

最粗糙的一种叫"活跃会话数"，指的是最近一段时间内有过请求的独立会话数量。比如设定5分钟窗口，只要某个会话在5分钟内发过请求就算在线。这种口径实现最简单，服务端只需要记录每个会话的最后活跃时间，查询时过滤一下时间窗口就行。缺点是数字偏大，因为用户关了页面之后，这个会话还会在窗口期内继续被算作在线，直到超时。

第二种叫"实时连接数"，指的是当前时刻真正保持着连接的数量。这种口径最接近普通人对"在线"的直觉理解，用户打开页面建立连接就算在线，关闭页面连接断开就不算。实现上依赖长连接技术，比如WebSocket或者SSE。数字相对准确，但会受网络抖动影响，短暂断线重连可能导致数字小幅波动。

第三种叫"去重访客数"，指的是当前在线的独立用户数量，同一个人的多个标签页、多台设备只算一个。这种口径对业务分析最有价值，但实现复杂度最高，需要一套稳定的用户标识体系，还要处理同一用户多连接的管理问题。

我的建议是，如果只是想在页面上挂一个"当前XX人在线"的展示，第二种口径足够用，实现成本也可控。如果要做运营决策，那必须上第三种，否则数字会虚高得离谱。

1.2 为什么"在线"必须靠约定来定义

这里有个容易被忽略的本质问题：服务端永远无法确切知道客户端什么时候关闭了页面。TCP连接理论上在四次挥手时会通知对端，但现实中用户可能直接断网、强制关闭浏览器、笔记本合盖休眠，这些情况下连接可能不会正常关闭，服务端只能靠心跳超时来判定。

所以任何在线人数系统，本质上都是在维护一个"疑似在线集合"，通过心跳机制不断刷新成员的存活状态，超时未刷新的成员被剔除。这个机制决定了你的数字永远存在一个滞后窗口，窗口越短数字越灵敏但心跳开销越大，窗口越长数字越稳定但滞后越明显。理解了这个权衡，你就不会纠结"为什么用户明明关了页面数字还没降"这种问题了。

1.3 数字展示背后的心理预期管理

还有个软性的点值得提。在线人数一旦展示给用户看，用户就会对它产生预期。如果数字长时间不动，用户会觉得是假的；如果数字剧烈跳动，用户会觉得系统不稳定。我一般会在展示层做一点平滑处理，比如数字变化时加个过渡动画，或者对短时间内的波动做聚合，避免个位数频繁跳变。这些细节不影响功能，但很影响观感。

2. 技术路线选型：从轮询到长连接的取舍逻辑

口径定清楚之后，接下来是选技术路线。这块的选项其实不多，但每个选项的适用边界差别很大，选错了后期改造成本很高。我把常见的几条路线按复杂度从低到高捋一遍，重点讲清楚每条路线在什么情况下该用、什么情况下不该用。

2.1 定时轮询方案：简单但有代价

最直观的做法是前端每隔几秒发一个请求，服务端收到请求就更新该会话的活跃时间，同时返回当前在线人数。这个方案的好处是几乎零门槛，任何后端框架都能实现，不需要额外的中间件。

但代价也很明显。假设你的站点有1000个同时在线用户，轮询间隔5秒，那就是每秒200个请求，这些请求全部是无效负载，不产生任何业务价值，纯粹为了维持在线状态。用户量再大一点，这部分开销会变得非常可观。而且轮询的实时性受间隔限制，间隔越短越实时但开销越大，间隔越长越省资源但数字越滞后。

我早期在一个小站点上用过轮询，日活几百的时候完全没问题，后来流量涨上来，光是轮询请求就把带宽吃掉了不少。所以我的经验是：轮询只适合低并发、对实时性要求不高的场景，比如内部工具、小型展示页。一旦并发上到几千，就该考虑换方案了。

2.2 长连接方案：实时性的正解

长连接方案的核心是客户端与服务端保持一条持久连接，连接建立时登记在线，连接断开时注销在线。主流的技术选择是WebSocket，它支持双向通信，服务端可以主动推送人数变化，客户端不需要反复请求。

WebSocket方案的关键优势在于，连接本身就是一个天然的在线信号。连接在，人在；连接断，人走。服务端只需要维护一个连接集合，集合的大小就是在线人数。这个模型非常干净，没有轮询那种"为了维持状态而制造请求"的浪费。

不过WebSocket也不是没有代价。它需要服务端支持连接升级，对负载均衡、反向代理的配置有额外要求，而且连接是有状态的，水平扩展时需要处理连接粘性问题。如果你的服务端是无状态设计，引入WebSocket会带来架构上的调整。

2.3 SSE方案：被低估的轻量选择

如果只需要服务端向客户端单向推送人数，其实SSE（Server-Sent Events）是更轻量的选择。它基于普通HTTP，客户端用EventSource接收服务端推送，服务端保持连接打开即可。相比WebSocket，SSE的配置更简单，对代理和负载均衡更友好，浏览器兼容性也不错。

SSE的局限在于单向通信，客户端不能通过这条连接发消息给服务端。但对于在线人数这个场景，客户端其实不需要发消息，只需要接收人数更新。连接建立和断开本身就完成了在线状态的登记和注销，完全够用。我在一个中等规模的站点上用SSE做过在线人数，实测下来资源占用比WebSocket低不少，配置也省心。

2.4 方案对比与选型建议

选型的判断逻辑我总结成一句话：先看实时性要求，再看是否需要双向通信，最后看团队对长连接的运维熟悉程度。如果只是展示人数，SSE基本是最优解；如果后续还要做聊天、协同编辑这类双向功能，那直接上WebSocket一步到位，避免二次改造。

3. 核心实现拆解：连接登记、心跳与超时剔除

选定方案之后，真正的难点在于把"在线状态"维护得足够稳。这部分我按连接的生命周期拆成几个关键环节来讲，每个环节都有容易出问题的地方。

3.1 连接建立时的登记逻辑

连接建立的那一刻，服务端需要做几件事：生成或读取用户标识、把连接加入在线集合、记录连接建立时间。这里第一个坑就是用户标识的生成。如果直接用连接ID作为标识，那同一个用户开两个标签页就会被算成两个人，数字虚高。

我的做法是前端在本地存储里维护一个稳定的访客标识，首次访问时生成一个随机ID存下来，后续所有连接都带上这个标识。服务端以这个标识为键维护在线集合，同一个标识的多个连接合并成一个在线用户。这样多标签页、刷新页面都不会导致数字翻倍。

不过这里有个细节要注意：刷新页面时旧连接会断开、新连接会建立，如果处理不当，中间会有一个瞬间该用户既不在线又在线，导致数字短暂抖动。解决办法是在注销逻辑里加一个短延迟，比如连接断开后等两三秒再真正剔除，如果这段时间内同一标识重新连上，就取消剔除。这个技巧能显著减少刷新导致的数字跳动。

3.2 心跳机制的设计要点

长连接虽然理论上能感知断开，但现实中网络中间设备（比如某些代理、防火墙）会悄悄掐断空闲连接而不通知两端，导致服务端以为连接还在，实际早已失效。所以必须有应用层心跳来主动探测连接存活。

心跳的设计有几个参数要定：心跳间隔、超时阈值、重试策略。心跳间隔太短会增加无谓流量，太长则故障发现慢。我一般用30秒间隔、90秒超时，也就是连续三次心跳没响应才判定离线。这个组合在大多数网络环境下比较稳，既不会太频繁，也能在合理时间内发现断线。

前端实现上，可以用定时器定期发送心跳消息，服务端收到后更新该连接的活跃时间。服务端再起一个定时任务，定期扫描在线集合，把活跃时间超过阈值的连接剔除。这个扫描任务的执行频率也要注意，太频繁浪费资源，太稀疏则剔除不及时，一般跟心跳间隔保持同一量级即可。

3.3 超时剔除与优雅降级

超时剔除逻辑看似简单，实际有几个边界情况要处理。第一是服务端重启，所有连接都会断开，重启后在线集合是空的，但客户端可能还在尝试重连。这时候如果客户端重连逻辑写得不好，会出现大量重连风暴。我的做法是客户端重连加随机退避，避免所有客户端在同一时刻集中重连。

第二是服务端多实例部署时的集合同步问题。如果在线集合存在单个实例的内存里，多实例之间数据不互通，每个实例只能看到自己维护的那部分连接，展示的人数就不准。解决办法要么是把在线集合放到共享存储（比如Redis），要么是各实例上报自己的连接数再汇总。前者实时性好但依赖外部存储，后者实现简单但有聚合延迟，按实际需求选。

第三是异常连接的清理。有些连接可能因为客户端崩溃而变成"僵尸连接"，心跳早就停了但连接对象还占着资源。所以除了基于活跃时间的剔除，还要定期检查连接的实际状态，把已经不可写的连接主动关闭并清理。

4. 那些上线后才会暴露的坑与应对

功能在本地跑通和在生产环境稳定运行，中间隔着一整个太平洋。在线人数这个功能尤其如此，因为它的行为高度依赖真实的网络环境和用户行为。我把几个印象深刻的坑列出来，都是实际遇到过、且排查起来比较费劲的。

4.1 数字虚高：多标签页与重复连接的陷阱

上线第一天就发现数字比预期高出一大截。排查下来是两个原因叠加：一是前面说的多标签页问题，早期版本用连接ID做标识，开三个标签页就算三个人；二是页面内某些组件重复初始化了连接，导致同一个页面建立了多条连接。

第一个问题的修复前面讲过了，用稳定的访客标识做键。第二个问题更隐蔽，需要在前端连接管理上做单例控制，确保整个页面生命周期内只维护一条连接，组件卸载时不要误关连接，组件重复挂载时也不要重复建连。我后来在连接管理模块里加了一个引用计数，多个组件共用同一条连接，最后一个使用者释放时才真正关闭。

4.2 数字骤降：代理层掐断空闲连接的排查过程

有段时间发现每天固定时段在线人数会突然掉一大截，过一会儿又恢复。一开始怀疑是服务端问题，查了日志发现是大量连接在同一时刻被判定超时。继续追查，发现这些连接的心跳其实一直在发，但服务端没收到。

问题出在中间的代理层。某些代理对空闲连接有超时策略，如果一段时间内没有数据流动就会主动断开。心跳间隔如果大于代理的超时时间，连接就会在心跳发出之前被掐断。解决办法是把心跳间隔调到小于代理超时时间，同时在心跳消息里带一点业务数据，让代理认为连接是活跃的。这个坑很典型，凡是经过多层网络设备的系统都可能遇到，排查时要有意识地去看每一层的超时配置。

4.3 内存缓慢增长：连接对象泄漏的定位方法

服务跑了一周之后内存占用持续上涨，重启就恢复，典型的泄漏特征。用内存快照对比，发现断开的连接对象没有被正确释放，一直挂在某个集合里。

根因是注销逻辑里有个分支没覆盖到：正常关闭的连接会走注销流程，但异常断开的连接（比如客户端直接崩溃）走的是另一条路径，那条路径里漏了从集合中移除对象的操作。修复方式是把清理逻辑统一到一个入口，无论哪种断开方式都经过同一个清理函数。这个教训让我后来养成了一个习惯：凡是涉及资源释放的地方，一定要保证所有路径最终都汇聚到同一个清理点，避免分支遗漏。

4.4 展示层的抖动与平滑处理

技术上数字准了，展示上还有讲究。原始数字每秒都在小幅波动，直接展示出来观感很差。我在展示层做了两层处理：一是对数字做短时间窗口的平滑，比如取最近几秒的中位数；二是变化时加过渡动画，让数字滚动而不是瞬间跳变。另外对于人数较少的站点，可以设置一个展示下限，比如实际只有3个人时展示"5+"，避免暴露真实的小数字带来的冷清感。这些都是产品层面的小技巧，但确实影响用户体验。

5. 从能用到好用：监控、扩展与数据沉淀

功能稳定之后，还有一层价值可以挖掘。在线人数本身是个很有用的运营指标，如果只是展示一下就浪费了。这部分讲讲怎么把这个能力做得更完整。

5.1 给在线人数加上监控告警

在线人数是个很好的健康度指标。正常情况下它应该在一个合理区间内波动，如果突然归零或者暴涨，往往意味着系统出了问题。我把在线人数接入了监控，设置了两条告警规则：一是人数在短时间内骤降到接近零，可能是连接层故障；二是人数异常暴涨，可能是重连风暴或者异常流量。这两条规则帮我提前发现过好几次问题，比等用户反馈快得多。

监控数据的采集也很简单，服务端定期把当前在线数上报到监控系统即可，不需要额外埋点。关键是采集频率要合适，太频繁增加负担，太稀疏则告警不及时，一般一分钟一次足够。

5.2 水平扩展时的连接数汇总

单机扛不住的时候就要考虑多实例。前面提过，多实例下每个实例只能看到自己的连接，需要汇总。我的做法是每个实例定期把自己的连接数写入共享存储的一个带过期时间的键，查询时把所有实例的键值加起来。带过期时间是为了防止某个实例挂掉后它的数字一直残留。

这个方案有个小缺陷：汇总数字有延迟，因为依赖定期上报。如果对实时性要求极高，可以改成实例间直接通信，但复杂度会上升不少。大多数场景下，几秒的延迟完全可以接受，没必要过度设计。

5.3 在线人数数据的长期沉淀

在线人数的历史数据很有分析价值。把每分钟的在线数存下来，可以画出一天的曲线，看出流量高峰时段；存几个月，能看出周规律、季节规律。这些数据对容量规划、活动安排都有参考意义。

存储上不需要用很重的方案，按时序数据存就行，保留粒度可以随时间递减，比如最近一周存分钟级，更早的存小时级，再早的存天级。查询时按需聚合。这套东西搭起来不复杂，但能让在线人数从一个展示数字变成一个真正有用的数据资产。

5.4 一个容易被忽略的细节：时区与统计边界

最后提一个细节。如果站点面向多个时区的用户，在线人数的展示要考虑时区问题。数字本身是全球实时的，不受时区影响，但如果要做"今日峰值"这类统计，就必须明确以哪个时区为边界。我一般统一用服务端的固定时区做统计边界，展示时再按用户本地时区转换，避免统计口径混乱。

另外，在线人数的统计边界还要考虑是否包含爬虫和自动化访问。如果不做过滤，搜索引擎的抓取也会被算作在线，导致数字虚高。简单的做法是在连接建立时检查User-Agent，把明显的爬虫标识排除掉。这个过滤不需要很精确，排除掉主流爬虫就能让数字干净很多。

整套东西做下来，我的体会是：在线人数这个功能，技术难度不在写代码，而在把各种边界情况想周全。口径定义、连接管理、心跳超时、多实例汇总、异常清理，每一个环节都有它的门道。真正稳定的实现，是把这些细节都处理到位之后自然呈现出来的结果，而不是靠某个巧妙的技巧一蹴而就。如果你正准备给自己的站点加这个功能，建议先把第1节的口径和第3节的生命周期管理吃透，剩下的都是在这两个基础上的延伸。