介绍

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

> 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实例启动了两个单独的负载测试,这就是：

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

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启动了相同的蝗虫测试,并确保每秒有足够的请求来引发对memcached的并发请求,结果如下：

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

这个问题

我非常好奇uWSGI如何让它消失,而我无法从他们的文档中了解到,回顾一下,问题是：

uWSGI是如何管理工作进程的,因此多线程memcached请求不会导致django崩溃？

事实上,我甚至不确定这是uWSGI管理工作流程以避免这个问题的方式,还是uWSGI附带的其他一些魔术,我在他们的文档中看到了一些名为memcached路由器的东西,我没有’很明白,这有关系吗？