gunicorn 多 worker 运行 django 实例，怎么保证每一个 django 是进程安全的，不会出现脏数据？

假如启了 2 个 worker，用户 A 第一次的 request 是走 worker1 的 django 实例，用户 A 第二次的 request 是走 worker2 的 django 实例。

按正常情况，应该是第一次的 request 先完成，但是某些 io 特殊情况导致第一次的 request 未及时完成，这个时候第二个 request 已经来了，问题是第二个 request 走的是 worker2，worker1 阻塞不了 worker2 啊，会导致注重数据操作顺序的时候，worker2 把 worker1 要处理的数据提前弄脏了。

request

worker2

django

worker1

8 replies • 2019-09-06 10:31:34 +08:00

heww

Sep 4, 2019

数据库事务隔离了解下～

ManjusakaL

Sep 4, 2019

这个时候为啥要交给 L4/L7 的框架来做？

你同一个用户有着依赖关系，B 依赖于 A 的成功结束，那么你为啥要同时发送两个请求？

这种情况正确的思路难道不是顺序请求，确保 A 请求结束之后再发起 B 请求啊？

dcoder

Sep 4, 2019

Django request 会对应到数据库的 transaction. 是数据库帮你搞定的, 基本只有数据库才是 stateful 的.

cz5424

Sep 4, 2019 via iPhone

1，2 楼已经说的很清楚了，不是 worker1 或 2 的问题，请求有先后的话，可以用这个方法，从请求 1 拿到凭证再发给 2

cuojue4655807

Sep 4, 2019

不能保证无状态的 api 考虑下加业务锁?

qqxx520

Sep 4, 2019 via Android

加锁，可以在 redis 里写一个 key，请求完成后销毁，其他进程的请求判断 key 是否存在，是就返回状态码，让客户端等会再试

jesnridy

Sep 4, 2019

基本就是数据库层面解决的，避免事务幻读就考虑在数据列加唯一键或者更改数据库隔离级别。

lolizeppelin

Sep 6, 2019

HTTP 的请求就不应该有阻塞
HTTP 设计本身就是无状态的才会有 fast cgi 这样的形式,http 请求本身就不应该有需要长时间执行的调用

你要实现 B 请求在 A 未完成的时候阻塞本身就是错误的思路,违背了 HTTP 协议的本意
如果 B 需要依赖 A 完成,那么 B 请求发现 A 未完成的时候直接返回 A 未完成,而不是阻塞

由客户端轮询 B 请求,直到成功执行

否者,需要设计成服务端通知模式,这就需要 websocket

gunicorn 多 worker 运行 django 实例，怎么保证 每一个 django 是进程安全的，不会出现脏数据？

gunicorn 多 worker 运行 django 实例，怎么保证每一个 django 是进程安全的，不会出现脏数据？