Tornado 官方怎么不好好维护一个 sql 的异步数据库驱动？

[Gem]

虽然这样显得 Tornado 更加纯粹了，可是在用户实际使用起来，还是有很多不便，社区里面也没有比较高 star 的实现。

[janxin]

Tornado 官方没维护其他的库吧，从维护上我看也就作者一个人主要维护而已。

其实现在我们也遇到了异步驱动的问题，除了 mongodb 官方维护的 motor 的库意外，其他的大概也就能数得上 PyMySQL 官方维护的 Tornado-PyMySQL 了。其他的偶尔都会有坑....

ORM 的支持更加无力...我都打算自己搞了

[Gem]

ORM 更不用想了。

[forging2012]

停播了

[janxin]

@Gem 我已经在想 Tornado 纯做 Web 框架，用 Gevent 加持上同步库了 2333

[lovedboy]

@janxin 我就是这样的。哈哈。 gevent+tornado+pymongo+pymysql

[Gem]

@janxin 这😅

[alex8224]

好吧，最近我在用 storm, 也在用 pymysql,准备加上 storm 的异步支持的，但是思考后决得太难看了。没动手。
还是觉得 gevent 自然一点。

[janxin]

@alex8224 yield from 方式觉得还不如干脆 yield 更好，所以我很期待 3.5+推广开，这样就很好了，而且 gevent 也可以支持关键字

[est]

我记得好像是 @ipconfiger 同志说过， tornado 认为，如果你数据库卡比得都需要异步了，那么怎么异步都没用的。因为数据库其实不怎么能抗并发和耗时的处理。。比如 MVCC 把一行锁等 commit ，你另外一个异步来修改这行，照样需要 locking 等待的。

[alex8224]

@janxin sqlalchemy 的作者写了一篇 <<Asynchronous Python and Databases>> 你可以看看

http://techspot.zzzeek.org/

[ipconfiger]

@est 这个观点是 tornado 作者的，我从不解到赞同到打算突破到继续赞成，经过了多年的心理斗争和努力，事实上，异步并不是一切的终极答案，大多数时候我们在未经思考的时候脱口而出：让我们异步起来吧。其实只是为了图方便而已。

[ipconfiger]

另外 gevent 也不是正确的解法，不管你怎么纤程，一个数据库的 connection 上是只能跑一个 statement 的，那么当一个查询 block 的时候，你也只能启动一个新的 connection 去执行新的 statement ，然后如果一条慢 SQL 要跑 1 秒，那么在这个时候狗屎运爆发了有 1000 个并发请求都在执行这条 SQL ，那么结果就是启动了 1000 个数据库的 connection ，超过 MySQL 的 max_connection 设置数的话，就会开始拒绝连接了。

感兴趣的话去网上随便搜索一点 MySQL 的配置优化方案，有没有数据库开挂上高并发的优化案例。

[janxin]

@est
@alex8224
@ipconfiger
谢谢各位解惑

[ryanking8215]

@est 但是至少 tornado 还能快速响应其他请求（非数据库相关请求），如果业务上没需求的话，这个也然并卵

[sujin190]

我觉得 Tornado 使用异步操作数据库，并不在于 1000 个并发过来，就真的 1000 个查询到数据库，同时查询肯定有上限的，使用异步只是为了不让 tornado 进程处于 iowait 状态，可以减少进程的切换，同时也可以更快的处理非数据库相关的请求，一般对于 web 查询多余读写的情景来说，数据库查询确实会很快，也正是如此数据库到 web 服务器的网络传输时间消耗也占到了整个查询时间的很大比重了吧

[lovedboy]

@ipconfiger 我反正是为了写法爽，不想用 yield,callback 之类。

[fordoo]

好多人从 python 转向 golang ，可能就是这个原因吧：同步 gevent 要踩坑，异步下库跟不上。

[aiqier]

我的理解是：其实在怎么异步，到数据库那一层都是阻塞的，意义不大。你的服务是异步的够了，

[robertding]

@janxin tornado 做纯 web 框架感觉没什么优势, 扩展性很不好

[jjx]

异步就老老实实的用 消息队列+多 worker 模式, 在 worker 中, 同步也行, 用 gevent 也行, 像 tornado 的典型方案应该是这样的

多进程 tornado + pyzmq + proxy +多 worker

这是在生产环境中用的, 要保证 tornado 中要么用异步客户端,要不直接转发到外部进程或消息队列

当然, 在一台服务器上 worker,不行, tornado 接入再多的连接又有什么用, 这种思路本身就是分布式的,要求你的数据库也能分布, 传统的 db 难度得确高了些

[sujin190]

测试了一下， tornado 使用异步数据库操作， sys 使用率可以低 50%，配合 pypy ，在 MySQL 基本没什么数据，读的情况下可以到 11000 每秒处理数，同步数据库操作 7000 左右， MySQL 毫无压力， cpu 使用率不高于 18%，并发的话， ab 同步 400 左右正常， 500 跪了，异步 1000 毫无压力

[est]

@sujin190 可以统计下 python 项目里的 view 。我觉得不调用 db 的 view 不存在。。。。好多 session 都是存 mysql 的。

[ipconfiger]

@sujin190 你再多点请求的话，就会发现数据库垮丝了，能支撑的 QPS 极限是一致的，当然在某些区间异步确实能带来肉眼能看见的提升

[alex8224]

@janxin 这里有一个关于 ORM ASYNC 的回答，你可以看看
http://stackoverflow.com/questions/16491564/how-to-make-sqlalchemy-in-tornado-to-be-async