python怎麼設置非同步模塊

⑴ 「2022 年」崔慶才 python3 爬蟲教程 - 代理的使用方法

前面我們介紹了多種請求庫，如 urllib、requests、Selenium、Playwright 等用法，但是沒有統一梳理代理的設置方法，本節我們來針對這些庫來梳理下代理的設置方法。

在本節開始之前，請先根據上一節了解一下代理的基本原理，了解了基本原理之後我們可以更好地理解和學習本節的內容。

另外我們需要先獲取一個可用代理，代理就是 IP 地址和埠的組合，就是 : 這樣的格式。如果代理需要訪問認證，那就還需要額外的用戶名密碼兩個信息。

那怎麼獲取一個可用代理呢？

使用搜索引擎搜索 「代理」 關鍵字，可以看到許多代理服務網站，網站上會有很多免費或付費代理，比如快代理的免費 HTTP 代理：https://www.kuaidaili.com/free/ 上面就寫了很多免費代理，但是這些免費代理大多數情況下並不一定穩定，所以比較靠譜的方法是購買付費代理。付費代理的各大代理商家都有套餐，數量不用多，穩定可用即可，我們可以自行選購。

另外除了購買付費 HTTP 代理，我們也可以在本機配置一些代理軟體，具體的配置方法可以參考 https://setup.scrape.center/proxy-client，軟體運行之後會在本機創建 HTTP 或 SOCKS 代理服務，所以代理地址一般都是 127.0.0.1: 這樣的格式，不同的軟體用的埠可能不同。

這里我的本機安裝了一部代理軟體，它會在本地 7890 埠上創建 HTTP 代理服務，即代理為 127.0.0.1:7890。另外，該軟體還會在 7891 埠上創建 SOCKS 代理服務，即代理為 127.0.0.1:7891，所以只要設置了這個代理，就可以成功將本機 IP 切換到代理軟體連接的伺服器的 IP 了。

在本章下面的示例里，我使用上述代理來演示其設置方法，你也可以自行替換成自己的可用代理。

設置代理後，測試的網址是 http://httpbin.org/get，訪問該鏈接我們可以得到請求的相關信息，其中返回結果的 origin 欄位就是客戶端的 IP，我們可以根據它來判斷代理是否設置成功，即是否成功偽裝了 IP。

好，接下來我們就來看下各個請求庫的代理設置方法吧。

首先我們以最基礎的 urllib 為例，來看一下代理的設置方法，代碼如下：

運行結果如下：

這里我們需要藉助 ProxyHandler 設置代理，參數是字典類型，鍵名為協議類型，鍵值是代理。注意，此處代理前面需要加上協議，即 http:// 或者 https://，當請求的鏈接是 HTTP 協議的時候，會使用 http 鍵名對應的代理，當請求的鏈接是 HTTPS 協議的時候，會使用 https 鍵名對應的代理。不過這里我們把代理本身設置為了 HTTP 協議，即前綴統一設置為了 http://，所以不論訪問 HTTP 還是 HTTPS 協議的鏈接，都會使用我們配置的 HTTP 協議的代理進行請求。

創建完 ProxyHandler 對象之後，我們需要利用 build_opener 方法傳入該對象來創建一個 Opener，這樣就相當於此 Opener 已經設置好代理了。接下來直接調用 Opener 對象的 open 方法，即可訪問我們所想要的鏈接。

運行輸出結果是一個 JSON，它有一個欄位 origin，標明了客戶端的 IP。驗證一下，此處的 IP 確實為代理的 IP，並不是真實的 IP。這樣我們就成功設置好代理，並可以隱藏真實 IP 了。

如果遇到需要認證的代理，我們可以用如下的方法設置：

這里改變的只是 proxy 變數，只需要在代理前面加入代理認證的用戶名密碼即可，其中 username 就是用戶名，password 為密碼，例如 username 為 foo，密碼為 bar，那麼代理就是 foo:[email protected]:7890。

如果代理是 SOCKS5 類型，那麼可以用如下方式設置代理：

此處需要一個 socks 模塊，可以通過如下命令安裝：

這里需要本地運行一個 SOCKS5 代理，運行在 7891 埠，運行成功之後和上文 HTTP 代理輸出結果是一樣的：

結果的 origin 欄位同樣為代理的 IP，代理設置成功。

對於 requests 來說，代理設置非常簡單，我們只需要傳入 proxies 參數即可。

這里以我本機的代理為例，來看下 requests 的 HTTP 代理設置，代碼如下：

運行結果如下：

和 urllib 一樣，當請求的鏈接是 HTTP 協議的時候，會使用 http 鍵名對應的代理，當請求的鏈接是 HTTPS 協議的時候，會使用 https 鍵名對應的代理，不過這里統一使用了 HTTP 協議的代理。

運行結果中的 origin 若是代理伺服器的 IP，則證明代理已經設置成功。

如果代理需要認證，那麼在代理的前面加上用戶名和密碼即可，代理的寫法就變成如下所示：

這里只需要將 username 和 password 替換即可。

如果需要使用 SOCKS 代理，則可以使用如下方式來設置：

這里我們需要額外安裝一個包 requests[socks]，相關命令如下所示：

運行結果是完全相同的：

另外，還有一種設置方式，即使用 socks 模塊，也需要像上文一樣安裝 socks 庫。這種設置方法如下所示：

使用這種方法也可以設置 SOCKS 代理，運行結果完全相同。相比第一種方法，此方法是全局設置的。我們可以在不同情況下選用不同的方法。

httpx 的用法本身就與 requests 的使用非常相似，所以其也是通過 proxies 參數來設置代理的，不過與 requests 不同的是，proxies 參數的鍵名不能再是 http 或 https，而需要更改為 http:// 或 https://，其他的設置是一樣的。

對於 HTTP 代理來說，設置方法如下：

對於需要認證的代理，也是改下 proxy 的值即可：

這里只需要將 username 和 password 替換即可。

運行結果和使用 requests 是類似的，結果如下：

對於 SOCKS 代理，我們需要安裝 httpx-socks 庫，安裝方法如下：

這樣會同時安裝同步和非同步兩種模式的支持。

對於同步模式，設置方法如下：

對於非同步模式，設置方法如下：

和同步模式不同的是，transport 對象我們用的是 AsyncProxyTransport 而不是 SyncProxyTransport，同時需要將 Client 對象更改為 AsyncClient 對象，其他的不變，運行結果是一樣的。

Selenium 同樣可以設置代理，這里以 Chrome 為例來介紹其設置方法。

對於無認證的代理，設置方法如下：

運行結果如下：

代理設置成功，origin 同樣為代理 IP 的地址。

如果代理是認證代理，則設置方法相對比較繁瑣，具體如下所示：

這里需要在本地創建一個 manifest.json 配置文件和 background.js 腳本來設置認證代理。運行代碼之後，本地會生成一個 proxy_auth_plugin.zip 文件來保存當前配置。

運行結果和上例一致，origin 同樣為代理 IP。

SOCKS 代理的設置也比較簡單，把對應的協議修改為 socks5 即可，如無密碼認證的代理設置方法為：

運行結果是一樣的。

對於 aiohttp 來說，我們可以通過 proxy 參數直接設置。HTTP 代理設置如下：

如果代理有用戶名和密碼，像 requests 一樣，把 proxy 修改為如下內容：

這里只需要將 username 和 password 替換即可。

對於 SOCKS 代理，我們需要安裝一個支持庫 aiohttp-socks，其安裝命令如下：

我們可以藉助於這個庫的 ProxyConnector 來設置 SOCKS 代理，其代碼如下：

運行結果是一樣的。

另外，這個庫還支持設置 SOCKS4、HTTP 代理以及對應的代理認證，可以參考其官方介紹。

對於 Pyppeteer 來說，由於其默認使用的是類似 Chrome 的 Chromium 瀏覽器，因此其設置方法和 Selenium 的 Chrome 一樣，如 HTTP 無認證代理設置方法都是通過 args 來設置的，實現如下：

運行結果如下：

同樣可以看到設置成功。

SOCKS 代理也一樣，只需要將協議修改為 socks5 即可，代碼實現如下：

運行結果也是一樣的。

相對 Selenium 和 Pyppeteer 來說，Playwright 的代理設置更加方便，其預留了一個 proxy 參數，可以在啟動 Playwright 的時候設置。

對於 HTTP 代理來說，可以這樣設置：

在調用 launch 方法的時候，我們可以傳一個 proxy 參數，是一個字典。字典有一個必填的欄位叫做 server，這里我們可以直接填寫 HTTP 代理的地址即可。

運行結果如下：

對於 SOCKS 代理，設置方法也是完全一樣的，我們只需要把 server 欄位的值換成 SOCKS 代理的地址即可：

運行結果和剛才也是完全一樣的。

對於有用戶名和密碼的代理，Playwright 的設置也非常簡單，我們只需要在 proxy 參數額外設置 username 和 password 欄位即可，假如用戶名和密碼分別是 foo 和 bar，則設置方法如下：

這樣我們就能非常方便地為 Playwright 實現認證代理的設置。

以上我們就總結了各個請求庫的代理使用方式，各種庫的設置方法大同小異，學會了這些方法之後，以後如果遇到封 IP 的問題，我們可以輕鬆通過加代理的方式來解決。

本節代碼：https://github.com/Python3WebSpider/ProxyTest

⑵ python非同步有哪些方式

yield相當於return，他將相應的值返回給調用next()或者send()的調用者，從而交出了CPU使用權，而當調用者再次調用next()或者send()的時候，又會返回到yield中斷的地方，如果send有參數，還會將參數返回給yield賦值的變數,如果沒有就和next（）一樣賦值為None。但是這里會遇到一個問題，就是嵌套使用generator時外層的generator需要寫大量代碼，看如下示例：
注意以下代碼均在Python3.6上運行調試

#!/usr/bin/env python# encoding:utf-8def inner_generator():
i = 0
while True:
i = yield i if i > 10: raise StopIterationdef outer_generator():
print("do something before yield")
from_inner = 0
from_outer = 1
g = inner_generator()
g.send(None) while 1: try:
from_inner = g.send(from_outer)
from_outer = yield from_inner except StopIteration: breakdef main():
g = outer_generator()
g.send(None)
i = 0
while 1: try:
i = g.send(i + 1)
print(i) except StopIteration: breakif __name__ == '__main__':
main()041

為了簡化，在Python3.3中引入了yield from

yield from

使用yield from有兩個好處，

1、可以將main中send的參數一直返回給最里層的generator，
2、同時我們也不需要再使用while循環和send (), next()來進行迭代。

我們可以將上邊的代碼修改如下：

def inner_generator():
i = 0
while True:
i = yield i if i > 10: raise StopIterationdef outer_generator():
print("do something before coroutine start") yield from inner_generator()def main():
g = outer_generator()
g.send(None)
i = 0
while 1: try:
i = g.send(i + 1)
print(i) except StopIteration: breakif __name__ == '__main__':
main()

執行結果如下：

do something before coroutine start123456789101234567891011

這里inner_generator()中執行的代碼片段我們實際就可以認為是協程，所以總的來說邏輯圖如下：

我們都知道Python由於GIL(Global Interpreter Lock)原因，其線程效率並不高，並且在*nix系統中，創建線程的開銷並不比進程小，因此在並發操作時，多線程的效率還是受到了很大制約的。所以後來人們發現通過yield來中斷代碼片段的執行，同時交出了cpu的使用權，於是協程的概念產生了。在Python3.4正式引入了協程的概念，代碼示例如下：

import asyncio# Borrowed from http://curio.readthedocs.org/en/latest/[email protected] countdown(number, n):
while n > 0:
print('T-minus', n, '({})'.format(number)) yield from asyncio.sleep(1)
n -= 1loop = asyncio.get_event_loop()
tasks = [
asyncio.ensure_future(countdown("A", 2)),
asyncio.ensure_future(countdown("B", 3))]
loop.run_until_complete(asyncio.wait(tasks))
loop.close()12345678910111213141516

示例顯示了在Python3.4引入兩個重要概念協程和事件循環，
通過修飾符@asyncio.coroutine定義了一個協程，而通過event loop來執行tasks中所有的協程任務。之後在Python3.5引入了新的async & await語法，從而有了原生協程的概念。

async & await

在Python3.5中，引入了aync&await 語法結構，通過」aync def」可以定義一個協程代碼片段，作用類似於Python3.4中的@asyncio.coroutine修飾符，而await則相當於」yield from」。

先來看一段代碼，這個是我剛開始使用async&await語法時，寫的一段小程序。

#!/usr/bin/env python# encoding:utf-8import asyncioimport requestsimport time


async def wait_download(url):
response = await requets.get(url)
print("get {} response complete.".format(url))


async def main():
start = time.time()
await asyncio.wait([
wait_download("http://www.163.com"),
wait_download("http://www.mi.com"),
wait_download("http://www.google.com")])
end = time.time()
print("Complete in {} seconds".format(end - start))


loop = asyncio.get_event_loop()
loop.run_until_complete(main())

這里會收到這樣的報錯：

Task exception was never retrieved
future: <Task finished coro=<wait_download() done, defined at asynctest.py:9> exception=TypeError("object Response can't be used in 'await' expression",)>
Traceback (most recent call last):
File "asynctest.py", line 10, in wait_download
data = await requests.get(url)
TypeError: object Response can't be used in 'await' expression123456

這是由於requests.get()函數返回的Response對象不能用於await表達式，可是如果不能用於await，還怎麼樣來實現非同步呢？
原來Python的await表達式是類似於」yield from」的東西，但是await會去做參數檢查，它要求await表達式中的對象必須是awaitable的，那啥是awaitable呢？ awaitable對象必須滿足如下條件中其中之一：

1、A native coroutine object returned from a native coroutine function .

原生協程對象

2、A generator-based coroutine object returned from a function decorated with types.coroutine() .

types.coroutine()修飾的基於生成器的協程對象，注意不是Python3.4中asyncio.coroutine

3、An object with an await method returning an iterator.

實現了await method，並在其中返回了iterator的對象

根據這些條件定義，我們可以修改代碼如下：

#!/usr/bin/env python# encoding:utf-8import asyncioimport requestsimport time


async def download(url): # 通過async def定義的函數是原生的協程對象
response = requests.get(url)
print(response.text)


async def wait_download(url):
await download(url) # 這里download(url)就是一個原生的協程對象
print("get {} data complete.".format(url))


async def main():
start = time.time()
await asyncio.wait([
wait_download("http://www.163.com"),
wait_download("http://www.mi.com"),
wait_download("http://www.google.com")])
end = time.time()
print("Complete in {} seconds".format(end - start))


loop = asyncio.get_event_loop()
loop.run_until_complete(main())27282930

好了現在一個真正的實現了非同步編程的小程序終於誕生了。
而目前更牛逼的非同步是使用uvloop或者pyuv，這兩個最新的Python庫都是libuv實現的，可以提供更加高效的event loop。

uvloop和pyuv

pyuv實現了Python2.x和3.x，但是該項目在github上已經許久沒有更新了，不知道是否還有人在維護。
uvloop只實現了3.x, 但是該項目在github上始終活躍。

它們的使用也非常簡單，以uvloop為例，只需要添加以下代碼就可以了

import asyncioimport uvloop
asyncio.set_event_loop_policy(uvloop.EventLoopPolicy())123

⑶ Python（七十二）多任務非同步協程

11_lxml/01_線程池的基本使用.py：

11_lxml/02_非同步.py：

11_多任務非同步協程/03_多任務非同步.py：

11_多任務非同步協程/04_flask服務.py：

11_多任務非同步協程/04_多任務非同步協程.py：

11_多任務非同步協程/05_aiohttp實現.py：（需與11_多任務非同步協程/05_aiohttp實現.py連用）

文章到這里就結束了！希望大家能多多支持Python（系列）！六個月帶大家學會Python，私聊我，可以問關於本文章的問題！以後每天都會發布新的文章，喜歡的點點關注！一個陪伴你學習Python的新青年！不管多忙都會更新下去，一起加油！

Editor：Lonelyroots

⑷ Python 非同步任務隊列Celery 使用

在 Python 中定義 Celery 的時候，我們要引入 Broker，中文翻譯過來就是「中間人」的意思。在工頭(生產者)提出任務的時候，把所有的任務放到 Broker 裡面，在 Broker 的另外一頭，一群碼農(消費者)等著取出一個個任務准備著手做。這種模式註定了整個系統會是個開環系統，工頭對於碼農們把任務做的怎樣是不知情的。所以我們要引入 Backend 來保存每次任務的結果。這個 Backend 也是存儲任務的信息用的，只不過這里存的是那些任務的返回結果。我們可以選擇只讓錯誤執行的任務返回結果到 Backend，這樣我們取回結果，便可以知道有多少任務執行失敗了。

其實現架構如下圖所示：

可以看到，Celery 主要包含以下幾個模塊：

celery可以通過pip自動安裝。

broker 可選擇使用RabbitMQ/redis，backend可選擇使用RabbitMQ/redis/MongoDB。RabbitMQ/redis/mongoDB的安裝請參考對應的官方文檔。

------------------------------rabbitmq相關----------------------------------------------------------

官網安裝方法： http://www.rabbitmq.com/install-windows.html

啟動管理插件：sbin/rabbitmq-plugins enable rabbitmq_management 啟動rabbitmq：sbin/rabbitmq-server -detached

rabbitmq已經啟動，可以打開頁面來看看 地址： http://localhost:15672/#/

用戶名密碼都是guest 。進入可以看到具體頁面。 關於rabbitmq的配置，網上很多 自己去搜以下就ok了。

------------------------------rabbitmq相關--------------------------------------------------------

項目結構如下：

使用前，需要三個方面：celery配置，celery實例，需執行的任務函數，如下：

Celery 的配置比較多，可以在 官方配置文檔： http://docs.celeryproject.org/en/latest/userguide/configuration.html 查詢每個配置項的含義。

當然，要保證上述非同步任務and下述定時任務都能正常執行，就需要先啟動celery worker，啟動命令行如下:

需 啟動beat ，執行定時任務時, Celery會通過celery beat進程來完成。Celery beat會保持運行, 一旦到了某一定時任務需要執行時, Celery beat便將其加入到queue中. 不像worker進程, Celery beat只需要一個即可。而且為了避免有重復的任務被發送出去，所以Celery beat僅能有一個。

命令行啟動：

如果你想將celery worker/beat要放到後台運行，推薦可以扔給supervisor。

supervisor.conf如下：

⑸ python 非同步是什麼意思

非同步是計算機多線程的非同步處理。與同步處理相對，非同步處理不用阻塞當前線程來等待處理完成，而是允許後續操作，直至其它線程將處理完成，並回調通知此線程。

⑹ python 非同步請求的時候怎麼添加代理

有幾種方法。一種是設置環境變數http_proxy，它會自動訪問這個。 另外一種是你使用urllib2的時候，在參數里加上代理。還有一個是urllib上指定。

比如
import urllib
urllib.urlopen(某網站，proxyes={'http:':"某代理IP地址:代理的埠"})

使用QT時，它的瀏覽器設置代理要在瀏覽器初始化參數里指定。

⑺ python2.7怎麼實現非同步

改進之前
之前，我的查詢步驟很簡單，就是：
前端提交查詢請求 --> 建立資料庫連接 --> 新建游標 --> 執行命令 --> 接受結果 --> 關閉游標、連接
這幾大步驟的順序執行。
這裡面當然問題很大：
建立資料庫連接實際上就是新建一個套接字。這是進程間通信的幾種方法里，開銷最大的了。
在「執行命令」和「接受結果」兩個步驟中，線程在阻塞在資料庫內部的運行過程中，資料庫連接和游標都處於閑置狀態。
這樣一來，每一次查詢都要順序的新建資料庫連接，都要阻塞在資料庫返回結果的過程中。當前端提交大量查詢請求時，查詢效率肯定是很低的。
第一次改進
之前的模塊里，問題最大的就是第一步——建立資料庫連接套接字了。如果能夠一次性建立連接，之後查詢能夠反復服用這個連接就好了。
所以，首先應該把資料庫查詢模塊作為一個單獨的守護進程去執行，而前端app作為主進程響應用戶的點擊操作。那麼兩條進程怎麼傳遞消息呢？翻了幾天Python文檔，終於構思出來：用隊列queue作為生產者（web前端）向消費者（資料庫後端）傳遞任務的渠道。生產者，會與SQL命令一起，同時傳遞一個管道pipe的連接對象，作為任務完成後，回傳結果的渠道。確保，任務的接收方與發送方保持一致。
作為第二個問題的解決方法，可以使用線程池來並發獲取任務隊列中的task，然後執行命令並回傳結果。
第二次改進
第一次改進的效果還是很明顯的，不用任何測試手段。直接點擊頁面鏈接，可以很直觀地感覺到反應速度有很明顯的加快。
但是對於第二個問題，使用線程池還是有些欠妥當。因為，CPython解釋器存在GIL問題，所有線程實際上都在一個解釋器進程里調度。線程稍微開多一點，解釋器進程就會頻繁的切換線程，而線程切換的開銷也不小。線程多一點，甚至會出現「抖動」問題（也就是剛剛喚醒一個線程，就進入掛起狀態，剛剛換到棧幀或內存的上下文，又被換回內存或者磁碟），效率大大降低。也就是說，線程池的並發量很有限。
試過了多進程、多線程，只能在單個線程里做文章了。
Python中的asyncio庫
Python里有大量的協程庫可以實現單線程內的並發操作，比如Twisted、Gevent等等。Python官方在3.5版本里提供了asyncio庫同樣可以實現協程並發。asyncio庫大大降低了Python中協程的實現難度，就像定義普通函數那樣就可以了，只是要在def前面多加一個async關鍵詞。async def函數中，需要阻塞在其他async def函數的位置前面可以加上await關鍵詞。
import asyncio
async def wait():
await asyncio.sleep(2)
async def execute(task):
process_task(task)
await wait()
continue_job()
async def函數的執行稍微麻煩點。需要首先獲取一個loop對象，然後由這個對象代為執行async def函數。
loop = asyncio.get_event_loop()
loop.run_until_complete(execute(task))
loop.close()
loop在執行execute(task)函數時，如果遇到await關鍵字，就會暫時掛起當前協程，轉而去執行其他阻塞在await關鍵詞的協程，從而實現協程並發。
不過需要注意的是，run_until_complete()函數本身是一個阻塞函數。也就是說，當前線程會等候一個run_until_complete()函數執行完畢之後，才會繼續執行下一部函數。所以下面這段代碼並不能並發執行。
for task in task_list:
loop.run_until_complete(task)
對與這個問題，asyncio庫也有相應的解決方案：gather函數。
loop = asyncio.get_event_loop()
tasks = [asyncio.ensure_future(execute(task))
for task in task_list]
loop.run_until_complete(asyncio.gather(*tasks))
loop.close()
當然了，async def函數的執行並不只有這兩種解決方案，還有call_soon與run_forever的配合執行等等，更多內容還請參考官方文檔。
Python下的I/O多路復用
協程，實際上，也存在上下文切換，只不過開銷很輕微。而I/O多路復用則完全不存在這個問題。
目前，Linux上比較火的I/O多路復用API要算epoll了。Tornado，就是通過調用C語言封裝的epoll庫，成功解決了C10K問題（當然還有Pypy的功勞）。
在Linux里查文檔，可以看到epoll只有三類函數，調用起來比較方便易懂。
創建epoll對象，並返回其對應的文件描述符（file descriptor）。
int epoll_create(int size);
int epoll_create1(int flags);
控制監聽事件。第一個參數epfd就對應於前面命令創建的epoll對象的文件描述符；第二個參數表示該命令要執行的動作：監聽事件的新增、修改或者刪除；第三個參數，是要監聽的文件對應的描述符；第四個，代表要監聽的事件。
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
等候。這是一個阻塞函數，調用者會等候內核通知所注冊的事件被觸發。
int epoll_wait(int epfd, struct epoll_event *events,
int maxevents, int timeout);
int epoll_pwait(int epfd, struct epoll_event *events,
int maxevents, int timeout,
const sigset_t *sigmask);
在Python的select庫里：
select.epoll()對應於第一類創建函數；
epoll.register()，epoll.unregister()，epoll.modify()均是對控制函數epoll_ctl的封裝；
epoll.poll()則是對等候函數epoll_wait的封裝。
Python里epoll相關API的最大問題應該是在epoll.poll()。相比於其所封裝的epoll_wait，用戶無法手動指定要等候的事件，也就是後者的第二個參數struct epoll_event *events。沒法實現精確控制。因此只能使用替代方案：select.select()函數。
根據Python官方文檔，select.select(rlist, wlist, xlist[, timeout])是對Unix系統中select函數的直接調用，與C語言API的傳參很接近。前三個參數都是列表，其中的元素都是要注冊到內核的文件描述符。如果想用自定義類，就要確保實現了fileno()方法。
其分別對應於：
rlist: 等候直到可讀
wlist: 等候直到可寫
xlist: 等候直到異常。這個異常的定義，要查看系統文檔。
select.select()，類似於epoll.poll()，先注冊文件和事件，然後保持等候內核通知，是阻塞函數。
實際應用
Psycopg2庫支持對非同步和協程，但和一般情況下的用法略有區別。普通資料庫連接支持不同線程中的不同游標並發查詢；而非同步連接則不支持不同游標的同時查詢。所以非同步連接的不同游標之間必須使用I/O復用方法來協調調度。
所以，我的大致實現思路是這樣的：首先並發執行大量協程，從任務隊列中提取任務，再向連接池請求連接，創建游標，然後執行命令，並返回結果。在獲取游標和接受查詢結果之前，均要阻塞等候內核通知連接可用。
其中，連接池返回連接時，會根據引用連接的協程數量，返回負載最輕的連接。這也是自己定義AsyncConnectionPool類的目的。
我的代碼位於：bottle-blog/dbservice.py
存在問題
當然了，這個流程目前還一些問題。
首先就是每次輪詢拿到任務之後，都會走這么一個流程。
獲取連接 --> 新建游標 --> 執行任務 --> 關閉游標 --> 取消連接引用
本來，最好的情況應該是：在輪詢之前，就建好游標；在輪詢時，直接等候內核通知，執行相應任務。這樣可以減少輪詢時的任務量。但是如果協程提前對應好連接，那就不能保證在獲取任務時，保持各連接負載均衡了。
所以這一塊，還有工作要做。
還有就是epoll沒能用上，有些遺憾。
以後打算寫點C語言的內容，或者用Python/C API，或者用Ctypes包裝共享庫，來實現epoll的調用。
最後，請允許我吐槽一下Python的epoll相關文檔：簡直太弱了！！！必須看源碼才能弄清楚功能。