基於前段時間研究資料庫客戶端的非同步訪問，發現

1）  ADO的非同步回撥通知並不能正常工作，相見這裡，

2）  ODBC在3.8版本之前都不支援非同步回撥，詳見這裡

3）  OCI(ORACLE)也並不提供非同步回撥，只支援non-blocking模式，詳見這裡

靠，這是什麼世界啊，大家都不用非同步訪問嗎？大家對非同步回撥通知都實現的這麼弱，讓我情何以堪~

對於中介軟體伺服器訪問資料庫來講，由於需要支援大規模的併發訪問且能高效相應，在資料庫訪問元件中，並不能讓客戶端對資料的請求阻塞掉服務。所以，簡單的來講，需要分層設計，需要把網路層和資料庫層分離，解耦。在這裡，可以採用兩個佇列，一個請求佇列，一個完成佇列，如圖：

資料庫層採用執行緒池來服務所有的資料庫操作請求，工作流程：

1）  網路層接受客戶端資料庫請求，放入請求佇列中

2）  資料庫層檢測到有新的請求任務，選擇一個執行緒來進行阻塞式資料庫操作

3）  當完成一次阻塞操作後，發起一個完成操作，放入完成佇列中

4）  網路層檢測到完成佇列中有任務，就拿出進行處理

對於這種模式存在兩點不足：

1）  對佇列要求很高，在理論上來講會出現較大的排隊現象，如果產生一個耗時的資料庫操作，就會影響以後的請求

2）  由於資料庫訪問採用同步阻塞的方式，並不能高效發揮資料庫的潛能

對此，我們還是需要採用非阻塞的方式來完成。當然能量是守恆的，這個請求佇列是不用我們來寫程式碼實現了，但是資料庫訪問元件或者資料庫管理連線模組肯定有個佇列。但是我們把風險轉嫁給了成熟的元件，而且我也相信有特別的優化。

所以，非同步操作資料庫操作後的狀態監測，由我們來完成，如果發現完成，就向完成佇列投遞完成訊息。實現思路就是採用一個執行緒輪詢監測請求的資料庫操作狀態。基於我的IOCP框架而做，當然，也可以替換掉，無非就是一個執行緒池的管理。

後記

基於方法論而言，其實這種模式不僅僅可以用在對資料庫操作的檢測，還可以用在其他類似的地方，所以，我抽象出這麼一個框架供大家學習討論。

猛擊這裡進行下載