Sqlalchemy
flask-sqlalchemy的session是线程安全的，但在多进程环境下，要确保派生子进程时，父进程不存在任何的数据库连接，可以通过调用db.get_engine(app=app).dispose()来手动销毁已经创建的engine，然后再派生子进程。
最近线上的项目总是会报出数据库连接相关的错误，比如“Command out of Sync”，“Mysql server has gone away”，“Lost databse connection”，“Package sequence out of order”等等，最终解决下来，发现以上错误可以分为两种，一种是和连接丢失有关的，一种是和连接被多个线程（进程）同时使用了有关。
我们项目基于flask，有多线程的场景，也有多进程的场景。orm用的是flask的拓展flask-sqlalchemy。flask-sqlalchemy的使用必须基于flask的app实例，也就是说要在app上下文中才能使用flask-sqlalchemy，所以在某些离线（非web）场景下，我们也用到了原生的Sqlalchemy。
原生的Sqlalchemy的使用方式是
engine = create_engine(db_url) Session = sessionmaker(bind=engine) session = Session()
session.query(xxx)
首先要创建一个engine，engine顾名思义就是和数据库连接的引擎。在实际发起查询前，是不会创建任何connection的。创建engine时可以通过指定poolclass参数来指定engine使用的连接池。默认是QueuePool，也可以设置为NullPool（不使用连接池）。为了方便理解，可以把engine视为管理连接池的对象。
sqlalchemy中session和我们平时数据库里说的session是两个不同的概念，在平时数据库中，session的生命周期从连接上数据库开始，到断开和数据库的连接位置。但是sqlalchemy中的session更多的是一种管理连接的对象，它从连接池取出一个连接，使用连接，然后释放连接，而自身也跟随着销毁。sqlalchemy中的Connection对象是管理真正数据库连接的对象，真正的数据库连接在sqlalchemy中是DBAPI。
默认地，如果不传入poolclass，则使用QueuePool（具有一定数量的连接池），如果不指定pool_recycle参数，则默认数据库连接不会刷新。也就是说连接如果不适用，则一直不去刷新它。但是问题来了，在Mysql中，输入“show variables like "%timeout%"; ” ，可以看到有一个waittimeout，还有interacttimeout，默认值为28800（8小时），这两个值代表着，如果8个小时内某个数据库连接都不和mysql联系，那么就会断掉这个连接。所以，8个小时过去了，Mysql把连接断掉了，但是sqlalchemy客户端这边却还保持着这个连接。当某个时候该连接从连接池被取出使用时，就会抛出“Mysql server has gone away”等连接丢失的信息。
解决这个问题的办法很简单，只要传入pool_recycle参数即可。特别地，在flask-sqlalchemy中不会出现这种问题，因为falsk-sqlalchemy拓展自动地帮我们注入了pool_recycle参数，默认为7200秒。
def apply_driver_hacks(self, app, sa_url, options):
"""This method is called before engine creation and used to inject
driver specific hacks into the options. The `options` parameter is
a dictionary of keyword arguments that will then be used to call
the :func:`sqlalchemy.create_engine` function.
The default implementation provides some saner defaults for things
like pool sizes for MySQL and sqlite. Also it injects the setting of
`SQLALCHEMY_NATIVE_UNICODE`.
"""
if sa_url.drivername.startswith('mysql'):
sa_url.query.setdefault('charset', 'utf8')
if sa_url.drivername != 'mysql+gaerdbms':
options.setdefault('pool_size', 10)
options.setdefault('pool_recycle', 7200) # 默认7200秒刷新连接
elif sa_url.drivername == 'sqlite':
pool_size = options.get('pool_size')
detected_in_memory = False
if sa_url.database in (None, '', ':memory:'):
detected_in_memory = True
from sqlalchemy.pool import StaticPool
options['poolclass'] = StaticPool
if 'connect_args' not in options:
options['connect_args'] = {}
options['connect_args']['check_same_thread'] = False
# we go to memory and the pool size was explicitly set
# to 0 which is fail. Let the user know that
if pool_size == 0:
raise RuntimeError('SQLite in memory database with an '
'empty queue not possible due to data '
'loss.')
# if pool size is None or explicitly set to 0 we assume the
# user did not want a queue for this sqlite connection and
# hook in the null pool.
elif not pool_size:
from sqlalchemy.pool import NullPool
options['poolclass'] = NullPool
# if it's not an in memory database we make the path absolute.
if not detected_in_memory:
sa_url.database = os.path.join(app.root_path, sa_url.database)
unu = app.config['SQLALCHEMY_NATIVE_UNICODE']
if unu is None:
unu = self.use_native_unicode
if not unu:
options['use_native_unicode'] = False
if app.config['SQLALCHEMY_NATIVE_UNICODE'] is not None:
warnings.warn(
"The 'SQLALCHEMY_NATIVE_UNICODE' config option is deprecated and will be removed in"
" v3.0. Use 'SQLALCHEMY_ENGINE_OPTIONS' instead.",
DeprecationWarning
)
if not self.use_native_unicode:
warnings.warn(
"'use_native_unicode' is deprecated and will be removed in v3.0."
" Use the 'engine_options' parameter instead.",
DeprecationWarning
)
sessionmaker是Session定制方法，我们把engine传入sessionmaker中，就可以得到一个session工厂，通过工厂来生产真正的session对象。但是这种生产出来的session是线程不安全的，sqlalchemy提供了scoped_session来帮助我们生产线程安全的session，原理类似于Local，就是代理session，通过线程的id来找到真正属于本线程的session。
flask-sqlalchemy就是使用了scoped_session来保证线程安全，具体的代码可以在Sqlalchemy中看到，构造session时，使用了scoped_session。
def create_scoped_session(self, options=None):
"""Create a :class:`~sqlalchemy.orm.scoping.scoped_session`
on the factory from :meth:`create_session`.
An extra key ``'scopefunc'`` can be set on the ``options`` dict to
specify a custom scope function. If it's not provided, Flask's app
context stack identity is used. This will ensure that sessions are
created and removed with the request/response cycle, and should be fine
in most cases.
:param options: dict of keyword arguments passed to session class in
``create_session``
"""
if options is None:
options = {}
scopefunc = options.pop('scopefunc', _app_ctx_stack.__ident_func__)
options.setdefault('query_cls', self.Query)
return orm.scoped_session(
self.create_session(options), scopefunc=scopefunc
)
def create_session(self, options):
"""Create the session factory used by :meth:`create_scoped_session`.
The factory **must** return an object that SQLAlchemy recognizes as a session,
or registering session events may raise an exception.
Valid factories include a :class:`~sqlalchemy.orm.session.Session`
class or a :class:`~sqlalchemy.orm.session.sessionmaker`.
The default implementation creates a ``sessionmaker`` for :class:`SignallingSession`.
:param options: dict of keyword arguments passed to session class
"""
return orm.sessionmaker(class_=SignallingSession, db=self, **options)
多进程和数据库连接
多进程环境下，要注意和数据库连接相关的操作。
说到多进程，python里最常用的就是multiprocessing。multiprocessing在windows下和linux的表现有所区别，在此只讨论linux下的表现。linux下多进程通过fork()来派生，要理解我下面说的必须先弄懂fork()是什么东西。粗略地说，每个进程都有自己的一个空间，称为进程空间，每个进程的进程空间都是独立的，进程与进程之间互不干扰。fork()的作用，就是将一个进程的进程空间，完完全全地copy一份，copy出来的就是子进程了，所以我们说子进程和父进程有着一模一样的地址空间。地址空间就是进程运行的空间，这空间里会有进程已经打开的文件描述符，文件描述符会间接地指向进程已经打开的文件。也就是说，fork()之后，父进程，子进程会有相同的文件描述符，指向相同的一个文件。为什么？因为文件是存在硬盘里的，fork()时copy的内存中的进程空间，并没有把文件也copy一份。这就导致了，父进程，子进程，同时指向同一个文件，他们任意一个都可以对这个文件进行操作。这和本文说的数据库有啥关系？顺着这个思路想，数据库连接是不是一个TCP连接？TCP连接是不是一个socket？socket在linux下是什么，就是一个文件。所以说，如果父进程在fork()之前打开了数据库连接，那么子进程也会拥有这个打开的连接。
两个进程同时写一个连接会导致数据混乱，所以会出现“Command out of sync”的错误，两个进程同时读一个连接，会导致一个进程读到了，另一个没读到，就是“No result”。一个进程关闭了连接，另一个进程并不知道，它试图去操作连接时，就会出现“Lost database connection”的错误。
在此讨论的场景是，父进程在派生子进程之前，父进程拥有已打开的数据库连接。派生出子进程之后，子进程也就拥有了相应的连接。如果在fork()之前父进程没有打开数据库连接，那么也不用担心这个问题。比如Celery使用的prefork池，虽然是多进程模型，但是celery在派子进程前时不会打开数据库连接的，所以不用担心在celery任务中会出现数据库连接混乱的问题。
我做的项目里的多进程的场景之一就是使用tornado来跑web应用，在派生多个web应用实例时，确保此前创建的数据库连接被销毁。
app = Flask() db = Sqlalchemy() db.init_app(app) ... ... db.get_engine(app=app).dispose() # 先销毁已有的engine，确保父进程没有数据库连接 ... ... fork() # 派生子进程
# 例如
tornado.start() # 启动多个web实例进程