- 事件驅動
gevent協程可實現自動切換，協程在遇到IO時會進行切換，到另外一個請求，那協程是如何得知在什么時候在切換回去呢？
通常，我們寫服務器處理模型的程序時，有以下幾種模型：
（1）每收到一個請求，創建一個新的進程，來處理該請求；
（2）每收到一個請求，創建一個新的線程，來處理該請求；
（3）每收到一個請求，放入一個事件列表，讓主進程通過非阻塞I/O方式來處理請求
上面的幾種方式，各有千秋:
第（1）中方法，由於創建新的進程的開銷比較大，所以，會導致服務器性能比較差,但實現比較簡單。
第（2）種方式，由於要涉及到線程的同步，有可能會面臨
死鎖等問題。
第（3）種方式，在寫應用程序代碼時，邏輯比前面兩種都復雜。
綜合考慮各方面因素，一般普遍認為第（3）種方式是大多數
網絡服務器采用的方式。
- 看圖說話講事件驅動模型
在UI編程中，常常要對鼠標點擊進行相應，首先如何獲得鼠標點擊呢？
方式一：創建一個線程，該線程一直循環檢測是否有鼠標點擊，那么這個方式有以下幾個缺點：
1. CPU資源浪費，可能鼠標點擊的頻率非常小，但是掃描線程還是會一直循環檢測，這會造成很多的CPU資源浪費；如果掃描鼠標點擊的接口是阻塞的呢？
2. 如果是堵塞的，又會出現下面這樣的問題，如果我們不但要掃描鼠標點擊，還要掃描鍵盤是否按下，由於掃描鼠標時被堵塞了，那么可能永遠不會去掃描鍵盤；
3. 如果一個循環需要掃描的設備非常多，這又會引來響應時間的問題；
注：該方式是非常不好的。
方式二：就是事件驅動模型
目前大部分的UI編程都是事件驅動模型，如很多UI平台都會提供onClick(鼠標)事件，這個事件就代表鼠標按下事件。事件驅動模型大體思路如下：
1. 有一個事件（消息）隊列；
2. 鼠標按下時，往這個隊列中增加一個點擊事件（消息）；
3. 有個循環，不斷從隊列取出事件，根據不同的事件，調用不同的函數，如onClick(鼠標)、onKeyDown(鍵盤)等；
4. 事件（消息）一般都各自保存各自的處理函數指針，這樣，每個消息都有獨立的處理函數；
- 事件驅動模型
# 網絡編程范式 根據事件發生進行相應處理。
# 其他范式：單線程同步、多線程編程。
當一個事件進入，放入到列表隊列內注冊任務，如果這個事件處理需要5秒鍾，協程會在去處理第二個事件也放入隊列內，通過一個不斷檢測事件的線程來處理相應的事件。這個處理機制是由外部事件如鼠標，鍵盤來產生，他的特點是包含一個事件循環，當外部事件發生時使用回調機制來觸發相應的處理。回調主要是執行線程處理完畢時在次進行的理，同時告訴協程這個事情處理完畢，事件進入注冊任務時同時會加一個回調函數，這個回調內容可以自定義。
- 編程范式
紅色(任務1) 、藍色（任務2） 、黃色（任務3） 、灰色（IO處理）
這里我們用到了三種編程范式，分別是線程，進程，協程，可以清晰的看出線程用的時間最長效率低，進程雖然效率高但消耗資源，協程分開切換io處理，提高效率並節省資源，將CPU與IO單獨進行處理，CPU只負責計算，通過一個線程把IO交給操作系統，並回調結果與協程在次交互。
