| IOCP模型與EPOLL模型的比較 |
|
一：IOCP和Epoll之間的異同。
異：
1：IOCP是WINDOWS系統下使用。Epoll是Linux系統下使用。
2：IOCP是IO操作完畢之後，通過Get函數獲得一個完成的事件通知。
Epoll是當你希望進行一個IO操作時，向Epoll查詢是否可讀或者可寫，若處於可讀或可寫狀態後，Epoll會通過epoll_wait進行通知。
3：IOCP封裝了非同步訊息事件的通知機制，同時封裝了部分IO操作。但Epoll僅僅封裝了一個非同步事件的通知機制，並不負責IO讀寫操作。Epoll保持了事件通知和IO操作間的獨立性，更加簡單靈活。
4：基於上面的描述，我們可以知道Epoll不負責IO操作，所以它只告訴你當前可讀可寫了，並且將協議讀寫緩衝填充，由使用者去讀寫控制，此時我們可以做出額外的許多操作。IOCP則直接將IO通道裡的讀寫操作都做完了才通知使用者，當IO通道裡發生了堵塞等狀況我們是無法控制的。 同：
1：它們都是非同步事件驅動的網路模型。
2：它們都可以向底層進行指標資料傳遞，當返回事件時，除可通知事件類型外，還可以通知事件相關資料。 二：描述一下IOCP:
扯遠點。首先傳統伺服器的網路IO流程如下：
接到一個用戶端串連->建立一個線程負責這個串連的IO操作->持續對新線程進行資料處理->全部資料處理完畢->終止線程。
但是這樣的設計代價是：
1：每個串連建立一個線程，將導致過多的線程。
2：維護線程所消耗的堆棧記憶體過大。
3：作業系統建立和銷毀線程過大。
4：線程之間切換的上下文代價過大。
此時我們可以考慮使用線程池解決其中3和4的問題。這種傳統的伺服器網路結構稱之為會話模型。
後來我們為防止大量線程的維護，建立了I/O模型，它被希望要求可以:
1：允許一個線程在不同時刻給多個用戶端進行服務。
2：允許一個用戶端在不同時間被多個線程服務。
這樣做的話，我們的線程則會大幅度減少，這就要求以下兩點：
1：用戶端狀態的分離，之前會話模式我們可以通過線程狀態得知用戶端狀態，但現在用戶端狀態要通過其他方式擷取。
2：I/O請求的分離。一個線程不再服務於一個用戶端工作階段，則要求用戶端對這個線程提交I/O處理請求。
那麼就產生了這樣一個模式，分為兩部分:
1：工作階段狀態管理模組。它負責接收到一個用戶端串連，就建立一個工作階段狀態。
2：當工作階段狀態發生改變，例如斷掉串連，接收到網路訊息，就發送一個I/O請求給 I/O工作模組進行處理。
3：I/O工作模組接收到一個I/O請求後，從線程池裡喚醒一個背景工作執行緒，讓該背景工作執行緒處理這個I/O請求，處理完畢後，該背景工作執行緒繼續掛起。
上面的做法，則將網路連接 和I/O背景工作執行緒分離為兩個部分，相互連訊僅依靠 I/O請求。
此時可知有以下一些建議：
1：在進行I/O請求處理的背景工作執行緒是被喚醒的背景工作執行緒，一個CPU對應一個的話，可以最大化利用CPU。所以 活躍線程的個數 建議等於 硬體CPU個數。
2：背景工作執行緒我們開始建立了線程池，免除建立和銷毀線程的代價。因為線程是對I/O進行操作的，且一一對應，那麼當I/O全部並行時，背景工作執行緒必須滿足I/O並行操作需求，所以 線程池內最大背景工作執行緒個數 建議大於或者等於 I/O並行個數。
3：但是我們可知CPU個數又限制了活躍的線程個數，那麼線程池過大意義很低，所以按常規建議 線程池大小 等於 CPU個數*2 左右為佳。例如，8核伺服器建議建立16個背景工作執行緒的線程池。
上面描述的依然是I/O模型並非IOCP，那麼IOCP是什麼呢，全稱 IO完成連接埠。
它是一種WIN32的網路I/O模型，既包括了網路連接部分，也負責了部分的I/O操作功能，用於方便我們控制有並發性的網路I/O操作。它有如下特點：
1：它是一個WIN32核心對象，所以無法運行於Linux.
2：它自己負責維護了背景工作執行緒池，同時也負責了I/O通道的記憶體池。
3：它自己實現了線程的管理以及I/O請求通知，最小化的做到了線程的環境切換。
4：它自己實現了線程的最佳化調度，提高了CPU和記憶體緩衝的使用率。
使用IOCP的基本步驟很簡單：
1：建立IOCP對象，由它負責管理多個Socket和I/O請求。CreateIoCompletionPort需要將IOCP對象和IOCP控制代碼綁定。
2：建立一個背景工作執行緒池，以便Socket發送I/O請求給IOCP對象後，由這些背景工作執行緒進行I/O操作。注意，建立這些線程的時候，將這些線程綁定到IOCP上。
3：建立一個監聽的socket。
4：輪詢，當接收到了新的串連後，將socket和完成連接埠進行關聯並且投遞給IOCP一個I/O請求。注意：將Socket和IOCP進行關聯的函數和建立IOCP的函數一樣，都是CreateIoCompletionPort，不過注意傳參必然是不同的。
5：因為是非同步，我們可以去做其他，等待IOCP將I/O操作完成會回饋我們一個訊息，我們再進行處理。
其中需要知道的是：I/O請求被放在一個I/O請求隊列裡面，對，是隊列，LIFO機制。當一個裝置處理完I/O請求後，將會將這個完成後的I/O請求丟回IOCP的I/O完成隊列。
我們應用程式則需要在GetQueuedCompletionStatus去詢問IOCP，該I/O請求是否完成。
其中有一些特殊的事情要說明一下，我們有時有需要人工的去投遞一些I/O請求，則需要使用PostQueuedCompletionStatus函數向IOCP投遞一個I/O請求到它的請求隊列中。
三：網路遊戲伺服器注意事項，最佳化措施
1：IO操作是最大的效能消耗點，注意最佳化餘地很大。
2：演算法資料結構。排序尋路演算法的最佳化。list,vector,hashmap的選擇。大資料定址，不要考慮遍曆，注意考慮hash.
3：記憶體管理。重載new/delete，記憶體池，對象池的處理。
4：資料的提前準備和即時計算。
5：CPU方面的統計監視。邏輯幀計數（應當50ms以內）。
6：預分配池減少切換和調度，預先處理的線程池和串連池等。
7：基與訊息佇列的統計和資訊監視架構。
8：CPU消耗排名：第一AOI同步，第二網路發包I/O操作，第三技能/BUFF判定計算處理，第四定時器的頻率。
9：記憶體泄露檢測，記憶體訪問越界警惕，記憶體片段的回收。
10：記憶體消耗排名：第一玩家對象包括其物品，第二網路資料緩衝。
11：注意32位和64位的記憶體容錯。
12：減少不必要的分包發送。
13：減少重複包和重拷貝包的代價。
14：建議分緊急包（立刻發送）和非緊急包（定時輪訓發送）。
15：頻寬消耗排名：第一移動位置同步，第二對象載入，第三登陸突發包，第四狀態機器定時器訊息。
16：用戶端可做部分預判斷機制，部分操作盡量分包發送。
17：大量玩家聚集時，部分非緊急包進行丟棄。
18：注意資料庫單表內key數量。
19：活躍使用者和非活躍使用者的分割存取處理。
20：控制玩家操作對資料庫的操作頻率。
21：注意使用共用記憶體等方式對資料進行安全備份儲存。
22：注意安全性原則，對內網進行IP檢查，對日誌進行記錄，任意兩環點內均使用密碼編譯演算法會更佳。
23：即時注意對網關，資料庫等介面進行監察控制。
24：定時器應當儲存一個隊列，而非單向定位。
25：九宮格資料同步時，不需要直接進行九宮格的同步，對角色加一個AOI，基於圓方碰撞原理，拋棄不必要的格資訊，可大幅節省。
26：用戶端做部分的預測機制，伺服器檢測時注意時間戳記問題。
27：定期心跳包，檢查死連結是必要的。
28：為了實現更加負責多種類的AI，AI尋路獨立伺服器設計已經是必須的了。其次需要考慮的是聊天，同步。
29：伺服器內網間可以考慮使用UDP。
30：注意所有記憶體池，對象池等的動態擴張分配。
1：以記憶體換取CPU的理念。
2：NPC不死理念。(只會disable)
3：動態擴充理念，負載平衡理念。
4：用戶端不可信理念。
5：指標資料，訊息均不可信理念。 |
引用：http://cto.csdn.net/Article.aspx?Name=liuyongli&pointid=4836
