python原生非同步

Ⅰ 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相關文檔：簡直太弱了！！！必須看源碼才能弄清楚功能。

Ⅱ 用python怎樣實現非同步redis客戶端

題主的問題里，訪問redis的瓶頸在於網路IO開銷太大，跟不上cpu的計算速度。有幾個辦法，題主可以考慮一下，大前提：cpu計算的數據，前後沒什麼關聯，否則只能用同步方式。
1. 內建多個queue，將需要寫回redis的數據，另起多線程（與queue一對一）處理。
2. 使用pipeline方式讀寫redis，減少網路交互開銷。

Ⅲ 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 非同步任務隊列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爬蟲中的非同步載入

'''
Created on 2012-3-31

@author: TQS
''' json
from BeautifulSoup import BeautifulSoup

START_URL = "http://www.17u.cn/SearchList_53_0_0_0__0__0_0_0___0_"
END_URL = "_0___0.html"
ROOT_URL = "http://www.17u.cn"
AJAX_URL = "http://www.17u.cn/Hotel/ajax/HotelAjaxCall.aspx?action=getpichotel&hotelId=%s&pictype=0&Page=%s&r=0.5"

start_queue = Queue.Queue()
out_queue = Queue.Queue()def addRootPart(item):
return ROOT_URL + item

def getBaseUrls():
hosts = [START_URL+str(num)+END_URL for num inrange(1,135)]return hosts

def getHotelUrls():
content = urllib2.urlopen('http://www.17u.cn/SearchList_53_0_0_0__0__0_0_0___0_1_0___0.html').read()
soup = BeautifulSoup(content)
hotellist = soup.find(id="hotellist_info").findAll("h3")
hotelurls = [ROOT_URL + item.a["href"]for item in hotellist]return hotelurls

def getDetails():
content = urllib2.urlopen('http://www.17u.cn/HotelInfo-19940.html').read()
soup = BeautifulSoup(content)
address = soup.find(id="div_info").findAll("dl")[1].find("局笑dd").text
name = soup.find(id="C_Deatl1_div_content"枝臘基).h1.text
photourl = ROOT_URL + soup.find(id="comImgList").find("a")['href']print address,name,photourl

def getPhotoFromJson(hotelid,page):
jsonurl = AJAX_URL %(hotelid,page)
content = urllib2.urlopen(jsonurl).read()
jsondata = json.loads(content)return[item["Url"]for item in jsondata["Image"]]def getPhotos():
content = urllib2.urlopen('http://www.17u.cn/HotelPicInfo-10218.html').read()
soup = BeautifulSoup(content)
hotelid = soup.find(id="txt_HotelId")['value'猛謹]"""the num of the pages"""
pages = soup.find(id='totalPage')['value']for num inrange(1,int(pages)+1):
getPhotoFromJson(str(hotelid),str(num))if __name__ == "__main__":
getPhotos()

Ⅵ Python非同步編程7：非同步迭代器

迭代器：在其內部實現yield方法和next方法的對象。可迭代對象：在類內部實現一個iter方法，並返回一個迭代器。

非同步迭代器：實現了__aiter__()和__anext__()方法的對象，必須返回一個awaitable對象。async_for支持處理非同步迭代器的

__anext__()方法返回的可等待對象，直到引發一個stopAsyncIteration異常，這個改動由PEP 492引入。

非同步可迭代對象：可在async_for語句中被使用的對象，必須通過它的__aiter__()方法返回一個asynchronous_iterator（非同步迭代器）.  這個改動由PEP 492引入。

示例： 不能直接寫在普通方法或者暴露在外面。必須寫在協程函數，任意協程函數均可。

Ⅶ python 非同步是什麼意思

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

Ⅷ 如何用python簡單的設計開發非同步任務調度隊列

首先，客戶端可以直接扔任務到一個web services的介面上 –》 web api接收到任務後，會根據客戶端的ip和時間戳做task_id,返回給客戶，緊接著在redis裡面標記這任務的狀態。 格式為 func,args,kwargs,timeout=xx,queue_level=xx,interval_time=xx
主服務端:
一個線程，會不停的掃描那個redis hash表，取出任務的interval_time後，進行取模，如果匹配成功，就會塞到 redis sorted set有續集和裡面。
主線程，會不停的看看sorted set裡面，有沒有比自己實現小的任務，有的話，執行並刪除。 這里的執行是用多進程，為毛用多進程，因為線程很多時候是不好控制強制幹掉的。 每個任務都會用multiprocessing的方式去執行，去調用的時候，會多傳進一個task_id，用來把相關的進度推送到redis裡面。 另外，fork進程後，我會得到一個pid，我會把pid和timeout的信息，存放到kill_hash裡面。 然後會不間斷的查看，在指定的timeout內，這pid還在不在，如果還是存在，沒有退出的話，說明他的任務不太正常，我們就可以在main()，裡面幹掉這些任務。
所謂的優先順序就是個 High + middle +Low 的三合一鏈條而已，我每次都會堅持從高到低取任務，如果你的High級別的任務不斷的話，那麼我會一直幹不了低級別的任務了。 代碼的體現是在redis sorted set這邊，設立三個有序集合，我的worker隊列會從high開始做……
那麼如果想幹掉一個任務是如何操作的，首先我需要在 kill_hash 裡面標記任務應該趕緊幹掉，在就是在task_hash裡面把那個task_id幹掉，好讓他不會被持續的加入待執行的隊列裡面。