移动端实时协作与离线同步：本地数据库作为SSOT的方案可行性探讨

一、该方案的可扩展性与可维护性 #

可扩展性 #

• 后端职责聚焦：仅负责数据同步、冲突解决和WebSocket推送，无需适配UI层状态，便于横向扩展同步服务和WebSocket节点，应对大规模用户并发场景
• 批量同步降负载：离线待操作批量提交，相比在线实时单条请求，能有效减少API调用量，后端压力可控，高并发下更稳定
• 幂等性易落地：给Sync表的每个待处理操作分配唯一标识，即使重复同步也不会产生脏数据，支持大规模用户离线恢复后的批量同步需求

可维护性 #

• UI逻辑统一：所有数据读取都走本地DB，无需在代码中分支处理在线/离线场景，减少冗余代码，排查问题时无需切换上下文
• 冲突逻辑集中：冲突解决完全由后端处理，移动端无需编写复杂的冲突合并代码，降低移动端维护成本
• 依赖成熟组件：Room、WorkManager都是Android生态的成熟工具，社区文档和解决方案丰富，踩坑成本低

二、与在线直接交互的混合方案相比的劣势 #

• 实时延迟更高：服务器的实时变更通过WebSocket推送后，需要先写入本地DB才能更新UI，相比直接用服务器返回数据更新UI，多了一层本地存储操作，对延迟敏感的场景（如实时协作白板、高频聊天）体验会受影响
• 本地存储压力：作为SSOT需要在本地存储全量（或核心）业务数据，当数据量较大时，会占用更多设备存储，还需额外设计数据清理、增量同步策略，而混合方案在线时可按需拉取数据，无需本地存全量
• 同步逻辑复杂度提升：需要维护Sync表跟踪操作类型、顺序、幂等标识，还要处理同步失败重试、部分成功回滚等场景，这部分逻辑比在线直接调用API更复杂，容易引入bug
• 一致性风险增加：如果本地DB写入成功但服务器更新失败，或WebSocket推送的变更在本地写入失败，会出现本地与服务器数据不一致的情况，需要额外的校验、兜底修复机制，而混合方案在线时直接依赖服务器，一致性保障更直接

内容的提问来源于stack exchange，提问作者Android Developer