首页 > tornado 3.2附带的chatdemo的代码中是如何实现异步的?最小利用cpu资源的,我没看见它释放cpu资源。

tornado 3.2附带的chatdemo的代码中是如何实现异步的?最小利用cpu资源的,我没看见它释放cpu资源。

主程序的代码是:

#!/usr/bin/env python
#
# Copyright 2009 Facebook
#
# Licensed under the Apache License, Version 2.0 (the "License"); you may
# not use this file except in compliance with the License. You may obtain
# a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
# License for the specific language governing permissions and limitations
# under the License.

import logging
import tornado.auth
import tornado.escape
import tornado.ioloop
import tornado.web
import os.path
import uuid

from tornado import gen
from tornado.options import define, options, parse_command_line

define("port", default=8888, help="run on the given port", type=int)


class MessageBuffer(object):
    def __init__(self):
        self.waiters = set()
        self.cache = []
        self.cache_size = 200

    def wait_for_messages(self, callback, cursor=None):
        if cursor:
            new_count = 0
            for msg in reversed(self.cache):
                if msg["id"] == cursor:
                    break
                new_count += 1
            if new_count:
                callback(self.cache[-new_count:])
                return
        self.waiters.add(callback)

    def cancel_wait(self, callback):
        self.waiters.remove(callback)

    def new_messages(self, messages):
        logging.info("Sending new message to %r listeners", len(self.waiters))
        for callback in self.waiters:
            try:
                callback(messages)
            except:
                logging.error("Error in waiter callback", exc_info=True)
        self.waiters = set()
        self.cache.extend(messages)
        if len(self.cache) > self.cache_size:
            self.cache = self.cache[-self.cache_size:]


# Making this a non-singleton is left as an exercise for the reader.
global_message_buffer = MessageBuffer()


class BaseHandler(tornado.web.RequestHandler):
    def get_current_user(self):
        user_json = self.get_secure_cookie("chatdemo_user")
        if not user_json: return None
        return tornado.escape.json_decode(user_json)


class MainHandler(BaseHandler):
    @tornado.web.authenticated
    def get(self):
        self.render("index.html", messages=global_message_buffer.cache)


class MessageNewHandler(BaseHandler):
    @tornado.web.authenticated
    def post(self):
        message = {
            "id": str(uuid.uuid4()),
            "from": self.current_user["first_name"],
            "body": self.get_argument("body"),
        }
        # to_basestring is necessary for Python 3's json encoder,
        # which doesn't accept byte strings.
        message["html"] = tornado.escape.to_basestring(
            self.render_string("message.html", message=message))
        if self.get_argument("next", None):
            self.redirect(self.get_argument("next"))
        else:
            self.write(message)
        global_message_buffer.new_messages([message])


class MessageUpdatesHandler(BaseHandler):
    @tornado.web.authenticated
    @tornado.web.asynchronous
    def post(self):
        cursor = self.get_argument("cursor", None)
        global_message_buffer.wait_for_messages(self.on_new_messages,
                                                cursor=cursor)

    def on_new_messages(self, messages):
        # Closed client connection
        if self.request.connection.stream.closed():
            return
        self.finish(dict(messages=messages))

    def on_connection_close(self):
        global_message_buffer.cancel_wait(self.on_new_messages)


class AuthLoginHandler(BaseHandler, tornado.auth.GoogleMixin):
    @gen.coroutine
    def get(self):
        if self.get_argument("openid.mode", None):
            user = yield self.get_authenticated_user()
            self.set_secure_cookie("chatdemo_user",
                                   tornado.escape.json_encode(user))
            self.redirect("/")
            return
        self.authenticate_redirect(ax_attrs=["name"])


class AuthLogoutHandler(BaseHandler):
    def get(self):
        self.clear_cookie("chatdemo_user")
        self.write("You are now logged out")


def main():
    parse_command_line()
    app = tornado.web.Application(
        [
            (r"/", MainHandler),
            (r"/auth/login", AuthLoginHandler),
            (r"/auth/logout", AuthLogoutHandler),
            (r"/a/message/new", MessageNewHandler),
            (r"/a/message/updates", MessageUpdatesHandler),
            ],
        cookie_secret="__TODO:_GENERATE_YOUR_OWN_RANDOM_VALUE_HERE__",
        login_url="/auth/login",
        template_path=os.path.join(os.path.dirname(__file__), "templates"),
        static_path=os.path.join(os.path.dirname(__file__), "static"),
        xsrf_cookies=True,
        )
    app.listen(options.port)
    tornado.ioloop.IOLoop.instance().start()


if __name__ == "__main__":
    main()

主要是class MessageUpdatesHandler(BaseHandler)那里,明明是用了异步的装饰器,但是我没看出来他是如何把他做成异步的,如果没有做成异步的,那这个东西会占用服务器的cpu的资源太多了,我想官方安装包下的demo应该不会出错的,请哪位大神帮我细致的解释一下,这段demo是如何唯美地实现了一个chatroom的功能?(其实它的大致意思我大概是能理解的,就是没发现他是如何在这个问题上用异步的,明明用了异步的装饰器,但是就是没有发现它使如何用异步的)

————————————
注:我理解异步,理解他这个chat的实现思路,只是认为他想做成异步的,但似乎实现异步的过程中是错的,没有用到异步,因为on new message那里虽然用到了异步装饰器,但是没有用到异步。求指出他在具体哪一步释放cpu线程的。对于二楼提出的他构造了一个异步的function的callback,但是callback回调函数不是异步的特有函数,是很平常的函数构造,我没看出他的构造。而我知道把异步的东西分开来构造的是func(args, callback=(yield gen.Callback(key)))
result = yield gen.Wait(key) 虽然说他没有gen,但是他根本没有用到他自己导入的那个tornado.web.asynchronous模块的任何功能。所以说感觉上他就没有实现异步。

其实这个问题的最佳实践方法是websocket,不过我就是觉得除了websocket的另外一个官方的直接不用websocket的代码应该不会有问题,明明用了异步装饰器,但是却没有发现他用到异步的功能。所以疑问。

—————————————
不过可能是我对tornado的理解不够深刻,也许二楼回答的就是对的。先采纳吧。谢谢大家的回答。


鉴于你竟然说到它看上去占用了很多服务器 CPU 资源,那么我假设你其实并不知道异步是什么。

  1. 什么是同步编程?
    举个例子。你去快餐店买快餐,店员问你要什么,然后他等着你回答。你说你要 X、Y、Z,并且付款,然后你等着店员把食物取给你。

  2. 什么是异步编程?
    还是举个例子。你去一餐馆吃饭。服务器过去了,递给你菜单,然后去忙其它事情了。等你们把菜点好,你们通知服务器菜点好了,他们把菜单收过去处理。在这段时间你们可以做其它的事情,聊天啊玩手机之类的。你们看到菜上上来了,于是你们开始就餐。

在网络编程中,与科学计算和数据处理等非常不同的一点是,你没有很多需要大量 CPU 计算的任务,但是你会经常等待用户把请求发过来,以及等待响应发送到用户端

同步编程就是配备很多服务员,每个服务员处理完一个顾客才会去处理下一个顾客的需求。而异步编程,「有事叫我」——

class MessageUpdatesHandler(BaseHandler):
    @tornado.web.authenticated
    @tornado.web.asynchronous
    def post(self):
        cursor = self.get_argument("cursor", None)
        global_message_buffer.wait_for_messages(self.on_new_messages,
                                                cursor=cursor)

    def on_new_messages(self, messages):
        # Closed client connection
        if self.request.connection.stream.closed():
            return
        self.finish(dict(messages=messages))

    def on_connection_close(self):
        global_message_buffer.cancel_wait(self.on_new_messages)

global_message_buffer.wait_for_messages(self.on_new_messages, cursor=cursor) 这句即是说,有消息来了就去调用 self.on_new_messages 函数。没消息的时候程序就做其它的事情去了。比如用户的消息还没来,但是来了一个新的请求,于是程序请处理这个新的请求,直到它结束或者类似地等待某个事件发生。

至于那个 @tornado.web.asynchronous,它的意思是告诉 Tornado 框架,这位服务员会在顾客暂时不需要服务时离开,暂时离开并不代表服务已经完毕(即函数返回时不要认为请求已经完成从而清理之),并且会在请求处理完毕之后告诉 Tornado(即调用 self.finish() 方法)。


我也不是很懂,但是我觉得应该看一下twisted,这个才是tornado的核心


MessageUpdateHandler中定义了on_new_messages这个callback回调函数,客户端请求新数据,服务器会检查cache中是否存有新数据

  • 如果有新数据则利用callback函数获取新数据
  • 如果没有新数据则将callback函数存入到waiters中。

client会通过/a/message/new来发送聊天消息,server收到消息以后会对消息进行封装和处理,然后根据waiters中的等待的客户的callback函数进行数据的返回。

on_new_messages中执行self.finish(dict(messages=messages))。因此真正的请求结束是在执行self.finish以后,而中间一直处于等待新数据的状态。

比如有1万个client, 定时发送/a/message/updates来获取最新的聊天信息数据。服务器接受请求并不处于忙等状态,如果没有新数据也不直接结束请求,而是将每个请求的self.finish()封装成callback函数保存在集合waiters中(之所以用集合是因为client会定时发送获取数据请求,集合能保证用于保存client的callback函数的唯一性)。

当任意client发送一条聊天消息的时候,server会解析并处理该消息,然后获取waiters中的callback集合,遍历执行该1万个callback函数,给client返回数据并结束此次请求。

整个过程中服务器并不在任意请求处理环节中等待获取新数据,因此实现了请求数据处理的异步性。

另外,在授权验证登陆的过程里也做了一些异步操作。@gen.coroutine可以实现模仿同步编程方式的异步编程,替代了原来的@gen.engine,避免写回调函数,使得开发起来更加符合正常逻辑思维。在yield语句之后,ioloop将会注册该事件,等到user返回之后继续执行


您可以先看一下 @tornado.web.asynchronous 这个装饰器。根据 docstring 和源码可以得知,由它装饰过的 post() 函数必须自己负责异步地调用 finish()

有了以上知识,我们可以分析一下这个 MessageUpdatesHandler 了,入口是 post()。第一句:

        cursor = self.get_argument("cursor", None)

是一个简单的阻塞调用,我们并不感兴趣。第二句:

        global_message_buffer.wait_for_messages(self.on_new_messages,
                                                cursor=cursor)

这是比较标准的 Tornado 方式的异步调用——参数里带着一个回调函数(我非 Tornado 长期使用者,结论是根据阅读有限的代码和一些评价得出的)。我们继续跟到这个函数里面去。

    def wait_for_messages(self, callback, cursor=None):
        if cursor:
            new_count = 0
            for msg in reversed(self.cache):
                if msg["id"] == cursor:
                    break
                new_count += 1
            if new_count:
                callback(self.cache[-new_count:])
                return
        self.waiters.add(callback)

这里就是“异步”的关键了。这个方法大部分代码都是在检查这个 buffer 里面有没有足够的数据可以让这次 wait_for_message 直接调用回调函数,如果刚好有数据那就皆大欢喜。

但是如果没有,注意看这个方法将回调函数添加到 self.waiters 队列里之后,就返回了。这就意味着,MessageUpdatesHandler.post() 也会立即返回 None,并且在 Tornado 内部会一直返回到 eventloop ——后者会“释放”CPU,去做循环里的别的事情;而此时这个 HTTP 请求,并没有因为函数的返回而结束,因为还没有人调用 finish()——回忆一下 @asynchronous

此时异步地(在 eventloop 转了许多圈之后),MessageBuffer.new_messages() 会被调用到(就不细分析了),然后会调用到之前放在 waiters 队列里的回调函数——也就是 MessageUpdatesHandler.on_new_messages

    def on_new_messages(self, messages):
        # Closed client connection
        if self.request.connection.stream.closed():
            return
        self.finish(dict(messages=messages))

它调用了 finish(),至此请求完成。

【热门文章】
【热门文章】