casbin 是否可以参考下，主要是整理 rbac 模型数据，剩下的可以通过 middleware 的方式进行权限管控

感谢回复。通过手动执行上述场景的锁持有状况来看，确实是这样的

time1 时刻，由于 id=22 在表中是没有的，此刻事务 A 会在 (15, 25) 加上间隙锁
time2 时刻，由于 id=21 在表中也是没有的，且间隙锁之间不是互斥的，所以此刻事务 B 会在 （ 15, 25 ）加上间隙锁

time3 时刻的 insert 语句因为事务 B 间隙锁的存在所以需要等待事务 B 间隙锁释放；
time4 时刻的 insert 语句因为事务 A 间隙锁的存在所以需要等待事务 A 间隙锁释放；

从而出现死锁的情况

首先 python3 manage.py makemigrations 是会基于 django_migration 表和当前的 model.py 进行的差异对比生成 migrations 文件，执行 migrate 后是根据新增的 migrations 文件执行表结构变更后在 django_migrations 插入对应 migrations 文件对应的 app 信息和时间戳版本信息

所以需要对比 django_migrations 表各 app 执行模块对应最新版本信息、migrations 文件信息、以及对应表结构综合对比

是否可以采用 MySQL 临时表的方案解决该问题

所有的表数据查询后都汇总到临时表中，然后在临时表进行 join 、aggregate 的操作，断开数据库连接后临时表也会自动回收掉

第一次发帖还没写好不小心点了发送，麻了

https://docs.celeryq.dev/en/stable/userguide/canvas.html#chords

菜鸟一枚，方案不夕勿喷，个人觉得可以采用 celery chord 的方式进行处理，它会等待所有的子任务处理完毕以后触发回调的方法

子任务可以做字段选择和字段去重工作，大致思路是这样
result1 = chord(处理数据源 1 ，处理数据源 2)（记录连接 1 方法）
result2 = chord(处理数据源 3 ，处理数据源 4)（记录连接 2 方法）
reslut3 = chord(result1, result2)

集群里每新增一个 Service 在每个宿主机的 iptables 都会增加一条 iptables 规则，而每条 iptables 规则都有与 Pod 对应的集合

所以 Service 多了 iptables 会变多，Pod 多了对应的规则维护与 Pod 对应关系的集合也会多

故都有关系

似乎使用 celery 的 chord 方法场景更合适，可以并发处理任务的结果，当所有结果准备好以后进行回调做顺序的编排

https://docs.celeryq.dev/en/stable/userguide/canvas.html#chords