Tornado Web框架与异步网络编程库入门

需积分: 16 65 浏览量更新于2024-07-17 1 收藏 869KB PDF 举报

“tornado.pdf”是关于Tornado框架的入门文档，版本为5.0.1。Tornado是一个Python web框架和异步网络库，最初由FriendFeed开发。它利用非阻塞网络I/O技术，能够处理成千上万的开放连接，非常适合长轮询、WebSocket和其他需要与每个用户保持长期连接的应用场景。 Tornado与大多数Python web框架不同，它不基于WSGI，通常在一个进程中只使用一个线程运行。在Tornado的用户指南中，你可以了解更多关于其异步编程的方法。虽然tornado.wsgi模块提供了一些对WSGI的支持，但这不是开发的重点，大多数应用应直接使用Tornado自己的接口（如tornado.web）而不是通过WSGI。一般而言，Tornado的代码不具备线程安全性。唯一可以在其他线程中安全调用的Tornado方法是IOLoop.add_callback。你还可以使用IOLoop.run_in_executor来异步地在另一个线程上运行阻塞函数，但需要注意，传递给run_in_executor的函数应避免引用任何Tornado对象。run_in_executor是推荐与阻塞代码交互的方式。文档内容包括： 1. 快速链接：提供当前版本信息、源代码仓库、邮件列表、StackOverflow讨论区等资源链接。 2. “Hello, world”：基础的Tornado应用程序示例。 3. 线程与WSGI：解释Tornado如何处理线程以及与WSGI的关系。 4. 安装：指导如何安装Tornado框架。 5. 用户指南：详细介绍了Tornado的使用方法，包括Web框架、HTTP服务器和客户端、异步网络编程、协程与并发、与其他服务的集成、实用工具、常见问题解答以及版本发布说明。 6. 讨论和支持：提供了获取帮助和社区支持的途径。 Tornado的特性包括： - 非阻塞网络I/O：允许高效处理大量并发连接。 - 异步编程模型：通过回调、Future或async/await实现协程。 - Web框架：提供路由、请求处理、模板渲染等功能。 - HTTP服务器和客户端：内置HTTP服务和客户端，支持异步操作。 - WebSocket支持：方便构建实时通信应用。 - 长连接支持：适用于需要持续连接的应用场景。 Tornado是一个强大的Python web框架，特别适合需要高性能异步网络操作的场景，如实时应用、高并发服务器等。通过理解和掌握Tornado的这些特性，开发者可以构建出高效的网络应用。

Tornado Documentation, Release 5.0.1

To minimize the cost of concurrent connections, Tornado uses a single-threaded event loop. This means that all

application code should aim to be asynchronous and non-blocking because only one operation can be active at a time.

The terms asynchronous and non-blocking are closely related and are often used interchangeably, but they are not

quite the same thing.

Blocking

A function blocks when it waits for something to happen before returning. A function may block for many reasons:

network I/O, disk I/O, mutexes, etc. In fact, every function blocks, at least a little bit, while it is running and using

the CPU (for an extreme example that demonstrates why CPU blocking must be taken as seriously as other kinds of

blocking, consider password hashing functions like bcrypt, which by design use hundreds of milliseconds of CPU

time, far more than a typical network or disk access).

A function can be blocking in some respects and non-blocking in others. In the context of Tornado we generally talk

about blocking in the context of network I/O, although all kinds of blocking are to be minimized.

Asynchronous

An asynchronous function returns before it is ﬁnished, and generally causes some work to happen in the background

before triggering some future action in the application (as opposed to normal synchronous functions, which do every-

thing they are going to do before returning). There are many styles of asynchronous interfaces:

• Callback argument

• Return a placeholder (Future, Promise, Deferred)

• Deliver to a queue

• Callback registry (e.g. POSIX signals)

Regardless of which type of interface is used, asynchronous functions by deﬁnition interact differently with their

callers; there is no free way to make a synchronous function asynchronous in a way that is transparent to its callers

(systems like gevent use lightweight threads to offer performance comparable to asynchronous systems, but they do

not actually make things asynchronous).

Examples

Here is a sample synchronous function:

from tornado.httpclient import HTTPClient

def synchronous_fetch(url):

http_client = HTTPClient()

response = http_client.fetch(url)

return response.body

And here is the same function rewritten to be asynchronous with a callback argument:

from tornado.httpclient import AsyncHTTPClient

def asynchronous_fetch(url, callback):

http_client = AsyncHTTPClient()

def handle_response(response):

callback(response.body)

http_client.fetch(url, callback=handle_response)

12 Chapter 5. Documentation

Tornado Documentation, Release 5.0.1

And again with a Future instead of a callback:

from tornado.concurrent import Future

def async_fetch_future(url):

http_client = AsyncHTTPClient()

my_future = Future()

fetch_future = http_client.fetch(url)

fetch_future.add_done_callback(

lambda f: my_future.set_result(f.result()))

return my_future

The raw Future version is more complex, but Futures are nonetheless recommended practice in Tornado because

they have two major advantages. Error handling is more consistent since the Future.result method can simply

raise an exception (as opposed to the ad-hoc error handling common in callback-oriented interfaces), and Futures

lend themselves well to use with coroutines. Coroutines will be discussed in depth in the next section of this guide.

Here is the coroutine version of our sample function, which is very similar to the original synchronous version:

from tornado import gen

@gen.coroutine

def fetch_coroutine(url):

http_client = AsyncHTTPClient()

response = yield http_client.fetch(url)

raise gen.Return(response.body)

The statement raise gen.Return(response.body) is an artifact of Python 2, in which generators aren’t

allowed to return values. To overcome this, Tornado coroutines raise a special kind of exception called a Return. The

coroutine catches this exception and treats it like a returned value. In Python 3.3 and later, a return response.

body achieves the same result.

5.1.3 Coroutines

Coroutines are the recommended way to write asynchronous code in Tornado. Coroutines use the Python yield

keyword to suspend and resume execution instead of a chain of callbacks (cooperative lightweight threads as seen

in frameworks like gevent are sometimes called coroutines as well, but in Tornado all coroutines use explicit context

switches and are called as asynchronous functions).

Coroutines are almost as simple as synchronous code, but without the expense of a thread. They also make concurrency

easier to reason about by reducing the number of places where a context switch can happen.

Example:

from tornado import gen

@gen.coroutine

def fetch_coroutine(url):

http_client = AsyncHTTPClient()

response = yield http_client.fetch(url)

# In Python versions prior to 3.3, returning a value from

# a generator is not allowed and you must use

# raise gen.Return(response.body)

# instead.

return response.body

5.1. User’s guide 13

Tornado Documentation, Release 5.0.1

Python 3.5: async and await

Python 3.5 introduces the async and await keywords (functions using these keywords are also called “native corou-

tines”). Starting in Tornado 4.3, you can use them in place of most yield-based coroutines (see the following

paragraphs for limitations). Simply use async def foo() in place of a function deﬁnition with the @gen.

coroutine decorator, and await in place of yield. The rest of this document still uses the yield style for

compatibility with older versions of Python, but async and await will run faster when they are available:

async def fetch_coroutine(url):

http_client = AsyncHTTPClient()

response = await http_client.fetch(url)

return response.body

The await keyword is less versatile than the yield keyword. For example, in a yield-based coroutine you can

yield a list of Futures, while in a native coroutine you must wrap the list in tornado.gen.multi. This also

eliminates the integration with concurrent.futures. You can use tornado.gen.convert_yielded to

convert anything that would work with yield into a form that will work with await:

async def f():

executor = concurrent.futures.ThreadPoolExecutor()

await tornado.gen.convert_yielded(executor.submit(g))

How it works

A function containing yield is a generator. All generators are asynchronous; when called they return a generator

object instead of running to completion. The @gen.coroutine decorator communicates with the generator via the

yield expressions, and with the coroutine’s caller by returning a Future.

Here is a simpliﬁed version of the coroutine decorator’s inner loop:

# Simplified inner loop of tornado.gen.Runner

def run(self):

# send(x) makes the current yield return x.

# It returns when the next yield is reached

future = self.gen.send(self.next)

def callback(f):

self.next = f.result()

self.run()

future.add_done_callback(callback)

The decorator receives a Future from the generator, waits (without blocking) for that Future to complete, then

“unwraps” the Future and sends the result back into the generator as the result of the yield expression. Most

asynchronous code never touches the Future class directly except to immediately pass the Future returned by an

asynchronous function to a yield expression.

How to call a coroutine

Coroutines do not raise exceptions in the normal way: any exception they raise will be trapped in the Future until it

is yielded. This means it is important to call coroutines in the right way, or you may have errors that go unnoticed:

@gen.coroutine

def divide(x, y):

return x / y

def bad_call():

14 Chapter 5. Documentation

Tornado Documentation, Release 5.0.1

# This should raise a ZeroDivisionError, but it won't because

# the coroutine is called incorrectly.

divide(1, 0)

In nearly all cases, any function that calls a coroutine must be a coroutine itself, and use the yield keyword in the

call. When you are overriding a method deﬁned in a superclass, consult the documentation to see if coroutines are

allowed (the documentation should say that the method “may be a coroutine” or “may return a Future”):

@gen.coroutine

def good_call():

# yield will unwrap the Future returned by divide() and raise

# the exception.

yield divide(1, 0)

Sometimes you may want to “ﬁre and forget” a coroutine without waiting for its result. In this case it is recommended

to use IOLoop.spawn_callback, which makes the IOLoop responsible for the call. If it fails, the IOLoop will

log a stack trace:

# The IOLoop will catch the exception and print a stack trace in

# the logs. Note that this doesn't look like a normal call, since

# we pass the function object to be called by the IOLoop.

IOLoop.current().spawn_callback(divide, 1, 0)

Using IOLoop.spawn_callback in this way is recommended for functions using @gen.coroutine, but it is

required for functions using async def (otherwise the coroutine runner will not start).

Finally, at the top level of a program, if the IOLoop is not yet running, you can start the IOLoop, run the coroutine,

and then stop the IOLoop with the IOLoop.run_sync method. This is often used to start the main function of a

batch-oriented program:

# run_sync() doesn't take arguments, so we must wrap the

# call in a lambda.

IOLoop.current().run_sync(lambda: divide(1, 0))

Coroutine patterns

Calling blocking functions

The simplest way to call a blocking function from a coroutine is to use IOLoop.run_in_executor, which returns

Futures that are compatible with coroutines:

@gen.coroutine

def call_blocking():

yield IOLoop.current().run_in_executor(blocking_func, args)

Parallelism

The coroutine decorator recognizes lists and dicts whose values are Futures, and waits for all of those Futures

in parallel:

@gen.coroutine

def parallel_fetch(url1, url2):

resp1, resp2 = yield [http_client.fetch(url1),

5.1. User’s guide 15

剩余233页未读，继续阅读

就这样吧_me

粉丝: 1
资源: 5

Tornado Web框架与异步网络编程库入门

最新资源