前言
最近有人在Twisted郵件列表中提出諸如"為任務(wù)緊急的人提供一份Twisted介紹"的需求。值得提前透露的是，這個(gè)系列并不會如他們所愿。尤其是介紹Twisted框架和基于Python 的異步編程而言，可能短時(shí)間無法講清楚。因此,如果你時(shí)間緊急，這恐怕不是你想找的資料。
我相信如果對異步編程模型一無所知，快速的介紹同樣無法讓你對其有所理解，至少你得稍微懂點(diǎn)基礎(chǔ)知識吧。我已經(jīng)用Twisted框架幾年了，因此思考過我當(dāng)初是怎么學(xué)習(xí)它(學(xué)得很慢)并發(fā)現(xiàn)學(xué)習(xí)它的最大難度并不在Twisted本身,而在于對其模型的理解，只有理解了這個(gè)模型，你才能更好去寫和理解異步程序的代碼。大部分Twisted的代碼寫得很清晰，其在線文檔也非常棒（至少在開源軟件這個(gè)層次上可以這么說）。但如果不理解這個(gè)模型，不管是讀Twisted源碼還是使用Twisted的代碼更或者是相關(guān)文檔，你都會感到非常的傷腦筋。
因此，我會用前面幾個(gè)部分來介紹這個(gè)模型以讓你掌握它的機(jī)制，稍后會介紹一下Twisted的特點(diǎn)。實(shí)際上，一開始，我們并不會使用Twisted，相反，會使用簡單的Python代碼來說明一個(gè)異步模型是如何工作的。我們在初次學(xué)習(xí)Twisted的時(shí)，會從你平常都不會直接使用的底層的實(shí)現(xiàn)講起。Twisted是一個(gè)高度抽象的體系，因此在使用它時(shí)，你會體會到其多層次性。但當(dāng)你去學(xué)習(xí)尤其是嘗試著理解它是如何工作時(shí)，這種為抽像而帶來的多層次性會給你帶來極大的理解難度。所以，我們準(zhǔn)備來個(gè)從內(nèi)到外，從低層開始學(xué)習(xí)它。

模型
為了更好的理解異步編程模型的特點(diǎn)，我們來回顧一下兩個(gè)大家都熟悉的模型。在闡述過程中，我們假設(shè)一個(gè)包含三個(gè)相互獨(dú)立任務(wù)的程序。在此，除了規(guī)定這些任務(wù)都要完成自己工作外，我們先不作具體的解釋，后面我們會慢慢具體了解它們。請注意：在此我用"任務(wù)"這個(gè)詞，這意味著它需要完成一些事情。
第一個(gè)模型是單線程的同步模型，如圖1所示：

圖1 同步模型
這是最簡單的編程方式。在一個(gè)時(shí)刻，只能有一個(gè)任務(wù)在執(zhí)行，并且前一個(gè)任務(wù)結(jié)束后一個(gè)任務(wù)才能開始。如果任務(wù)都能按照事先規(guī)定好的順序執(zhí)行，最后一個(gè)任務(wù)的完成意味著前面所有的任務(wù)都已無任何差錯(cuò)地完成并輸出其可用的結(jié)果―這是多么簡單的邏輯。 下面我們來呈現(xiàn)第二個(gè)模型，如圖2所示：

圖2 線程模型
在這個(gè)模型中，每個(gè)任務(wù)都在單獨(dú)的線程中完成。這些線程都是由操作系統(tǒng)來管理，若在多處理機(jī)、多核處理機(jī)的系統(tǒng)中可能會相互獨(dú)立的運(yùn)行，若在單處理機(jī)上，則會交錯(cuò)運(yùn)行。關(guān)鍵點(diǎn)在于，在線程模式中，具體哪個(gè)任務(wù)執(zhí)行由操作系統(tǒng)來處理。但編程人員則只需簡單地認(rèn)為：它們的指令流是相互獨(dú)立且可以并行執(zhí)行。雖然，從圖示看起來很簡單，實(shí)際上多線程編程是很麻煩的，你想啊，任務(wù)之間的要通信就要是線程之間的通信。線程間的通信那不是一般的復(fù)雜。什么郵槽、通道、共享內(nèi)存。。。 唉―__-
一些程序用多處理機(jī)而不是多線程來實(shí)現(xiàn)并行運(yùn)算。雖然具體的編程細(xì)節(jié)是不同的，但對于我們要研究的模型來說是一樣的。
下面我們來介紹一下異步編程模型，如圖3所示

圖3 異步模型
在這個(gè)模型中，任務(wù)是交錯(cuò)完成，值得注意的是：這是在單線程的控制下。這要比多線程模型簡單多了，因?yàn)榫幊倘藛T總可以認(rèn)為只有一個(gè)任務(wù)在執(zhí)行，而其它的在停止?fàn)顟B(tài)。雖然在單處理機(jī)系統(tǒng)中，線程也是像圖3那樣交替進(jìn)行。但作為程序員在使用多線程時(shí)，仍然需要使用圖2而不是圖3的來思考問題，以防止程序在挪到多處理機(jī)的系統(tǒng)上無法正常運(yùn)行（考慮到兼容性）。但單線程的異步程序不管是在單處理機(jī)還是在多處理機(jī)上都能很好的運(yùn)行。
在異步編程模型與多線程模型之間還有一個(gè)不同：在多線程程序中，對于停止某個(gè)線程啟動另外一個(gè)線程，其決定權(quán)并不在程序員手里而在操作系統(tǒng)那里，因此，程序員在編寫程序過程中必須要假設(shè)在任何時(shí)候一個(gè)線程都有可能被停止而啟動另外一個(gè)線程。相反，在異步模型中，一個(gè)任務(wù)要想運(yùn)行必須顯式放棄當(dāng)前運(yùn)行的任務(wù)的控制權(quán)。這也是相比多線程模型來說，最簡潔的地方。 值得注意的是：將異步編程模型與同步模型混合在同一個(gè)系統(tǒng)中是可以的。但在介紹中的絕大多數(shù)時(shí)候，我們只研究在單個(gè)線程中的異步編程模型。
動機(jī)
我們已經(jīng)看到異步編程模型之所以比多線程模型簡單在于其單指令流與顯式地放棄對任務(wù)的控制權(quán)而不是被操作系統(tǒng)隨機(jī)地停止。但是異步模型要比同步模型復(fù)雜得多。程序員必須將任務(wù)組織成序列來交替的小步完成。因此，若其中一個(gè)任務(wù)用到另外一個(gè)任務(wù)的輸出，則依賴的任務(wù)（即接收輸出的任務(wù)）需要被設(shè)計(jì)成為要接收系列比特或分片而不是一下全部接收。由于沒有實(shí)質(zhì)上的并行，從我們的圖中可以看出，一個(gè)異步程序會花費(fèi)一個(gè)同步程序所需要的時(shí)間，可能會由于異步程序的性能問題而花費(fèi)更長的時(shí)間。
因此，就要問了，為什么還要使用異步模型呢？ 在這兒，我們至少有兩個(gè)原因。首先，如果有一到兩個(gè)任務(wù)需要完成面向人的接口，如果交替執(zhí)行這些任務(wù)，系統(tǒng)在保持對用戶響應(yīng)的同時(shí)在后臺執(zhí)行其它的任務(wù)。因此，雖然后臺的任務(wù)可能不會運(yùn)行的更快，但這樣的系統(tǒng)可能會受歡迎的多。
然而，有一種情況下，異步模型的性能會高于同步模型，有時(shí)甚至?xí)浅Ｍ怀觯丛诒容^短的時(shí)間內(nèi)完成所有的任務(wù)。這種情況就是任務(wù)被強(qiáng)行等待或阻塞，如圖4所示：

圖4 同步模型中出現(xiàn)阻塞
在圖4中，灰色的部分代表這段時(shí)間某個(gè)任務(wù)被阻塞。為什么要阻塞一個(gè)任務(wù)呢？最直接的原因就是等待I/O的完成：傳輸數(shù)據(jù)或來自某個(gè)外部設(shè)備。一個(gè)典型的CPU處理數(shù)據(jù)的能力是硬盤或網(wǎng)絡(luò)的幾個(gè)數(shù)量級的倍數(shù)。因此，一個(gè)需要進(jìn)行大I/O操作的同步程序需要花費(fèi)大量的時(shí)間等待硬盤或網(wǎng)絡(luò)將數(shù)據(jù)準(zhǔn)備好。正是由于這個(gè)原因，同步程序也被稱作為阻塞程序。
從圖4中可以看出，一個(gè)可阻塞的程序，看起來與圖3描述的異步程序有點(diǎn)像。這不是個(gè)巧合。異步程序背后的最主要的特點(diǎn)就在于，當(dāng)出現(xiàn)一個(gè)任務(wù)像在同步程序一樣出現(xiàn)阻塞時(shí)，會讓其它可以執(zhí)行的任務(wù)繼續(xù)執(zhí)行，而不會像同步程序中那樣全部阻塞掉。因此一個(gè)異步程序只有在沒有任務(wù)可執(zhí)行時(shí)才會出現(xiàn)"阻塞"，這也是為什么異步程序被稱為非阻塞程序的原因。 任務(wù)之間的切換要不是此任務(wù)完成，要不就是它被阻塞。由于大量任務(wù)可能會被阻塞，異步程序等待的時(shí)間少于同步程序而將這些時(shí)間用于其它實(shí)時(shí)工作的處理（如與人打交道的接口），這樣一來，前者的性能必然要高很多。
與同步模型相比，異步模型的優(yōu)勢在如下情況下會得到發(fā)揮：
有大量的任務(wù)，以至于可以認(rèn)為在一個(gè)時(shí)刻至少有一個(gè)任務(wù)要運(yùn)行
任務(wù)執(zhí)行大量的I/O操作，這樣同步模型就會在因?yàn)槿蝿?wù)阻塞而浪費(fèi)大量的時(shí)間
任務(wù)之間相互獨(dú)立，以至于任務(wù)內(nèi)部的交互很少。
這些條件大多在CS模式中的網(wǎng)絡(luò)比較繁忙的服務(wù)器端出現(xiàn)（如WEB服務(wù)器）。每個(gè)任務(wù)代表一個(gè)客戶端進(jìn)行接收請求并回復(fù)的I/O操作。客戶的請求（相當(dāng)于讀操作）都是相互獨(dú)立的。因此一個(gè)網(wǎng)絡(luò)服務(wù)是異步模型的典型代表，這也是為什么twisted是第一個(gè)也是最棒的網(wǎng)絡(luò)庫。

對你的假設(shè)
在展開討論前，我假設(shè)你已經(jīng)有過用Python寫同步程序的經(jīng)歷并且至少知道一點(diǎn)有關(guān)Python的Sockt編程的經(jīng)驗(yàn)。如果你從沒有寫過Socket程序，或許你可以去看看Socket模塊的文檔，尤其是后面的示例代碼。如果你沒有用過Python的話，那后面的描述對你來說可能比看周易還痛苦。

對你的環(huán)境假設(shè)
我一般是在Linux上使用Twisted，這個(gè)系列的示例代碼也是在Linux下完成的。首先聲明的是我并沒有故意讓代碼失去平臺無關(guān)性，但我所講述的一些內(nèi)容確實(shí)可能僅僅適應(yīng)于Linux和其它的類Unix（比如MAC OSX或FreeBSD）。WIndows是個(gè)奇怪詭異的地方（為什么這么評價(jià)Windows呢），如果你想嘗試在它上面學(xué)習(xí)這個(gè)系列，抱歉，如果出了問題，我無法提供任何幫助。 并且假設(shè)你已經(jīng)安裝了Python和Twisted。我所提供的示例代碼是基于Python2.5和Twisted8.2.0。 你可以在單機(jī)上運(yùn)行所有的示例代碼，也可以在網(wǎng)絡(luò)系統(tǒng)上運(yùn)行它們。但是為了學(xué)習(xí)異步編程的機(jī)制，單機(jī)上學(xué)習(xí)是比較理想的。
獲取代碼的方法

使用git工具來獲取Dave的最新示例代碼。在shell或其它命令行上輸入以下命令（假設(shè)已經(jīng)安裝git）：

            
git clone git://github.com/jdavisp3/twisted-intro.git

          

下載結(jié)束后，解壓并進(jìn)入第一層文件夾（你可以看到有個(gè)README文件）。

低效的詩歌服務(wù)器
雖然CPU的處理速度遠(yuǎn)遠(yuǎn)快于網(wǎng)絡(luò)，但網(wǎng)絡(luò)的處理速度仍然比人腦快，至少比人類的眼睛快。因此，想通過網(wǎng)絡(luò)來獲得CPU的視角是很困難的，尤其是在單機(jī)的回路模式中數(shù)據(jù)流全速傳輸時(shí)，更是困難重重。
我們所需要的是一個(gè)慢速低效詩歌服務(wù)器，其用人為的可變延時(shí)來體現(xiàn)對結(jié)果的影響。畢竟服務(wù)器要提供點(diǎn)東西嘛，我們就提供詩歌好了。目錄下面有個(gè)子目錄專門存放詩歌用的。
最簡單的慢速詩歌服務(wù)器在blocking-server/slowpoetry.py中實(shí)現(xiàn)。你可用下面的方式來運(yùn)行它。

            
python blocking-server/slowpoetry.py poetry/ecstasy.txt

          

上面這個(gè)命令將啟動一個(gè)阻塞的服務(wù)器，其提供"Ecstasy"這首詩。現(xiàn)在我們來看看它的源碼內(nèi)容，正如你所見，這里面并沒有使用任何Twisted的內(nèi)容，只是最基本的Socket編程操作。它每次只發(fā)送一定字節(jié)數(shù)量的內(nèi)容，而每次中間延時(shí)一段時(shí)間。默認(rèn)的是每隔0.1秒發(fā)送10個(gè)比特，你可以通過--delay和 --num-bytes參數(shù)來設(shè)置。例如每隔5秒發(fā)送50比特：

            
python blocking-server/slowpoetry.py --num-bytes 50 ?C-delay 5 poetry/ecstasy.txt

          

當(dāng)服務(wù)器啟動時(shí)，它會顯示其所監(jiān)聽的端口號。默認(rèn)情況下，端口號是在可用端口號池中隨機(jī)選擇的。你可能想使用固定的端口號，那么無需更改代碼，只需要在啟動命令中作下修改就OK了，如下所示：

            
python blocking-server/slowpoetry.py --port 10000 poetry/ecstasy.txt

          

如果你裝有netcat工具，可以用如下命令來測試你的服務(wù)器（也可以用telnet）：

            
netcat localhost 10000

          

如果你的服務(wù)器正常工作，那么你就可以看到詩歌在你的屏幕上慢慢的打印出來。對！你會注意到每次服務(wù)器都會發(fā)送過一行的內(nèi)容過來。一旦詩歌傳送完畢，服務(wù)器就會關(guān)閉這條連接。
默認(rèn)情況下，服務(wù)器只會監(jiān)聽本地回環(huán)的端口。如果你想連接另外一臺機(jī)子的服務(wù)器，你可以指定其IP地址內(nèi)容，命令行參數(shù)是 --iface選項(xiàng)。
不僅是服務(wù)器在發(fā)送詩歌的速度慢，而且讀代碼可以發(fā)現(xiàn)，服務(wù)器在服務(wù)一個(gè)客戶端時(shí)其它連接進(jìn)來的客戶端只能處于等待狀態(tài)而得不到服務(wù)。這的確是一個(gè)低效慢速的服務(wù)器，要不是為了學(xué)習(xí)，估計(jì)沒有任何其它用處。

阻塞模式的客戶端
在示例代碼中有一個(gè)可以從多個(gè)服務(wù)器中順序（一個(gè)接一個(gè)）地下載詩歌的阻塞模式的客戶端。下面讓這個(gè)客戶端執(zhí)行三個(gè)任務(wù)，正如第一個(gè)部分圖1描述的那樣。首先我們啟動三個(gè)服務(wù)器，提供三首不同的詩歌。在命令行中運(yùn)行下面三條命令：

            
python blocking-server/slowpoetry.py --port 10000 poetry/ecstasy.txt --num-bytes 30
python blocking-server/slowpoetry.py --port 10001 poetry/fascination.txt
python blocking-server/slowpoetry.py --port 10002 poetry/science.txt

          

如果在你的系統(tǒng)中上面那些端口號有正在使用中，可以選擇其它沒有被使用的端口。注意，由于第一個(gè)服務(wù)器發(fā)送的詩歌是其它的三倍，這里我讓第一個(gè)服務(wù)器使用每次發(fā)送30個(gè)字節(jié)而不是默認(rèn)的10個(gè)字節(jié)，這樣一來就以3倍于其它服務(wù)器的速度發(fā)送詩歌，因此它們會在幾乎相同的時(shí)間內(nèi)完成工作。
現(xiàn)在我們使用阻塞模式的客戶端來獲取詩歌，運(yùn)行如下所示的命令：
python blocking-client/get-poetry.py 10000 10001 10002
如果你修改了上面服務(wù)口器的端口，你需要在這里相應(yīng)的修改以保持一致。由于這個(gè)客戶端采用的是阻塞模式，因此它會一首一首的下載，即只有在完成一首時(shí)才會開始下載另外一首。這個(gè)客戶端會像下面這樣打印出提示信息而不是將詩歌打印出來：

            
Task 1: get poetry from: 127.0.0.1:10000
Task 1: got 3003 bytes of poetry from 127.0.0.1:10000 in 0:00:10.126361 
Task 2: get poetry from: 127.0.0.1:10001 
Task 2: got 623 bytes of poetry from 127.0.0.1:10001 in 0:00:06.321777
Task 3: get poetry from: 127.0.0.1:10002 
Task 3: got 653 bytes of poetry from 127.0.0.1:10002 in 0:00:06.617523
Got 3 poems in 0:00:23.065661

          

這圖1最典型的文字版了，每個(gè)任務(wù)下載一首詩歌。你運(yùn)行后可能顯示的時(shí)間會與上面有所差別，并且也會隨著你改變服務(wù)器的發(fā)送時(shí)間參數(shù)而改變。嘗試著更改一下參數(shù)來觀測一下效果。

異步模式的客戶端
現(xiàn)在，我們來看看不用Twisted構(gòu)建的異步模式的客戶端。首先，我們先運(yùn)行它試試。啟動使用前面的三個(gè)端口來啟動三個(gè)服務(wù)器。如果前面開啟的還沒有關(guān)閉，那就繼續(xù)用它們好了。接下來，我們通過下面這段命令來啟動我們的異步模式的客戶端：

            
python async-client/get-poetry.py 10000 10001 10002

          

你或許會得到類似于下面的輸出：

            
Task 1: got 30 bytes of poetry from 127.0.0.1:10000 
Task 2: got 10 bytes of poetry from 127.0.0.1:10001
Task 3: got 10 bytes of poetry from 127.0.0.1:10002
Task 1: got 30 bytes of poetry from 127.0.0.1:10000 
Task 2: got 10 bytes of poetry from 127.0.0.1:10001
...
Task 1: 3003 bytes of poetry
Task 2: 623 bytes of poetry
Task 3: 653 bytes of poetry
Got 3 poems in 0:00:10.133169

          

這次的輸出可能會比較長，這是由于在異步模式的客戶端中，每次接收到一段服務(wù)器發(fā)送來的數(shù)據(jù)都要打印一次提示信息，而服務(wù)器是將詩歌分成若干片段發(fā)送出去的。值得注意的是，這些任務(wù)相互交錯(cuò)執(zhí)行，正如第一部分圖3所示。
嘗試著修改服務(wù)器的設(shè)置（如將一個(gè)服務(wù)器的延時(shí)設(shè)置的長一點(diǎn)），來觀察一下異步模式的客戶端是如何針對變慢的服務(wù)器自動調(diào)節(jié)自身的下載來與較快的服務(wù)器保持一致。這正是異步模式在起作用。
還需要值得注意的是，根據(jù)上面的設(shè)置，異步模式的客戶端僅在10秒內(nèi)完成工作，而同步模式的客戶端卻使用了23秒。現(xiàn)在回憶一下第一部分中圖3與圖4.通過減少阻塞時(shí)間，我們的異步模式的客戶端可以在更短的時(shí)間里完成下載。誠然，我們的異步客戶端也有些阻塞發(fā)生，那是由于服務(wù)器太慢了。由于異步模式的客戶端可以在不同的服務(wù)器來回切換，它比同步模式的客戶產(chǎn)生的阻塞就少得多。

更近一步的觀察
現(xiàn)在讓我們來讀一下異步模式客戶端的代碼。注意其與同步模式客戶端的差別：

• 異步模式客戶端一次性與全部服務(wù)器完成連接，而不像同步模式那樣一次只連接一個(gè)。
• 用來進(jìn)行通信的Socket方法是非阻塞模的，這是通過調(diào)用setblocking(0)來實(shí)現(xiàn)的。
• select模塊中的select方法是用來識別其監(jiān)視的socket是否有完成數(shù)據(jù)接收的，如果沒有它就處于阻塞狀態(tài)。
• 當(dāng)從服務(wù)器中讀取數(shù)據(jù)時(shí)，會盡量多地從Socket讀取數(shù)據(jù)直到它阻塞為止，然后讀下一個(gè)Socket接收的數(shù)據(jù)（如果有數(shù)據(jù)接收的話）。這意味著我們需要跟蹤記錄從不同服務(wù)器傳送過來詩歌的接收情況（因?yàn)椋皇自姷慕邮詹⒉皇沁B續(xù)完成，所以需要保證每個(gè)任務(wù)的可連續(xù)性，就得有冗余的信息來完成這一工作）。

異步模式中客戶端的核心就是最高層的循環(huán)體，即get_poetry函數(shù)。這個(gè)函數(shù)可以被拆分成兩個(gè)步驟：

• 使用select函數(shù)等待所有Socket，直到至少有一個(gè)socket有數(shù)據(jù)到來。
• 對每個(gè)有數(shù)據(jù)需要讀取的socket，從中讀取數(shù)據(jù)。但僅僅只是讀取有效數(shù)據(jù)，不能為了等待還沒來到的數(shù)據(jù)而發(fā)生阻塞。
• 重復(fù)前兩步，直到所有的socket被關(guān)閉。

可以看出，同步模式客戶端也有個(gè)循環(huán)體（在main函數(shù)內(nèi)），但是這個(gè)循環(huán)體的每個(gè)迭代都是完成一首詩的下載工作。而在異步模式客戶端的每次迭代過程中，我們可以完成所有詩歌的下載或者是它們中的一些。我們并不知道在一個(gè)迭代過程中，在下載哪首詩，或者一次迭代中我們下載了多少數(shù)據(jù)。這些都依賴于服務(wù)器的發(fā)送速度與網(wǎng)絡(luò)環(huán)境。我們只需要select函數(shù)告訴我們哪個(gè)socket有數(shù)據(jù)需要接收，然后在保證不阻塞程序的前提下從其讀取盡量多的數(shù)據(jù)。

如果在服務(wù)器端口固定的條件下，同步模式的客戶端并不需要循環(huán)體，只需要順序羅列三個(gè)get_poetry就可以了。但是我們的異步模式的客戶端必須要有一個(gè)循環(huán)體來保證我們能夠同時(shí)監(jiān)視所有的socket端。這樣我們就能在一次循環(huán)體中處理盡可能多的數(shù)據(jù)。
這個(gè)利用循環(huán)體來等待事件發(fā)生，然后處理發(fā)生的事件的模型非常常見，而被設(shè)計(jì)成為一個(gè)模式：reactor模式。其圖形化表示如圖5所示：

這個(gè)循環(huán)就是個(gè)"reactor"（反應(yīng)堆），因?yàn)樗却录陌l(fā)生然后對其作相應(yīng)的反應(yīng)。正因?yàn)槿绱耍脖环Q作事件循環(huán)。由于交互式系統(tǒng)都要進(jìn)行I/O操作，因此這種循環(huán)也有時(shí)被稱作select loop,這是由于select調(diào)用被用來等待I/O操作。因此，在本程序中的select循環(huán)中，一個(gè)事件的發(fā)生意味著一個(gè)socket端處有數(shù)據(jù)來到。值得注意的是，select并不是唯一的等待I/O操作的函數(shù)，它僅僅是一個(gè)比較古老的函數(shù)而已（因此才被用的如此廣泛）。現(xiàn)在有一些新API可以完成select的工作而且性能更優(yōu)，它們已經(jīng)在不同的系統(tǒng)上實(shí)現(xiàn)了。不考慮性能上的因素，它們都完成同樣的工作：監(jiān)視一系列sockets（文件描述符）并阻塞程序，直到至少有一個(gè)準(zhǔn)備好的I/O操作。
嚴(yán)格意義上來說，我們的異步模式客戶端中的循環(huán)并不是reactor模式，因?yàn)檫@個(gè)循環(huán)體并沒有獨(dú)立于業(yè)務(wù)處理（在此是接收具體的服務(wù)器傳送來的詩歌）之外。它們被混合在一起。一個(gè)真正reactor模式的實(shí)現(xiàn)是需要實(shí)現(xiàn)循環(huán)獨(dú)立抽象出來并具有如下的功能：

• 監(jiān)視一系列與你I/O操作相關(guān)的文件描述符（description)
• 不停地向你匯報(bào)那些準(zhǔn)備好的I/O操作的文件描述符

一個(gè)設(shè)計(jì)優(yōu)秀的reactor模式實(shí)現(xiàn)需要做到：

• 處理所有不同系統(tǒng)會出現(xiàn)的I/O事件
• 提供優(yōu)雅的抽象來幫助你在使用reactor時(shí)少花些心思去考慮它的存在
• 提供你可以在抽象層外使用的公共協(xié)議實(shí)現(xiàn)。
• 好了，我們上面所說的其實(shí)就是Twisted ― 健壯、跨平臺實(shí)現(xiàn)了reactor模式并含有很多附加功能。