美洽离线缓存支持

美洽的离线缓存支持是指在用户网络中断或应用后台时，本地与服务端协同保存未读消息、会话状态与附件元数据，并在重连后自动同步，保证消息不丢失、顺序一致与可回溯，同时降低实时连接压力并提升用户体验。它还支持多端融合、离线消息聚合、过期策略和加密存储，便于运维监控与故障恢复，可配置以满足不同业务场景需求。更

先把概念讲清楚：什么是“离线缓存支持”

说白了，离线缓存就是把客户和客服之间那条“即时”通道的临时状态留着，不让信息在网络波动时丢掉。对一个智能客服平台来说，离线缓存有两个层面：一是客户端（APP、H5、小程序）本地缓存未读消息和会话上下文；二是服务端为每个会话维护持久化队列和同步接口，保证重连后能够把遗漏的内容补齐。

为什么要有离线缓存？

• 可靠性：网络不稳定时，消息不丢；客户和客服都能看到完整会话记录。
• 用户体验：打开应用马上看到历史对话，不用等实时连接完成。
• 资源优化：减少频繁短连接和重复拉取，降低后端压力。
• 多端一致性：同一账号在手机、PC、客服后台之间状态一致。

美洽离线缓存的常见组成（通用架构视角）

这里我用比较直白的图式描述——别真以为是画图，想象一下流程：

• 客户端本地层：本地存储（IndexedDB / SQLite / Realm / Key-Value），缓存策略（LRU、TTL），附件临时缓存。
• 网络层：消息队列与序列号、ACK 机制、重试策略、消息签名/加密。
• 服务端持久层：会话队列/消息存储（可用分布式DB或消息中间件持久化），变更日志（用于差量同步）。
• 同步接口：基于时间戳或序列号的拉取/推送 API，支持按会话、按用户或按时间范围查询未读消息。

常用名词速览（免得后面读着晕）

• Sequence（序列号）：每条消息的单调递增编号，保证顺序性和去重。
• ACK：客户端接收并回执，服务端据此清理已送达但不再需要重试的数据。
• Delta sync（差量同步）：重连/切换设备后只拉取自上次已知序列号后的新消息。
• TTL / Expiry：缓存生命周期，决定何时丢弃本地或服务端的历史数据。

实战：离线缓存如何在美洽里落地（步骤导向）

下面是一个从客户端到服务端再回到客户端的完整流程，按步骤讲，像教人装台咖啡机那样简单：

1. 客户端：写入本地缓存并标记状态

• 收到推送或通过长连接接收消息时，先写本地数据库，记录 msg_id、seq、timestamp、from、to、content_type、status 等字段。
• 本地显示“未读”或“同步中”状态，避免空白界面。
• 对附件：先缓存元数据（大小、URL、hash），大文件采用分片/断点续传策略。

2. 服务端：持久化并维护队列

• 服务端收到消息后写入持久化存储，生成序列号。持久化可以是关系型、NoSQL 或消息队列+数据库的组合。
• 为每一会话维护“watermark”（已发送到某客户端的最高序列号）以便差量同步。
• 设计可配置的过期策略：例如系统消息保留 30 天，业务单据相关消息长期保留。

3. 重连与差量同步

• 客户端重连时，上报本地已知的最大序列号；服务端返回从该序列号之后的消息清单。
• 若检测到序列号中断或缺失（例如本地缺少中间段），触发完整回溯或请求归档接口。
• 冲突处理——若同一消息在多端被修改（比如客服编辑回复），采用最后写入优先或业务合并策略。

4. 消息确认与清理

• 客户端处理完某条消息后，发送 ACK；服务端据此更新 watermark 并在合适时清理或归档消息。
• 对已确认并过期的本地缓存，客户端可按本地策略自动清理，或为用户提供“清理聊天记录”选项。

实现细节与设计决策（开发者关心的部分）

选择本地存储方案

• Web：优先 IndexedDB（支持大数据量、事务），fallback 到 LocalStorage 只适合非常小的数据。
• Android：SQLite/Room 或 Realm，Room 更方便与 LiveData 联动。
• iOS：CoreData 或 Realm，视项目复杂度和团队偏好而定。

序列号 vs 时间戳

用序列号能保证严格顺序与去重，尤其是跨多端场景更稳妥。时间戳好理解但会遇到时钟偏差问题。建议以序列号为主，时间戳作为辅助索引。

消息去重与幂等

服务端与客户端都要做幂等处理：基于 msg_id+seq 做唯一校验，重复入库要丢弃或合并。对于附件，先验证 hash。

安全性与合规

离线缓存把敏感信息留在设备上，安全必须考虑：

• 加密存储：在客户端对敏感字段做 AES 加密或使用平台提供的加密存储（Android Keystore、iOS Keychain）。
• 传输加密：所有同步接口必须使用 TLS，并校验证书/域名。
• 访问控制：服务端检查会话权属，避免越权拉取历史消息。
• 隐私与合规：对聊天记录保留期、数据脱敏、审计日志按法规要求配置。

运维指标与监控建议

线上要能看见离线缓存带来的效果与异常：

• 消息同步延迟（从消息发送到客户端实际同步的时间分布）
• 重连后差量大小分布（平均每次需同步多少条消息）
• ACK 丢失率与重试次数
• 本地缓存占用（按设备型号/客户端版本）
• 错误率监控（序列号不连续、解密失败、附件丢失）

常见问题与排查思路

• 问题：用户反馈重连后缺少消息。
  排查：检查客户端上报的最大序列号、服务端水位线、是否存在归档系统或分区延迟。
• 问题：消息重复展示。
  排查：确认客户端去重逻辑、msg_id 是否全局唯一，以及 ACK 是否丢失导致重发。
• 问题：附件无法下载或校验失败。
  排查：检查临时 URL 过期策略、分片索引和文件 hash。

示例：缓存字段设计（供参考）

最佳实践与配置建议（结合业务场景）

• 电商场景：对订单相关消息延长保留期，优先保证售后与退款相关对话完整。
• 金融场景：开启强加密、缩短本地缓存可见期，增加审计与告警。
• 高并发客服中心：采用分片队列与水平扩展的同步服务，控制单次差量同步大小，避免一次性回溯压力过大。

与推送/通知的协同

离线缓存并不是替代推送，而是补充。推送用于唤醒与提醒，离线缓存负责消息完整性：

• 收到推送后客户端能立刻从本地缓存取出最后几条对话用于通知展示。
• 若推送失败（APNS/FCM），客户端重连后仍能通过差量同步补齐。

测试策略（别只在开发机上测）

• 离线/弱网测试：模拟丢包、低带宽、长时断连，检验重连策略与缓存一致性。
• 多端切换：模拟同账户在多端同时在线并发消息，观察序列号与冲突解决。
• 压力测试：批量回溯大体量消息，确认服务端回溯吞吐与延迟。

最后一点实践经验（像在白板上画的思路）

实现一个靠谱的离线缓存不是一次性工程，而是逐步打磨的过程：先把最关键的“消息不丢”和“顺序对齐”做好，接着再优化附件策略、清理策略和加密措施。上线后密切观察 ACK 丢失、差量同步大小和重连延迟这些指标，逐步调整 watermark 策略与本地持久化策略。嗯，写到这儿想到以前遇到的一个坑：团队把本地缓存清理得太积极，结果用户翻旧讯息就空白了——所以策略要可配置，给产品和运维留调整空间。

如果你正打算在美洽平台或类似系统上落地离线缓存，优先明确业务边界（消息保留期、敏感信息策略）、选好本地存储方案、实现序列化与幂等机制，然后做充分的线上观测与回滚手段。说得有点罗嗦，但比起临时把数据丢掉，这些小心思省事多了。