1. 跨模块数据同步的挑战与目标
多模块架构下的 Room 数据库同步，核心矛盾源于 数据所有权分散 与 一致性边界模糊。不同模块各自维护 Room 实例，却需要共享或部分共享同一份业务数据。本章从数据一致性、同步粒度、同步策略三个维度拆解挑战，并定义可交付的目标文档。
1.1 多模块数据一致性问题
当模块 A、B、C 各自持有 Room 数据库副本时，数据同步面临三种典型不一致场景：
- 写后读不一致：模块 A 写入 user 表，模块 B 立即读取仍为旧数据（因本地缓存未触发跨模块通知）。
- 更新丢失：模块 A 和模块 C 同时对同一用户信息的 email 字段做本地修改，互相覆盖。
- 级联失败：模块 B 删除订单时需同步更新模块 A 中的库存表，若同步链路中断则数据孤岛。
关键洞察：真正的问题不是数据库技术本身，而是跨模块事务边界无法跨越 Room 实例。每个模块的 Room 数据库是独立的事务上下文，无法保证全局 ACID。
1.2 同步粒度决策
跨模块同步并非必须复制整张表。决策树基于数据变更频率、字段耦合度、消费者数量将粒度分为三级：
| 粒度级别 | 适用场景 | 典型风险 |
|---|---|---|
| 表级同步 | 低频低并发配置表（如 app_config） | 网络带宽浪费；触发全表替换导致短暂断流 |
| 行级同步 | 用户详情、订单主记录等核心实体 | 行冲突需版本号 / 时间戳裁决 |
| 字段级同步 | 高竞争字段（如 email、库存数量） | 监听逻辑复杂；需字段级脏标记 |
选型权衡：字段级同步看似最精准，但引入的监听代码量和字段映射维护成本通常超过收获。实践中多采用“行级 + 白名单字段”模式，即整行推送但消费者只取用白名单字段，避免数据膨胀。
1.3 交付物：同步挑战矩阵与目标定义文档
本章验收标准是产出正式文档，包含以下两部分：
同步挑战矩阵
按模块对列出数据一致性威胁、同步粒度、信任链路断裂点：
| 模块对 | 共享数据 | 一致性威胁 | 推荐粒度 | 信任链路要求 |
|---|---|---|---|---|
| A ↔ B | order 行 | 级联失败（减库存） | 行级 | 强顺序写入 + 重试至少一次 |
| A ↔ C | user.email | 写后读不一致 | 字段级 | 双写确认 + 缓存失效 |
| B ↔ C | order_stat 聚合 | 更新丢失 | 表级（批处理） | 本地日志 + 定时合并 |
目标定义文档（摘要）
- 强同步：任何跨模块写入，在本地提交后 500ms 内到达目标模块 Room 实例。
- 字段级一致性：同一字段在两个模块间不允许出现静默覆盖，必须携带版本号或时间戳。
- 可恢复链路：网络或进程中断后，同步队列必须支持持久化重放，不丢失变更。
- 无侵入集成：模块只需声明共享数据范围和字段白名单，不修改原有 DAO。
落地检查点：在架构评审时使用该矩阵逐行审查模块间依赖，可提前暴露 80% 的数据同步隐患。矩阵应随着业务迭代持续更新，而非一次完成。
1.4 风险点与初步应对
- 死锁风险：两个模块同时对同一行做更新 → 引入全局锁序列或版本号 + 乐观锁。
- 级联风暴：一条订单变更引发 N 个模块连锁同步 → 设置单次同步最大链路深度（推荐 3 层）并降级为 TTL 缓存。
- Room 版本不兼容：各模块 Room 版本若不一致可能导致 schema 差异 → 强制对齐
Room.databaseBuilder的版本号，并在 CI 中校验。
1.5 落地步骤（本章范围）
- 盘点模块共享数据资产：输出各模块 Room 实体映射表，标记跨模块引用的表名与字段。
- 构建同步挑战矩阵：按本章模板完成初版，评审确认三大一致性威胁场景。
- 选定同步粒度：在矩阵中为每对模块关系标注推荐粒度（表/行/字段）。
- 定义验收断言：明确“写后读一致”的度量方法（例如模块 B 在模块 A 写入后 10 次连续读取均为最新值）。
- 冻结目标文档：包含同步粒度表、一致性 SLA、信任链路契约供后续章节设计。
本章不涉及具体实现代码，但为后续的数据同步管道、消息契约、冲突解决策略提供了决策基线。下一阶段将基于此目标文档设计 跨模块数据同步管道。