双后端共享数据库：Django与Rails遗留系统的数据同步方案咨询

一、Celery Beat 定时任务方案（你的倾向选择） #

这个方案的核心价值在于完全隔离遗留系统，不会对第三方维护的Rails应用及数据库产生任何侵入性影响，这在遗留系统改造场景中是优先级最高的考量因素，完全具备可行性。

落地优化要点 #

• 跟踪机制：创建一个极简的SyncMarker模型（仅需存储一条记录），记录最后同步的Employee最大自增ID（优先用ID而非时间戳，避免服务器时间不同步导致的漏同步）。
• 同步逻辑：定时任务每次执行时，通过Employee.objects.filter(id__gt=SyncMarker.last_id)拉取新增记录，用bulk_create()批量生成EmployeeDetails，最后更新SyncMarker的last_id。
• 异常防护：给任务添加Celery重试机制，若某次同步失败，下次任务会从上次成功的断点继续；创建EmployeeDetails时用get_or_create()替代create()，避免重复插入。

潜在问题应对 #

• 延迟问题：同步延迟由任务间隔决定，若业务允许5分钟内的延迟，设置5分钟间隔即可；若要求近乎实时，可缩至1分钟甚至30秒——范围查询id__gt不会触发全表扫描，对数据库性能影响极小。
• 数据一致性：若遗留系统存在Employee更新场景（比如修改字段），可扩展任务逻辑，同时检查updated_at字段，同步更新EmployeeDetails关联数据。

二、PostgreSQL Trigger 方案的利弊 #

这个方案能实现实时同步，但缺点远大于优势：

• 侵入风险：需要在第三方维护的数据库上创建触发器，即便不修改表结构，也可能违反第三方的维护协议，后续数据库升级时触发器有被覆盖的风险。
• 维护成本：触发器逻辑需写在数据库层（PL/pgSQL），若直接插入EmployeeDetails，后续Django模型结构变更时需同步修改触发器；若调用Django API，还要处理API调用失败的重试、幂等问题，复杂度陡增。

三、备选方案：Webhook 回调（若可行） #

如果能说服第三方在Rails系统创建Employee后，调用Django提供的Webhook接口，让Django主动生成EmployeeDetails，这是最优解——实时性高且无数据库侵入。但该方案依赖第三方配合修改代码，多数场景下可能无法落地，可作为备选沟通方向。

最终结论 #

优先推进Celery Beat定时任务方案，理由如下：

• 零侵入性，彻底规避影响遗留系统的风险，符合第三方维护场景的核心约束。
• 实现简单，基于Celery和Django ORM即可完成，无需额外的数据库底层技能。
• 可靠性可控，通过断点跟踪、批量操作、重试机制，能保证数据不遗漏、不重复。

若业务对实时性要求极高，可在Django的API接口中加入兜底逻辑：当前端请求某Employee的EmployeeDetails时，若记录不存在则立即创建并返回，让用户无感知延迟。

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