django - django 应用程序的 uWSGI + nginx 避免 pylibmc 多线程并发问题？

Question

介绍

本周我遇到了这个非常有趣的问题，最好从一些事实开始:

pylibmc是 not thread safe ，当用作 django memcached 后端时，直接在 shell 中启动多个 django 实例会在遇到并发请求时崩溃。

如果使用 nginx + uWSGI 部署，pylibmc 的这个问题会神奇地消失。

如果您将 django 缓存后端切换到 python-memcached ，它也将解决这个问题，但这个问题不是关于那个。

细化

从第一个事实开始，这就是我复制 pylibmc 的方式问题:
pylibmc失败

我有一个 django 应用程序，它进行大量的 memcached 读写，并且有这个部署策略，我在 shell 中启动多个 django 进程，绑定(bind)到不同的端口(8001、8002)，并使用 nginx 来做平衡。

我使用 locust 对这两个 django 实例启动了两个单独的负载测试。 ，这就是发生的事情:



在上面的屏幕截图中，它们都崩溃并报告了完全相同的问题，如下所示:

Assertion "ptr->query_id == query_id +1" failed for function "memcached_get_by_key" likely for "Programmer error, the query_id was not incremented.", at libmemcached/get.cc:107

uWSGI 来救援

所以在上面的例子中，我们通过 pylibmc 了解到对 memcached 的多线程并发请求。可能会导致问题，这在某种程度上不会打扰 uWSGI具有多个工作进程。

为了证明这一点，我开始 uWSGI包括以下设置:

master          = true
processes       = 2

这告诉 uWSGI 启动两个工作进程，然后我告诉 nginx 服务任何 django 静态文件，并将非静态请求路由到 uWSGI ，看看会发生什么。随着服务器启动，我在 localhost 中针对 django 启动了相同的 locust 测试，并确保每秒有足够的请求来导致对 memcached 的并发请求，结果如下:



在 uWSGI控制台，没有工作进程死亡的迹象，也没有重新生成任何工作进程，但查看屏幕截图的上半部分，肯定有并发请求(5.6 req/s)。

问题

我非常好奇 uWSGI让它消失，我无法在他们的文档中了解到这一点，回顾一下，问题是:

uWSGI是如何管理worker进程的，让多线程memcached请求不会导致django崩溃？

事实上，我什至不确定是不是这样 uWSGI管理避免此问题的工作进程，或 uWSGI 附带的一些其他魔法这就是诀窍，我在他们的文档中看到了一个叫做 memcached 路由器的东西，我不太明白，这有关系吗？

Answer 1

不是因为你实际上有两个由 uWSGI 管理的独立进程吗？由于您设置的是 processes 选项而不是 workers 选项，因此您实际上应该有多个 uWSGI 进程(由于您使用的配置，我假设一个 master + 两个 worker)。这些进程中的每一个都有自己加载的 pylibmc，因此线程之间没有状态共享(毕竟你还没有在 uWSGI 上配置线程)。