django-mysqlpool 0.1-9

简介

这是一个简单的Django数据库后端，用于连接池。此后端基于Ed Menendez的一篇博客文章。

http://menendez.com/blog/mysql-connection-pooling-django-and-sqlalchemy/

主要区别在于

1. 工作由您完成。

2. 我们不是克隆Django mysql后端，而是对其进行猴子补丁。

第二点听起来很糟糕，但这是最佳选择，因为它不会将Django MySQL后端锁定在特定修订版上。使用此方法可以使我们利用Django项目修复的任何错误，同时在连接池上构建。

实际的池化是通过SQLAlchemy完成的。虽然不完美（此后端仅限于每个进程），但它是有用的。它为我们解决的主要问题是限制进程到一定数量的总连接数。

使用方法

配置此后端而不是默认的Django mysql后端。

DATABASES = {
    'default': {
        'ENGINE': 'django_mysqlpool.backends.mysqlpool',
        'NAME': 'db_name',
        'USER': 'username',
        'PASSWORD': 'password',
        'HOST': '',
        'PORT': '',
    },
}

配置

您可以定义池实现及其传递给它的特定参数。可用的实现（后端）及其参数在SQLAlchemy文档中定义。

https://docs.sqlalchemy.org.cn/en/rel_0_7/core/pooling.html

• MYSQLPOOL_BACKEND - 池实现名称（默认为'QueuePool'）。

• MYSQLPOOL_ARGUMENTS - 传递给池的kwargs。

例如，要使用无threadlocal的QueuePool，可以使用以下配置。

MYSQLPOOL_BACKEND = 'QueuePool'
MYSQLPOOL_ARGUMENTS = {
    'use_threadlocal': False,
}

连接关闭

虽然这与连接池没有直接关系，但它与之相关。一旦开始池化（并限制）数据库连接，关闭它们就变得很重要。

这仅在处理线程化应用程序时才有实际意义。我们服务器中的一个就是这样。它会为处理并发操作创建许多线程。每个线程都会持续打开到数据库的连接。一旦我们部署了连接池，这个服务很快就耗尽了连接池的连接限制。

这听起来像是一次巨大的失败，但对我们来说却是一次巨大的成功。原因是，我们实施池化的具体目的是为了限制每个进程的连接数。这防止了任何给定进程影响其他服务，将全局问题转化为局部问题。一旦我们能够确定哪个具体服务正在滥用我们的MySQL服务器，我们就能够修复它。

以下是关于我们与该线程服务器存在的问题的详细描述。

http://stackoverflow.com/questions/1303654/threaded-django-task-doesnt-automatically-handle-transactions-or-db-connections

因此，这个库提供了一个装饰器，可以在类似情况下使用以帮助连接管理。您可以使用它如下。

from django_mysqlpool import auto_close_db

@auto_close_db
def function_that_uses_db():
    MyModel.objects.all().delete()

在池化（和线程）中，提前和频繁地关闭连接是良好性能的关键。关闭操作将连接返回到池中以便重用，从而减少了连接总数。我们还需要禁用QueuePool的use_threadlocal选项，以便多个线程可以共享相同的连接。一旦我们将所有使用连接的函数都进行了装饰，这个服务使用的连接数就比总线程数少。

分叉

如果您使用mysqlpool与守护进程（我们的项目使用Django admin命令构建守护进程），那么您需要注意连接池。在fork()之后，池将无法使用。在我们的情况下，连接的文件描述符被关闭，在子进程中，任何新的连接或文件都假定了MySQL连接的fd，这导致Django ORM在我们的情况下在Redis上读写，因此Django会将SQL发送到Redis并期待回复！解决方案是在fork()之前关闭池。这将释放池连接，当子进程第一次尝试使用它们时将重新打开。

from django_mysqlpool import close_pool

close_pool()
pid = os.fork()