@CrazySpiderMan 用过 nodejs ，不得不说，没有 yield 的 nodejs 更坑，各种异常处理，查询数据库，麻烦死了，但是 tornado 遇到的问题，估计也会遇到吧

@decaywood 读写分离并不能解决这个问题，单独起个服务的话分明又加了个更复杂的问题，否则有 nginx 我为什么要用 tornado 呢？

@deben 不平稳的请求数，在完全异步的 tornado 环境下，会导致 mysql 队列太长，最终请求超时，客户端发起重试，但 mysql 查询请求并未取消，然后就循环超时，高并发时快速失败是个问题，后来加了队列等待超时机制，然后又一波一波开始超时了，削峰又是个问题啊，异步的 mysql 操作，又有可能造成连接池获取连接死锁问题。。

@janxin 是啊，看来比较懂，后来加了队列超时时间，然后要一波一波开始超时了。。

@mailto1587 异步的，要是阻塞的就简单多了

@hunau 我们在中华门那边 http://www.lagou.com/gongsi/23018.html

@xiamx 所以在设计同步锁的时候要有两个参数，一个是等待最大时间紧，另一个是锁保持最大时间，超过等待最大时间则获取锁超时，超过锁保持的最大时间则获取的锁要自动释放，一般来说超过平均处理时间数倍也就没问题了，这样既可以保持同步，又可以在程序异常时不出现死锁

@em3rge 现在我们支付就已经这么做了，方便很多

南京可来

@lecher 恩，但同时不管提高 mysql 查询性能到多少，总有可能瞬间并发超过的可能，所以应用层能提供一个当严重超负载时快速失败的策略还是必须的

@Ge4Los 我的问题正是 tornado 没有阻塞才出了这个故障。。

@ethego 平时流量并不高，所以应该暂时不用

@tabris17 算是吧，哈哈，现在果断调小了最大连接数

@micyng 我就没说同步 io 。。。

@AlexaZhou 这显然做不到吧，可以取消查询，但调用栈取消不掉啊

@scys aiomysql 遇到的问题还是一样的啊，并发高了之后， tornado 不会拒绝请求，当超过连接池最大链接数后，大量的请求都会阻塞在从连接池获取连接那，最后几乎所以得请求等待连接的时间就超过了请求超时时间， nginx 超时断开连接但 tornado 查询数据库请求却并未取消，客户端如果有重试的话，等待从连接池或取连接的请求会越来越多，最后几乎所有请求都会超时的，除非 tornado 内存爆了，否则是不会出现访问拒绝的

@lecher 并不高， 400 个 mysql 并发查询，有 join ，平时压力并不高所以。。

@calease 因为平时压力很小，所以暂时还没走缓存，没想到突然网络异常重启就跪了

@skydiver 恩，以前没考虑到这种情况