本文介绍如何在 spring boot + websocket 架构中，避免客户端频繁全量拉取数据，转而实现按用户过滤条件精准推送新增、更新、删除的增量变更，显著降低带宽消耗与服务压力。
在构建支持实时数据同步的 Web 应用时，一个常见却易被低估的性能瓶颈是：服务端盲目广播所有变更，客户端无差别重载全量结果集。如题所述，当缓存中每秒发生 5–10 行变更，而某客户端因日期/文本过滤仅关注 50 行数据时，仍被迫每秒请求并解析 5000 行——这不仅浪费网络带宽，更增加前端渲染负担与后端计算开销。
✅ 核心策略：服务端维护“客户端过滤上下文”，实现智能增量分发
最高效且工程可行的解法，正是回答中强调的 Option 1：服务端主动缓存并索引各客户端的当前过滤条件。这不是“有状态”的反模式，而是对 WebSocket 连接天然状态的合理利用（WebSocket 本身即要求连接保活与会话管理）。
实现步骤概览：
-
记录客户端过滤器：当客户端首次发起 /api/data?filter=... 请求时，服务端将其 Filter 对象（含 contentFilter, startDateFilter, endDateFilter 等）与 WebSocket Session ID 绑定，存入轻量级内存缓存（如 ConcurrentHashMap
，Key 为 session ID）。 - 监听缓存变更事件：EHCache 更新时触发事件（如 CacheEventListener），获取变更的实体 ID 或完整对象（推荐 ID + 变更类型，减少序列化开销）。
- 按需匹配与推送：对每个变更项（id, type=ADDED/UPDATED/DELETED），遍历所有活跃客户端的过滤器，调用服务端过滤逻辑（复用原有 filterDataFromCache() 的判定逻辑）判断该变更是否落入其视图范围。若命中，则通过对应 WebSocket Session 推送结构化增量消息。
示例：增量推送消息格式（JSON）
{
"timestamp": 1717023456789,
"changes": {
"newItems": [
{ "id": "abc123", "startDate": "2024-05-01", "username": "alice", "group": "admin" }
],
"updatedItems": [
{ "id": "def456", "endDate": "2024-12-31", "username": "bob" }
],
"deletedIds": ["xyz789"]
}
}✅ 优势：客户端仅接收与其当前视图相关的变更，无需二次过滤；服务端避免重复执行全量数据扫描，仅对少量变更项做轻量判定。
⚙️ 进阶优化：时间戳驱动 + 批量聚合（应对高吞吐场景）
若业务允许毫秒级延迟（如监控看板可接受 1–3 秒延迟），可叠加 Option 2：变更事件缓冲与定时聚合：
- 后端不逐条推送，而是将 2 秒窗口内的变更暂存至队列（如 ConcurrentLinkedQueue）；
- 定时任务（@Scheduled(fixedDelay = 2000)）触发批量处理：合并同一 ID 的多次更新为最终状态，再按客户端过滤器分发；
- 客户端收到 { "type": "BATCH_UPDATE", "batchId": "20240530_001" } 后，可选择静默更新或触发局部刷新。
此方式进一步降低 WebSocket 频次，尤其适合突发性高频写入场景。
⚠️ 注意事项与边界处理
- 过滤器更新同步：客户端修改筛选条件（如拖动日期滑块）时，必须显式调用 POST /api/filters 更新服务端缓存，避免推送错漏。建议在前端封装 setFilters() 方法，自动完成本地状态更新 + 服务端同步。
- 初始加载一致性：首次加载仍需全量请求（GET /api/data），但响应中应包含 lastSyncTime（毫秒时间戳）。后续增量推送均基于此时间点，确保状态连续。
- 内存安全：为防内存泄漏，需为 ClientFilter 缓存设置 TTL（如 30 分钟无心跳则自动清理），并监听 @OnClose 事件及时移除失效 Session。
- 极端场景兜底：若客户端长时间离线或推送失败，可设计 SYNC 指令——客户端主动发送 {"type":"SYNC","lastKnownVersion":123}，服务端返回自该版本后的全部变更快照。
✅ 总结
抛弃“全量轮询”或“无差别广播”的粗放模式，转向 服务端感知客户端意图、按需分发增量变更，是实时数据架构成熟的关键标志。它不依赖复杂中间件（如 Kafka + Flink），仅需合理利用现有 WebSocket 状态与缓存能力，即可实现数量级的性能提升。真正的“无状态”，不是拒绝一切上下文，而是让状态服务于精准、高效与可控——而这，正是专业实时系统的设计哲学。
