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

Question

引言

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

• pylibmc是not thread safe，当用作django memcached后端时，在shell中直接启动多个django实例会在并发请求命中时崩溃。
• 如果使用nginx + uWSGI部署，那么pylibmc就会神奇地解决这个问题。
• 如果您将django缓存后端切换到python-memcached，它也将解决这个问题，但这个问题与此无关。

精化

从第一个事实开始，我是如何复制pylibmc问题的：

pylibmc的失效

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

我使用locust对这两个django实例启动了两个单独的负载测试，结果如下：

​

​

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

断言"ptr->query_id == query_id +1“对于函数"memcached_get_by_key”失败，可能是“程序员错误，query_id没有增加”，在libmemcached/get.cc:107处。

uWSGI到救援

因此，在上述情况下，我们了解到通过pylibmc对memcached的多线程并发请求可能会导致问题，这在某种程度上不会影响多个辅助进程的uWSGI。

为了证明这一点，我从以下设置开始uWSGI：

master          = true
processes       = 2

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

​

​

在uWSGI控制台中，没有死工作进程的迹象，也没有工作人员被重新生成，但是从屏幕截图的上部看，确实存在并发请求(5.6req/s)。

问题是

我非常好奇uWSGI是如何解决这个问题的，我无法从他们的文档中了解到这一点，简单地说，问题是：

uWSGI是如何管理工作进程的，这样多线程memcached请求就不会导致django崩溃？

事实上，我甚至不确定是否是uWSGI管理工作进程的方式避免了这个问题，或者是uWSGI带来的其他魔法在起作用，我在他们的文档中看到了一个叫做memcached路由器的东西，我不太明白，这有关系吗？

Answer 1

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