django通过在settings中添加databases的设置即可以实现数据库的访问；通常在开发环境中配置engine，name，passwd就足够了，可是要满足上线需求通常都会设置一个选项CONN_MAX_AGE；通过这个设置可以使得django保存当前的连接；默认情况下每次请求都会使用一个新的连接，频繁的打开关闭连接，效率很低。
DATABASES = {
‘default’: {
‘ENGINE’: ‘django.db.backends.mysql’,
‘NAME’: ‘dbname’,
‘CONN_MAX_AGE’: 600, # 参照mysql的wait_timeout 和 interactive_timeout
}
}
这种配置的持久化连接每次都将存活10分钟。
但是问题还没完，这个配置需要结合数据库的配置，数据库中输入
show variables like "%timeout%"
SHOW SESSION VARIABLES LIKE "wait_timeout";
SHOW GLOBAL VARIABLES LIKE "wait_timeout"; -- 660
tips: 这两个值有可能不一样，一个是session一个是global;如果mysql没有设置interactive_timeout，可能看到的一直是session wait_timeout 这个值可能是8小时 28800；设置了interactive_timeout后显示为660
查看wait_timeout 和 interactive_timeout 的值，通常CONN_MAX_AGE值要比这两个值稍小，后面我们会分析原因；
案例 daphne -- MySQL server has gone away
由于项目需要使用websocket，因此引入了django channels；在部署的时候采用了nginx + uwsgi + daphne的方式；大多数的http请求由uwsgi来响应；而ws由daphne进程处理；在开发阶段没有发现任何问题，可上线测试时候daphne频繁报错，错误提示如下；但是使用同一个数据库的uwsgi却并不会报错。sigh ~~
ERROR Exception inside application: (2006, 'MySQL server has gone away')
在github上面也有类似的问题 Django channels uses persistent database connections? MySQL server gone away in Auth middleware，但是解答都不怎么靠谱；
下面我们分析一下导致问题的原因，并由此看一下django这部分的实现。
先上一段代码看看每次wsgihandler在处理请求的时候都做了些什么：
class WSGIHandler(base.BaseHandler):
initLock = Lock()
request_class = WSGIRequest
def __call__(self, environ, start_response):
# Set up middleware if needed. We couldn't do this earlier, because
# settings weren't available.
if self._request_middleware is None:
with self.initLock:
try:
# Check that middleware is still uninitialised.
if self._request_middleware is None:
self.load_middleware()
except:
# Unload whatever middleware we got
self._request_middleware = None
raise
set_script_prefix(base.get_script_name(environ))
signals.request_started.send(sender=self.__class__)
try:
request = self.request_class(environ)
except UnicodeDecodeError:
logger.warning('Bad Request (UnicodeDecodeError)',
exc_info=sys.exc_info(),
extra={
'status_code': 400,
}
)
response = http.HttpResponseBadRequest()
else:
response = self.get_response(request)
response._handler_class = self.__class__
status = '%s %s' % (response.status_code, response.reason_phrase)
response_headers = [(str(k), str(v)) for k, v in response.items()]
for c in response.cookies.values():
response_headers.append((str('Set-Cookie'), str(c.output(header=''))))
start_response(force_str(status), response_headers)
return response
通过上面代码可以看出，WSGIHandler主要做了以下几件事情：
- 加载request middleware
- 发送request_started的信号
- 获取response
- 设置cookies
- 返回response
其他的代码看起来都比较直观，只有第二条发送一个信号，这个信号做什么呢；
# request_started 的定义
request_started = Signal()
查找这个时间注册的处理函数发现，在django.core.db.__ init __.py中注册了close_old_connections事件处理函数；
# 在文件 django.core.db.__init__.py中
def reset_queries(**kwargs):
for conn in connections.all():
conn.queries_log.clear()
signals.request_started.connect(reset_queries)
# Register an event to reset transaction state and close connections past
# their lifetime.
def close_old_connections(**kwargs):
for conn in connections.all():
conn.close_if_unusable_or_obsolete()
signals.request_started.connect(close_old_connections)
signals.request_finished.connect(close_old_connections)
继续代码 close_if_unusable_or_obsolete()
def close_if_unusable_or_obsolete(self):
"""
Closes the current connection if unrecoverable errors have occurred,
or if it outlived its maximum age.
"""
if self.connection is not None:
# If the application didn't restore the original autocommit setting,
# don't take chances, drop the connection.
if self.get_autocommit() != self.settings_dict['AUTOCOMMIT']:
self.close()
return
# If an exception other than DataError or IntegrityError occurred
# since the last commit / rollback, check if the connection works.
if self.errors_occurred:
if self.is_usable():
self.errors_occurred = False
else:
self.close()
return
if self.close_at is not None and time.time() >= self.close_at:
self.close()
return
检查当前的connection是否 is_usable,如果不可用或者当前时间> self.close_at(CONN_MAX_AGE 设置的超时时间)就会关闭当前的连接；那我们再看看如何知道connection 是否可用, 在django.db.backends.base.py 中有如下代码：
class DatabaseWrapper(BaseDatabaseWrapper):
def is_usable(self):
try:
self.connection.ping()
except Database.Error:
return False
else:
return True
如果当前connection ping命令正常就说明可用；说道这里真相就呼之欲出了
分析
- 每当收到一个请求，wsgihandler都会发送信号 request_start 信号
- database engine收到信号，检查所有的数据库connection是否有已经超时的，如果未设置CONN_MAX_AGE，或者设置的时间已经超时就关闭当前的数据库连接； 因此设置适当的CONN_MAX_AGE既保证高效的重用连接，又防止长时间占用；
daphne MySQL报错的问题
在daphne中 因为处理的都是websocket，不经过wsgihandler；因此数据库中超时的连接不会被及时的清理，因此导致了daphne 中的数据库访问获取的连接可能已经超时；因此访问的时候报错 MySQL server has gone away； （由于数据库engine的实现不同，如果实现方式为使用了mysql已经回收的连接，重新获取一个新的连接执行操作，这种可能会导致数据库访问时间变长）
总结
看明白了整个处理过程；就很容易修改上面提到的问题了
在django channels进行数据库访问之前，比如auth middleware中调用close_old_connections就可以了；
from django.db import close_old_connections
close_old_connections
# 自己定义一个decorator，用来装饰使用数据库的函数
def close_old_connections_wrapper(func):
def wrapper(*args, **kwargs):
close_old_connections()
return func(*args, **kwargs)
return wrapper
