採用IOCP模型開發SOCKET服務端設計思路

1、設計模式；
      IO收發線程與EMPLOY任務線程必須分離設計，否則如果只考慮IO線程來處理所有事情的話，一旦出現某個業務介面運行較慢，勢必造成對IO網路的堵塞，那麼這樣的後台服務又有什麼用呢？
      EMPLOY任務線程指派演算法，要看具體業務來定，如果所有業務實現資料轉送量大小差不多，反應時間長短都差不多的話，可以採取平均順序分配的方式，否則可以按照業務具體調用來指派某一個或多個EMPLOY任務線程來處理。
      如果再做的好一點的話，應該對每個EMPLOY任務線程進行監視，如按照已有任務隊列長度來決定分配哪個線程。
2、效能保證；
      必須保證正常通訊過程中，各個串連、各個線程之間基本沒有共用資料鎖機制，否則效能肯定大打折扣；
      對於Buffer訪問機制，應該採取類似Linux核心技術的迴圈緩衝機制，其最大特點就是如果同時只有一個寫線程和讀線程時，此迴圈緩衝不用加任何互斥鎖機制，這樣效能才會保證；
      對於socket本身進行的一些參數最佳化，如：設定SO_SNDBUF為零，可以減少使用者態到核心態的複製CPU耗時。
3、錯誤處理；
      IOCP最大的痛點之一，就是在串連斷開情況下的資源回收，推薦兩種辦法：
      3.1、採取延時回收策略，在保證所有Buffer對象都在一定時間內回到隊列後，再釋放該串連的所有資源，前提是要看你的業務介面運行速度了，一般30秒左右應該足夠了吧？！
      3.2、採取即時回收策略，但是必須對多線程情況下考慮加入Buffer計數器，當所有Buffer被回收到當前連線物件後，並且EMPLOY任務線程中懸而未決的該串連任務個數為0時，馬上進行回收處理。
4、容錯機制；
      主要是對包本身是否非法的檢測，一般採取：4位元組包頭長度位+N位元組資料位元的協議模式，這樣服務端只需每次解讀包頭來判斷是否合法，
      用戶端API必須保證封包的正確性，一定要避免分區報文以雜序排列發到服務端；
      如果服務端收到某串連有非法資料報文，應該主動關閉串連。
5、業務接入。
      業務繼承開發介面一般只需要關注三個方法：串連、中斷連線、讀取資料；
      業務介面只需要繼承並重載父類的讀取資料方法，並在構造完回複資料後，調用父類的發送方法；
      應該保證業務介面實現的高效性，避免一條魚腥了一鍋湯的情況發生。
效能測試建議範例：
1、每用戶端平均0.5秒發個請求，報文大小100位元組左右；
2、服務端回複1024位元組；
3、串連個數10000；
4、伺服器是R710，8核；
5、網路是千兆。

測試回應均值應不多於500微妙，好的可能達到100微妙以下，否則你的設計肯定有問題。

你的服務端設計一般只有兩個鎖機制：
1、每個連線物件的自鎖，用來保持連線物件中一些變數的同步；
2、所有串連的集合，一般為MAP，用來insert、remove用戶端串連時使用。

除此以外，你不應該再增加其他鎖。