日期：2026-07-11
标签：#面试 #八股 #后端 #同步 #线程问题排查 #场景题
一句话答案
页面查询不应耦合全量同步，应将同步改为事件驱动加增量补偿，页面只读取本地可查询模型，必要时触发异步刷新。
面试口语版
每次进页面全量同步会造成重复 I/O、线程堆积、上游压力和长尾延迟。我会先拆开“同步”和“查询”：订单变更通过 MQ/Webhook 增量更新本地库，定时任务按游标或更新时间补偿漏事件，并周期性对账。页面直接分页查询本地数据，展示最后同步时间；如果用户要求刷新，只提交带幂等键的异步增量任务，并用 SingleFlight 或分布式任务锁合并同一用户的重复刷新。
关键细节
- 增量游标应单调且可恢复，仅依赖时间戳要处理同毫秒与迟到更新。
- MQ 消费和数据库更新必须幂等。
- 全量同步保留为低频校准手段，按租户分片、限速执行。
- 线程池有界并按租户隔离，避免一个大客户占满全部同步线程。
面试官追问
- 增量事件丢失怎么办？
- 用户连续点击刷新如何合并任务？
- 如何保证页面读到一致数据？
面试官追问参考答案
1. 增量事件丢失怎么办？
生产端用 Outbox/事务消息可靠发布，消费端幂等；同时按更新时间或业务序号定时拉取增量，并通过日终全量对账发现缺口。实时链路负责新鲜度，补偿链路负责最终正确。
2. 用户连续点击刷新如何合并任务？
以用户或租户为 Key 维护进行中任务，使用 SET NX/任务表唯一约束让同一时刻只有一个刷新任务，其他请求返回同一 taskId。任务结束后短时间缓存结果，避免立即重复触发。
3. 如何保证页面读到一致数据？
先定义是一致到哪个时间点。页面读取本地快照并返回同步水位；写后立即读可通过主库、版本等待或查询源系统补偿，普通列表接受秒级最终一致，并明确刷新状态。
学习清单
- 能设计实时增量、定时补偿和全量对账三层同步。
- 理解任务合并与租户隔离。
维护与整理 · Yihui在 GitHub 上编辑