Django竞态条件疑问：开启ATOMIC_REQUESTS仍无法获取新创建记录

这是个典型的跨事务可见性与时序问题，虽然你开启了ATOMIC_REQUESTS=True保证单个请求内的操作原子性，但它管不到独立运行的cron进程事务——我们来一步步拆解可能的原因和对应的解决办法：

1. 最可能的元凶：主从复制延迟（如果用了读写分离） #

如果你的生产环境用了PostgreSQL主从复制，而且cron进程连接的是从库做查询，那这个问题几乎可以肯定是复制延迟导致的：

• 主库上的请求事务提交后，主库到从库的数据同步需要极短的时间（比如0.1秒左右）
• cron进程刚好卡在同步完成Job记录但还没同步JobFile记录的窗口执行查询：先查到了已同步的Job，却没查到还在路上的JobFile
• 等你稍后手动查数据库时，从库已经完成所有同步，所以能看到完整的记录

解决办法： #

• 如果cron的查询需要强一致性，直接让它连接主库执行（注意监控主库负载，避免查询影响业务）
• 放弃固定时间的cron任务，改用消息队列（比如Celery）触发检查：在主事务提交后，主动发送消息通知检查进程，这样能保证数据完全落地后再执行查询
• 临时方案可以在cron查询前加个短暂延迟（比如0.5秒），但这个方法不稳定，不推荐长期用

2. PostgreSQL事务隔离级别的细节坑 #

PostgreSQL默认用的是**读已提交（Read Committed）**隔离级别，在这个级别下：

• 每个查询语句都会看到当前已经提交的所有数据
• 但你遇到的“看到Job却看不到JobFile”的情况，理论上不可能发生在同一事务提交的场景下——除非你的代码里有手动提前提交事务的逻辑：
  • 比如视图里用了@transaction.non_atomic_requests装饰器，绕过了全局的ATOMIC_REQUESTS
  • 或者在job.save()之后手动调用了transaction.commit()，然后才创建JobFile，把两个操作拆成了两个独立事务
  • 还有一种可能是Job模型的save()方法被重写，或者有post_save信号触发了异步操作，导致Job的记录被提前提交

排查与修复： #

• 检查视图代码，确保没有手动控制事务的逻辑（比如transaction.atomic()块、commit()/rollback()调用）
• 检查Job模型的自定义方法和信号，确认没有提前提交事务的操作

3. 时区或时间戳的边界问题 #

如果你的timestamp字段是自动生成的（比如auto_now_add=True），要检查时区和时间计算的一致性：

• 确保Django的TIME_ZONE设置和cron进程的系统时区完全一致，避免时间戳的偏移
• cron任务里的my_timestamp计算是否刚好卡在Job创建的时间边界上？比如cron刚好查询到了timestamp刚生成的Job，但此时主事务还没提交JobFile

解决办法： #

• 统一所有服务的时区设置，比如都用UTC或者当地时区
• 在cron的过滤条件里给时间戳加个小范围的偏移，比如用timestamp__range=(my_timestamp - timedelta(seconds=1), my_timestamp + timedelta(seconds=1))，避免刚好卡在边界上的情况

4. 调试验证建议 #

• 在cron代码里加详细日志：记录每个查询的时间点、查询到的Job ID列表、JobFile的查询结果，同时在视图里记录Job创建和事务提交的时间，对比时序就能清楚看到问题
• 临时修改cron代码，把JobFile.objects.filter(job__in=jobs)改成循环每个Job直接查JobFile.objects.filter(job_id=job.id)，排除QuerySet求值顺序的影响
• 查PostgreSQL的事务日志，对比主事务的提交时间和cron事务的查询时间，能直观看到时序差

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