@geew 借鉴了drupal的设计。

@mywaiting 附加: 那个and or 只是为了写比较复杂的and or组合，当然特别复杂的直接raw sql最好了。

@mywaiting 关键是python db api规范参数预处理绑定比较蛋疼，那个如果需要参数转义反注入怎么办。 那种简单真的不如 db.query('SELECT * FROM tabel_name where a=%s and b=%s', (a, b))

或者 db.select('table_name').condition('a', 1).condition('b', 2) 这样至少做会做转义防止sql注入

@baoyexi 恩，好吧，谢谢提醒。纠正

@ipconfiger 不知道，hello这种东西，以前用c 与libev做的可以直接到3w，然后flask加gevent也就3k左右。大多数应用如果有cache层，这时也许有点意义了。

@tanywei 钩子都有，然后底层使用的webob，不会比Werkzeug差。

@typcn 不会在乎的，其实用redis 的sorted set很方便。只是设计而已，用关联数据库首先不会有nosql那么快，但相对没那么耗内存耗cpu，但如果没有做好优化可能很容易玩坏硬盘。ssd自然也是很贵的

没有优化呀， golang 加redis 做chat 一进程能承受4w sockets 40w msg/s ， 4w 套接字应该要耗2g内存的

@c4pt0r 嗯 mesos 有一个 https://github.com/airbnb/chronos 不过有点负载，java的不知道是否结合应用能否省时间。

@9hills 是的，只是支持crontab的主要时间格式，对于消息系统消费模式，queued任务现在没有实现，主要实现定时任务调度。对于本地cache任务并不好做，因为使用的分布式任务调度，对于超时已经实现处理。

对于报警的考虑是因为已经有web tool，用户注册时会有email就可以通过email报警，或者使用一个特定邮箱统一报警。另外日志的监控这块也是会考虑。现在主要做的是一个模型。

@zzNucker 任务的注册管理App类借鉴的的wsgi类似模式。 就是:


def app(task): pass # to do something

# most like wsgi: def app(environ, start_response): pass

所以理解wsgi应该比较好懂。

@zzNucker 这个现在只是定时任务调度，还没有实现queued任务分派，（想法是使用zeromq或者rabbitmq实现）。 mysql对于成千上万的定时任务绝对是够用的。为了考虑到更多定时任务和更大负载，将会加入mongodb的适配mapper，以加快优化定时任务调度，加大任务的负载。如果使用mysql做queued调度也是可行的，但是性能会不如使用消息系统。所以在考虑queued任务作为消息系统实现。

@ryanking8215 抱歉呀，sqlalchemy没用过，做游戏的，不关心这类的，更喜欢直接使用data-mapper模式。

http://martinfowler.com/eaaCatalog/dataMapper.html

推荐看这位作者企业架构书 http://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420

@zhouquanbest


先说最简单的方法， 使用OpenResty lua 编写数据库落地接口

tornado 优化一个能够长连接的http client 或者直接使用自带的异步client 发送请求 如

req: /query?op=user.find_by_user&uid=1222

res ： {"uid" : 1222, "name", ...... }

req /execute?op=user.save&data=<User.as_json>

req: 200 0k

这类架构 数据库使用openresty 作为dbproxy

上面的例子中使用的http协议，数据可是用json或者google protobuf（这个比较高效）

效率在 3k-4k req/s


### 使用长连接


如果绝对http协议不够高效，那么使用tcp自行封装一个简单长连接的协议。 不过这样dbproxy serverlength需要使用c++之类的做个异步server了。协议可以选高效的二进制协议 protobuf只是一个选择。

如

req: {"op": "user.find_by_uid", "data": {"uid": 12}}\r\n

使用这类行协议

回复如下：

7200 ok
23{"uid" : 1222, "name", ...... }

回复消息定义首4位标识消息状态长度 上面是状态200 msg为 ok 之间是空格分隔
然后紧接着32位标识数据长度，后面自定义解析的raw数据，觉得要省事可以使用protobuf。

这类优化后到 5-6k req/s问题不大。但这时，妈蛋去多关心你的数据库压力，然后去优化吧。

@ryanking8215 你把自己绑死在sqlalchemy了。

@zhouquanbest celery只是一个解，但绝对不是最优的

不知道你要做什么玩意，如果你的负载有4k req/s， 就告诉一个方法如何用tornado 和数据库异步落地架构（当然不是搞个什么python mysql异步库版本之类的）

__len__ 方法

@1989922yan

Gunicorn 'Green Unicorn' is a Python WSGI HTTP Server for UNIX. It's a pre-fork worker model ported from Ruby's Unicorn project.

perfork的玩意性能将就，就是费内存