17370845950

本文介绍如何在 web 应用中高效实现服务端缓存变更到客户端的实时同步，避免全量重拉、减少带宽消耗与渲染压力，核心是结合客户端过滤规则做精准增量推送（新增/更新/删除）。

在典型的前后端分离架构中，当后端使用 EHCache 等本地缓存存储数十万级数据，并通过 WebSocket 向多个 Web 客户端广播变更时，若每次变更都触发客户端按原始过滤条件重新拉取全量匹配结果（如 5000 行），将导致严重性能瓶颈——尤其当高频小规模更新（每 1–5 秒 5–10 行）与低相关性（多数更新不满足客户端 filter）并存时。

根本问题在于：“通知即重载”模型缺乏语义感知能力。客户端无需知道“所有变更”，只需知道“与我当前视图相关的变更”。

✅ 推荐方案：服务端维护客户端过滤上下文 + 增量事件分发

最高效且工程可行的解法，是在服务端轻量级缓存每个活跃 WebSocket 连接的最新请求过滤器（Filter Context），并在缓存更新事件发生时，仅向匹配该 filter 的客户端推送对应增量数据。

1. 服务端需维护的元数据（极简状态）

// 示例：内存中 Map
public record ClientFilterContext(
    String sessionId,
    Filter contentFilter,
    LocalDate startDateFilter,
    LocalDate endDateFilter,
    // 可选：记录上次同步时间戳，用于幂等/断线续传
    Instant lastSyncAt
) {}

• 每次客户端发起 /api/data?filter=... 请求时，服务端解析参数并更新对应连接的 ClientFilterContext；
• WebSocket 连接关闭时清理该条目（可配合 Spring Session 或手动管理）。

2. 更新事件处理逻辑（伪代码）

// 当 EHCache 触发 onUpdate(event: CacheEvent)
List relevantDeltas = new ArrayList<>();

for (ClientFilterContext ctx : activeClients.values()) {
    // 对本次变更的每一行数据（event.getUpdatedItem()）做快速 filter 匹配
    if (matchesFilter(event.getItem(), ctx)) {
        DeltaUpdate delta = buildDelta(event.getType(), event.getItem());
        relevantDeltas.add(delta);
    }
}
// 仅向 ctx 对应的 WebSocket 会话推送 relevantDeltas
websocketTemplate.convertAndSendToUser(ctx.sessionId, "/queue/updates", relevantDeltas);

3. 客户端增量应用（前端示例）

// 收到 { newItems: [...], updatedItems: [...], deletedIds: [...] }
function applyDelta(delta: DeltaUpdate) {
  // 1. 删除：根据 ID 从本地列表移除
  state.items = state.items.filter(item => !delta.deletedIds.includes(item.id));

  // 2. 新增/更新：按 ID 合并（或使用 Map 提升性能）
  delta.newItems.forEach(item => upsertItem(item));
  delta.updatedItems.forEach(item => upsertItem(item));
}

function upsertItem(item: DataItem) {
  const idx = state.items.findIndex(i => i.id === item.id);
  if (idx >= 0) state.items[idx] = item;
  else state.items.push(item);
}

⚙️ 进阶优化选项（按需启用）

⚠️ 注意事项与权衡

• 状态合理性：虽引入轻量连接上下文，但 WebSocket 本身已是状态化协议，此举并未破坏架构本质，反而提升可观测性与可控性；
• Filter 匹配性能：对 10 万行缓存，每次变更仅需检查 N 个客户端 × 1–10 行更新（非全量扫描），复杂度远低于反复执行 cache.values().stream().filter(...)；
• 一致性边界：该方案不保证强一致性（如客户端 filter 变更与服务端更新并发时），但可通过「先更新 filter 上下文，再响应数据请求」的顺序保障最终一致；
• 兜底机制：仍保留全量拉取接口（如 /api/data?forceRefresh=true），用于调试、强制同步或 filter 初始化。

✅ 总结

抛弃“推通知 → 客户端全量重拉”的反模式，转向“服务端理解客户端意图 → 精准推送增量”的正向设计，是解决高频率、低相关性实时更新问题的关键。它不仅显著降低带宽与服务端 CPU 压力，也使前端渲染更轻量、用户体验更流畅。实施成本低、扩展性强，是现代实时数据同步的推荐实践。