实时统计在线用户并发数的关键是还原用户真实交互时间粒度与状态，而非简单计数日志条目；需识别用户身份、打毫秒级时间戳、定义有效交互（如POST/PUT请求、WebSocket消息等），通过滑动1秒窗口去重聚合user_id，并区分连接态与请求态并发，辅以多源指标交叉校验。
实时统计在线用户的并发数，关键不是“数日志条目”，而是从日志中还原用户行为的真实时间粒度和交互状态。日志本身是离散事件记录，直接按行计数会严重高估或低估——比如一个用户刷10次页面只产生10条日志，但实际并发请求可能集中在几秒内；反之，一个长会话可能几十分钟只产生1条心跳日志，却持续占用连接资源。
核心逻辑：并发 ≠ 在线，而是在某一毫秒级时间窗口内，真实向服务端发起有效请求的用户数
所以日志分析做实时并发统计，必须完成三件事：识别用户身份、打上精确时间戳、定义“有效交互”边界。
用日志还原用户活跃窗口
不是每条日志都算“并发触发点”。要筛选出能代表用户正在与服务器交互的日志，例如：
- HTTP 访问日志中 status=200 且 method=POST/PUT/DELETE 的请求（含表单提交、数据修改）
- WebSocket 连接日志中的
onopen和带 payload 的message事件 - API 日志中标记为
action=submit、action=upload、action=pay等业务动作字段 - 排除静态资源（
.js,.css,.png）、健康检查（/health,/ping）、GET 列表页等低负载请求
对每条有效日志提取：
-
user_id或session_id（优先用登录态标识， fallback 用 device_id + ip 组合去重） -
timestamp（务必统一到毫秒级，校准 NTP 时间，避免日志采集延迟导致时间漂移） -
request_duration（可选，用于判断是否仍在处理中）
滑动时间窗口聚合（推荐 1 秒粒度）
并发是瞬时值，不能靠“每分钟汇总后取最大值”这种粗粒度方式——它会漏掉尖峰。正确做法是：
- 构建一个滑动窗口（如 1 秒），滚动计算该窗口内去重后的 user_id 数量
- 使用流式引擎（Flink / Spark Streaming / Kafka Streams）或内存数据库（Redis TimeSeries / TimescaleDB）实现
- 示例逻辑（伪代码）：
for each log in stream: if log is valid interaction: ts = floor(log.timestamp / 1000) * 1000 // 对齐到秒级起点 add user_id to set at key "concurrent:ts:{ts}" expire key after 2s （防延迟日志堆积） then: get cardinality of "concurrent:ts:{now-1000}" → 当前并发数
区分“连接态并发”和“请求态并发”
很多系统混淆了这两个概念：
-
连接态并发：如 WebSocket 长连、HTTP/2 多路复用连接数，反映的是资源占用，适合用 Netty 或 Nginx
$connections_active指标监控 - 请求态并发：单位时间内真正发往业务逻辑层的请求数，才是压测和容量规划关心的“并发用户数”
日志分析更适合估算后者。若日志里有 upstream_response_time 或 backend_time 字段，还可进一步过滤出“正在执行中”的请求（比如 backend_time > 500ms 且未返回），这类请求更接近真实并发压力源。
补充建议：别只依赖日志
纯日志方案有天然缺陷——延迟高、丢失风险、解析开销大。生产环境建议组合使用：
- 日志作为兜底和审计依据（用于回溯、归因）
- 应用层埋点上报（如 Spring Boot Actuator
/actuator/metrics/http.server.requests+ Micrometer） - 中间件指标（Nginx stub_status、Tomcat activeThreads、Redis connected_clients）
- 前端心跳上报（适用于 Web 应用，每30秒发一次轻量 ping，服务端维护 session TTL）
三者交叉校验，才能得到稳定可信的实时并发值。
