主流的数据库有异步调用接口吗？

linux_c_py_php

其实用DB同步也没差，搞异步反而增加项目维护成本，你可以想想业务逻辑多变，你如何高效的变更DB操作逻辑？

所以，多线程网络框架，同步DB访问就可以了，多开点线程，维护全局DB连接池。

yulihua49

boyatchinaunix 发表于 2013-11-27 10:57
这个功能正是我想要的，谢谢啊。

/**
* Set OCI blocking mode on/off.
*
* By default a database connection is in blocking mode. This means
* the call does not return until the task is finished. With this
* function you can change to non-blocking mode.
* In this case some functions can return SQLO_STILL_EXECUTING.
*
* The functions are:
* <ul>
* <li>sqlo_open2 (when called for queries)
* <li>sqlo_reopen (when called for queries)
* <li>sqlo_fetch (when called for non-queries)
* <li>sqlo_exec
* <li>sqlo_execute
* </ul>
* @param dbh I - A database handle where the blocking should be changed.
* @param on  I - SQLO_ON switches blocking mode on, SQLO_OFF switches to
*                non-blocking mode
* @return <ul>
* <li>SQLO_SUCCESS
* <li>SQLO_INVALID_DB_HANDLE
* <li> < 0 on error
* </ul>
* @since Version 2.2
*/

1. if ( blocking != new_mode)
   
2.     {
   
3.       /* toggle the mode */
   
4.       if (OCI_SUCCESS !=
   
5.           (dbp->status = OCIAttrSet( (dvoid *) dbp->srvhp,
   
6.                                      (ub4) OCI_HTYPE_SERVER,
   
7.                                      (dvoid *) 0,
   
8.                                      (ub4) 0,
   
9.                                      (ub4) OCI_ATTR_NONBLOCKING_MODE,
   
10.                                      dbp->errhp))) {
    
11.         TRACE(2, fprintf(_get_trace_fp(dbp), "Unable to toggle blocking mode"););
    
12.         CHECK_OCI_STATUS_RETURN(dbp, dbp->status, "sqlo_set_blocking", "");
    
13.         return (dbp->status);
    
14.       }
    
15. 
    
16.     }
    

复制代码

yulihua49

boyatchinaunix 发表于 2013-11-27 10:07
我做的是个服务，采用epool IO处理方式。
并发量大，岂不是会有很多线程？数据库响应越慢，线程越多。

在另一个帖子聊过了哈。

在我们的中间件里，虽然支持异步，但我不主张这么做。
我建议，使用TPC（每个连接一个线程）的模式，外加交易管理器，提供线程池。
把应用逻辑和线程池分开。
使用TPC，可以数据库配连接池（连接数可配置，多少好可以试验），做同步访问。程序简单可靠，不易错。

tpc服务器不直接对外。所有客户端都连接到交易管理器，可支持上万的同时在线。
管理器对服务器有一个连接池，连接数可配置。管理器是线程池的，线程数可配置。
就是，线程数，连接数，数据库连接数都是可配置的，你可以通过试验，最佳搭配，都能满足交易要求。

这样，上万的客户端，到服务器一般只有几十个连接，起到了线程池的作用。
交易管理器的处理吞吐量为65000/秒，足够一般的高密度交易了。

boyatchinaunix

linux_c_py_php 发表于 2013-11-27 11:06
其实用DB同步也没差，搞异步反而增加项目维护成本，你可以想想业务逻辑多变，你如何高效的变更DB操作逻辑？ ...

本来顺序执行的工作，被强行分成几个阶段，确实增加很多项目复杂性。
我也在想比较好的方案。

yulihua49

boyatchinaunix 发表于 2013-11-27 10:25
这个事情真是比较令人头疼，努力寻求最优解。
我要把数据库的操作结果反馈给用户。也不知道弄几个队列比较 ...

我们的中间件这个问题解决了，网络连接池，数据库连接池都是自愈的，较好的解决了故障和恢复的问题。
数量可配置，容易找到最佳搭配。
软件和文档可以到SDBC群，免费下载。
高性能数据库包装器可以使每个交易占时尽可能短。
搭配好了，数据库可以饱和，就是达到了数据库最高处理能力。这样，讨论前端服务器什么同步异步都是没有意义的。

iw1210

没用epool用 select 的路过

boyatchinaunix

yulihua49 发表于 2013-11-27 11:58
我们的中间件这个问题解决了，网络连接池，数据库连接池都是自愈的，较好的解决了故障和恢复的问题。
数 ...

我对数据库的操作很简单，只有三五条插入语句，也不会经常变化。
想找轻量级的解决方案。

yulihua49

boyatchinaunix 发表于 2013-11-27 12:02
我对数据库的操作很简单，只有三五条插入语句，也不会经常变化。
想找轻量级的解决方案。

那何必担心性能？
过于复杂的方案牺牲了可靠性。
交易中间件要应对每秒数万的密度，和并发、互斥等复杂情况。
当然简单的活也能干。

同步，也可以把数据库灌满，就是说没有改进余地。
应用服务器满不满又有什么关系呢？
同步异步又有什么关系呢？

服务线程数=数据库连接数，就没什么问题。
如果二者不等，就会有复杂的情况出现，服务器可能会死掉。
我们的中间件处理了这个问题，程序是比较复杂的。

boyatchinaunix

我做的是个插件，新开线程后，会有许多复杂的问题出现。
尤其是，如果线程是底层接口开的，会更不可控。

yulihua49

boyatchinaunix 发表于 2013-11-27 12:44
我做的是个插件，新开线程后，会有许多复杂的问题出现。
尤其是，如果线程是底层接口开的，会更不可控。

在旧系统上改的？那风险太大了。
线程管理应该在框架做，而不应该插件做。

哦，单线程框架，插件没法多线程，想异步操作？
那上下文调度很麻烦的。
你可能要把插件搞成二级框架了。
框架接口？socket？
把socket连同context抛到epoll，后边多个线程守护，激活后再抛到应用层，在应用层进行线程安全的业务，然后结果按原路抛回。
这样就可以多线程同步，避免单线程异步。