前不久參加了個Opnstack的Meetup，其中有一個來自EasyStack的大大就Nova中的協(xié)同并發(fā)做了一番講解，有所感觸，本想當(dāng)天就總結(jié)一下，但是由于前段時間工作上比較忙，加上為了履行諾言每天幾更的來寫設(shè)計模式系列性文章，故而拖到今天才寫此次的總結(jié)。好吧，其實歸根結(jié)底還是自己太懶了，趁著閑時在補(bǔ)新番小籠包之類的。廢話就此打住，開始正文。

Python中協(xié)程的介紹

在此之前，先介紹下Python中的并發(fā)，在Python中，并發(fā)有三種，分別是：

進(jìn)程：Python中一般使用multiprocessing/subprocess來實現(xiàn)

線程：threading/thread是Python中用來實現(xiàn)多線程的模塊

協(xié)程(Coroutines)：Python中用于處理協(xié)程的模塊倒是比較多，有eventlet、Twisted、Tulip、asyncio

有關(guān)進(jìn)程、協(xié)程、線程中的關(guān)系圖如下所示(圖來自EasyStack的大大)：

想必大家對進(jìn)程以及線程那是相當(dāng)?shù)氖煜ち?，所以就重點介紹下協(xié)程：協(xié)程源自 Simula 和 Modula-2 語言，但也有其他語言支持。協(xié)程更適合于用來實現(xiàn)彼此熟悉的程序組件，如合作式多任務(wù)，迭代器，無限列表和管道。 協(xié)程最初在1963年被提出。那么協(xié)程又有什么特點呢?

每個協(xié)程都有自己的私有stack以及局部變量。

線程我們都知道可以多個同時運(yùn)行，也就是所謂的多線程，但是同一時間只有一個協(xié)程在運(yùn)行，所以就無須對某些共享變量加鎖。

由于協(xié)程比較輕量級，所以一個線程中可以有多個協(xié)程。

協(xié)程之間的執(zhí)行順序，完全由程序來控制。

其實協(xié)程也就僅僅是一種概念罷了，非操作系統(tǒng)可見，在多種語言中都有實現(xiàn)，一會詳細(xì)介紹的eventlet就是在Python中實現(xiàn)的一種。

Eventlet的介紹

eventlet其實就是對greenlet的一個封裝，對其進(jìn)行簡單的封裝之后，就成了所謂的greenthread，greenlet是一個稱為協(xié)程(coroutine)的東西。下面上一個greenlet的例子來介紹一下greenlet：

1from greenletimportgreenlet23def test1:4print 125gr2.switch6print 3478def test2:9print 5610gr1.switch11print 781213gr1 =greenlet(test1)14gr2 =greenlet(test2)15gr1.switch 

執(zhí)行結(jié)果是：

也就是說在這里先定義了兩個函數(shù)test1,test2以及兩個協(xié)程gr1,gr2，***一行g(shù)1.switch跳轉(zhuǎn)到 test1 ，它打印12，然后執(zhí)行g(shù)r2.switch，跳轉(zhuǎn)到 test2 ，打印56，然后又執(zhí)行了gr1.switch跳轉(zhuǎn)回 test1 ，打印34，然后 test1 就結(jié)束，gr1死掉，回到父greenlet，不會再切換到test2，所以不會打印78。在上面的例子中main greenlet就是它們的父 greenlet。

eventlet是一個用來處理和網(wǎng)絡(luò)相關(guān)的python庫函數(shù)，而且可以通過協(xié)程來實現(xiàn)并發(fā)，在eventlet里，把“協(xié)程”叫做greenthread(綠色線程)。所謂并發(fā)，就是開啟了多個greenthread，并且對這些greenthread進(jìn)行管理，以實現(xiàn)非阻塞式的I/O。比如說用eventlet可以很方便的寫一個性能很好的web服務(wù)器，或者是一個效率很高的網(wǎng)頁爬蟲，這都?xì)w功于eventlet的“綠色線程”，以及對“綠色線程”的管理機(jī)制。更讓人不可思議的是，eventlet為了實現(xiàn)“綠色線程”，竟然對python的和網(wǎng)絡(luò)相關(guān)的幾個標(biāo)準(zhǔn)庫函數(shù)進(jìn)行了改寫，并且可以以補(bǔ)丁(patch)的方式導(dǎo)入到程序中，因為python的庫函數(shù)只支持普通的線程，而不支持協(xié)程，eventlet稱之為“綠化”。Eventlet庫在OpenStack服務(wù)中上鏡率很高，尤其是在服務(wù)的多線程和WSGI Server并發(fā)處理請求的情況下。

主要API如下：

Greenthread 產(chǎn)⽣：

spawn(func, *args, **kwargs)： 創(chuàng)建一個綠色線程去運(yùn)行func這個函數(shù)，后面的參數(shù)是傳遞給這個函數(shù)的參數(shù)。返回值是一個eventlet.GreenThread對象，這個對象可以用來接受func函數(shù)運(yùn)行的返回值。在綠色線程池還沒有滿的情況下，這個綠色線程一被創(chuàng)建就立刻被執(zhí)行。其實，用這種方法去創(chuàng)建線程也是可以理解的，線程被創(chuàng)建出來，肯定是有一定的任務(wù)要去執(zhí)行，這里直接把函數(shù)當(dāng)作參數(shù)傳遞進(jìn)去，去執(zhí)行一定的任務(wù)，就好像標(biāo)準(zhǔn)庫中的線程用run方法去執(zhí)行任務(wù)一樣。

spawn_n(func, *args, **kwargs)： 這個函數(shù)和spawn類似，不同的就是它沒有返回值，因而更加高效，這種特性，使它也有存在的價值。

spawn_after(seconds, func, *args, **kwargs)： 這個函數(shù)和spawn基本上一樣，都有一樣的返回值，不同的是它可以限定在什么時候執(zhí)行這個綠色線程，即在seconds秒之后，啟動這個綠色線程。

Greenthread 控制：

sleep(seconds=0)：中止當(dāng)前綠色線程，以允許其它綠色線程執(zhí)行。

eventlet.GreenPool： 這是一個類，在這個類中用set集合來容納所創(chuàng)建的綠色線程，并且可以指定容納線程的***數(shù)量(默認(rèn)是1000個)，它的內(nèi)部是用Semaphore和Event這兩個類來對池進(jìn)行控制的，這樣就構(gòu)成了線程池，下面有一些重要的方法：

• running：返回當(dāng)前池中的綠色線程數(shù)
• free：返回當(dāng)前池中可容納的綠色線程數(shù)
• spawn：創(chuàng)建新的綠色線程
• spawn_n：同上

#p#

接著談?wù)凮penstack中Nova對其的應(yīng)用。

eventlet

在nova/cmd/__init__.py中，就直接調(diào)用了eventlet的方法，代碼如下：

from nova import debugger  
if debugger.enabled(): 
eventlet.monkey_patch(os=False, thread=False) 
else:  
eventlet.monkey_patch(os=False) 

這里在調(diào)試器被啟動后，關(guān)閉線程，然后啟用遠(yuǎn)程調(diào)試器。這個就是eventlet.monkey_patch()的方法。這里僅僅是因為dnspython無法支持IPV6，所以使用eventlet的monkeypatch檢測一下環(huán)境變量的設(shè)置是否符合。

greenthread

在虛機(jī)遷移過程中如果看過我寫的源碼分析，相信對于下面的代碼不會陌生：  

greenthread.spawn(self._live_migration, context, instance, dest,  
post_method, recover_method, block_migration, 
migrate_data) 

這個是熱遷移中所使用的所調(diào)用的由eventlet所封裝而成的綠色線程，調(diào)用了spawn(func,*args, kwargs)的函數(shù)，創(chuàng)建了一個綠色線程去運(yùn)行l(wèi)ive_migration也就是熱遷移的函數(shù)，返回值是一個eventlet.greenthread的對象，這個對象可以用來接受live_migration運(yùn)行的返回值。在綠色線程池未滿的情況下，就可以直接執(zhí)行熱遷移的函數(shù)。

greenthread.sleep

然后Nova中用到的最多的綠色線程的栗子可能就是time.sleep了吧，下面隨便找了幾個用到的例子：

for cnt in range(max_retry): 
try: 
self.plug_vifs(instance, network_info)  
break  
except processutils.ProcessExecutionError:  
if cnt == max_retry - 1:  
raise  
 else:  
LOG.warn(_('plug_vifs() failed %(cnt)d. Retry up to ' 
 '%(max_retry)d.'), 
 {'cnt': cnt, 
  'max_retry': max_retry}, 
  instance=instance) 
 greenthread.sleep(1) 

這個是調(diào)用plug_vifs的函數(shù)中的greenthread.sleep()的函數(shù)調(diào)用，這個函數(shù)多次的發(fā)送請求。

except exception.InstanceNotFound: 
pass 
greenthread.sleep(0) 
return disk_over_committed_size 

像這樣的栗子還有好多，一般情況下，greenthread.sleep()綠色線程的函數(shù)是為了中止當(dāng)前的線程，用來給其它的線程一個執(zhí)行的機(jī)會。其實說的通俗點就是傳說中的孔融讓梨了，不過此處的梨就是CPU、內(nèi)存等等一些資源了，綠色池中的空間了之類的，突然發(fā)現(xiàn)程序也是那么的有人情味啊~

loopingcall

接下來談?wù)動胠oopingcall實現(xiàn)固定時間間隔運(yùn)行的函數(shù)：

def _wait_for_reboot(): 
state = self.get_info(instance)['state'] 
 if state == power_state.RUNNING: 
LOG.info(_("Instance rebooted successfully."), 
 instance=instance) 
 raise loopingcall.LoopingCallDone() 
 timer = loopingcall.FixedIntervalLoopingCall(_wait_for_reboot) 
timer.start(interval=0.5).wait() 

這個函數(shù)是等待虛機(jī)重啟的函數(shù)，每隔0.5s調(diào)用一次函數(shù)，檢查虛機(jī)狀態(tài)，直到虛機(jī)重新啟動。此函數(shù)通過拋出LoopingCallDone來異常退出。

好了，對于虛機(jī)中的協(xié)同并發(fā)就到此結(jié)束了。

博文地址：http://www.cnblogs.com/voidy/