WebSocket 不能直接监控 Redis 分布式锁状态，因其仅是通信管道，不感知 Redis 数据变化；需结合 Redis Pub/Sub 发布锁事件，后端订阅后推送至前端，并聚合高频事件、校验字段、推送全量快照以确保实时准确。
为什么不能直接用 WebSocket 监控 Redis 分布式锁状态
WebSocket 本身不存储状态，它只是个双向通信管道。你看到的“锁被谁持有”“当前等待队列长度”这些信息，必须来自外部数据源（比如 Redis 的 GET、LLEN 或自定义的监控 key），再由后端主动推送给前端。常见错误是试图让 WebSocket 服务自己“发现”锁状态变化——它不会自动感知 Redis 中 lock:order_123 的值变了，除非你显式轮询或监听 Pub/Sub。
用 Redis Pub/Sub + WebSocket 实现实时锁状态推送
核心思路：把锁的生命周期事件（加锁、续期、释放、争抢失败）通过 PUBLISH 发到 Redis 频道，后端 WebSocket 服务订阅该频道，收到消息后广播给所有已连接的监控页面。
- 加锁成功时，执行：
PUBLISH lock:status "{"event":"acquired","resource":"order_123","holder":"svc-a-01","ts":1716476583}" - 释放锁时，发布：
PUBLISH lock:status "{"event":"released","resource":"order_123"}" - 后端需用
redis.PubSub().subscribe("lock:status")（Python）或client.subscribe("lock:status")（Node.js）持续监听 - 前端 WebSocket 连接建立后，服务端立即推送一次全量快照（如当前所有活跃锁列表），再推送增量事件
避免监控页面显示“假死”或延迟的关键点
锁状态变化极快，但人眼只关心“谁在抢”“卡在哪了”。如果每毫秒都推一条消息，前端会卡顿且无意义。必须做服务端聚合：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 对同一资源的连续争抢事件，在 500ms 窗口内合并为一条：
{"event":"contending","resource":"order_123","count":7,"last_ts":1716476584} - 使用 Redis 的
EXPIRE给每个锁监控 key 设置 TTL（比如 30 秒），防止历史脏数据堆积 - 不要依赖客户端时间戳；所有
ts字段必须由服务端生成，避免多节点时钟漂移导致排序错乱 - 若用 Spring Boot + WebSocket，别把
@MessageMapping当作监控入口——它走的是 HTTP 握手后的消息通道，不适合承载高频率系统事件；应另起一个@EventListener监听 Redis 消息，再调用SimpMessagingTemplate.convertAndSend()
前端如何安全渲染锁争抢链路
直接把原始 JSON 渲染成表格容易出错。真实场景中，你要区分三类状态并用不同视觉样式：
-
"acquired"→ 显示绿色高亮 + 持有者 ID + 倒计时（根据 Redis key 的 TTL 动态计算剩余时间） -
"contending"→ 显示黄色脉冲动画 + 等待数量 + “最近一次尝试时间”（不是服务器时间，而是事件里带的last_ts） -
"failed"→ 显示红色闪烁 + 失败原因字段（如"reason":"timeout"或"reason":"wrong_token"） - 务必校验每条消息的
resource字段是否符合预期正则（如^order_[0-9]{6,}$），防止恶意消息注入 HTML 标签
最易被忽略的是：监控页面打开时，可能错过中间若干次状态变更。必须让后端在连接建立后，立刻查一次 Redis 所有匹配 lock:*:holder 的 key，并构造完整快照推送，否则你看到的永远是“断层画面”。
