数据库异步访问解决方案

基于前段时间研究数据库客户端的异步访问，发现

1）  ADO的异步回调通知并不能正常工作，相见这里，

2）  ODBC在3.8版本之前都不支持异步回调，详见这里

3）  OCI(ORACLE)也并不提供异步回调，只支持non-blocking模式，详见这里

靠，这是什麽世界啊，大家都不用异步访问吗？大家对异步回调通知都实现的这么弱，让我情何以堪~

 

对于中间件服务器访问数据库来讲，由于需要支持大规模的并发访问且能高效相应，在数据库访问组件中，并不能让客户端对数据的请求阻塞掉服务。所以，简单的来讲，需要分层设计，需要把网络层和数据库层分离，解耦。在这里，可以采用两个队列，一个请求队列，一个完成队列，如图：

 

数据库层采用线程池来服务所有的数据库操作请求，工作流程：

1）  网络层接受客户端数据库请求，放入请求队列中

2）  数据库层检测到有新的请求任务，选择一个线程来进行阻塞式数据库操作

3）  当完成一次阻塞操作后，发起一个完成操作，放入完成队列中

4）  网络层检测到完成队列中有任务，就拿出进行处理

 

对于这种模式存在两点不足：

1）  对队列要求很高，在理论上来讲会出现较大的排队现象，如果产生一个耗时的数据库操作，就会影响以后的请求

2）  由于数据库访问采用同步阻塞的方式，并不能高效发挥数据库的潜能

 

对此，我们还是需要采用非阻塞的方式来完成。当然能量是守恒的，这个请求队列是不用我们来写代码实现了，但是数据库访问组件或者数据库管理连接模块肯定有个队列。但是我们把风险转嫁给了成熟的组件，而且我也相信有特别的优化。

 

所以，异步操作数据库操作后的状态监测，由我们来完成，如果发现完成，就向完成队列投递完成消息。实现思路就是采用一个线程轮询监测请求的数据库操作状态。基于我的IOCP框架而做，当然，也可以替换掉，无非就是一个线程池的管理。

 

后记

基于方法论而言，其实这种模式不仅仅可以用在对数据库操作的检测，还可以用在其他类似的地方，所以，我抽象出这么一个框架供大家学习讨论。

猛击这里进行下载