转寄人: ZabraZoe (ZabraZoe)
标 题: 一个提高数据库连接效率的方法-自愈式连接池
发信站: 水木社区 (Mon Jul 20 12:57:21 2026)
来 源: 120.245.107.123
【以下内容由 ZabraZoe 转寄于 CProgramming 版】
标 题: 一个提高数据库连接效率的方法-自愈式连接池
发信站: 水木社区 (Mon Jul 20 12:57:21 2026)
来 源: 120.245.107.123
【以下内容由 ZabraZoe 转寄于 CProgramming 版】
有一个提高效率的方法，完美解决了当年的数据库连接，长连接和短连接之争。
数据库连接句柄打开开销较大，一般需要30~40ms，如果在功能模块里开，性能降低一半不止。如果常开，在多线程服务器环境不合适。
所以采用了数据库连接池，虽然很多数据库提供了内建的连接池，那与我无关。
连接池在开始时是一个连接也不开。第一个使用者取用时打开一个连接，用完归还时，如果是正常归还，不关闭，就加到空闲队列头。下一次有人用就优先取已经打开的。因数据库致命故障归还的，就关闭，回收资源，放到队尾。
一个定时器线程定时扫描连接池健康度，有超过一定时间（一般是5分钟）不用的连接就关闭之。
这是一种极为可靠的连接池健康保障法。
一般的策略是保活，这很难的，你怎么发个信息并得到应答从而确定其活不活？如果那边太忙无暇顾及你，是否会误判？你想检查的连接正在被别人使用怎么办？
我的策略是保死，只检查空闲队列，没人用就弄死，不要老占着资源。有的数据库是按连接数付费的，没事别占着茅坑不拉屎，现用现开，最健康。保活的话，检查一次空闲队列需要很长时间，不知道需要多长时间才能得到一个应答，保死的只看时间戳，检查的非常快，锁队列的时间非常短。
实践中这个方法简单而可靠。数据库崩溃，服务器不必restart，等着数据库恢复即可，这叫自愈式连接池。
实现空闲连接超时的功能
这个检查链接有效性没有替代关系
【 在 ylh1969 的大作中提到: 】
: 有一个提高效率的方法，完美解决了当年的数据库连接，长连接和短连接之争。
: 数据库连接句柄打开开销较大，一般需要30~40ms，如果在功能模块里开，性能降低一半不止。如果常开，在多线程服务器环境不合适。
: 所以采用了数据库连接池，虽然很多数据库提供了内建的连接池，那与我无关。
不是检查连接有效性，是检查连接的无用性。无用的连接关闭，不要占有资源。
打开的连接长时间不用就没法保证其可用性，夜长梦多，打开的连接，越长的时间不用，损坏的可能性越大。
如何你认为5分钟太长，可以缩短一些。这个时间等同于心跳时间间隔。
可以证明，与心跳周期容错效果相同，开销要小得多。
你可以1秒钟检查一次呀，只不过应用超过1秒间隔就重新开一次数据库呗，多消耗50ms最多了。此法对数据库没有负担。
换句话说吧，越长时间不用，损坏的可能性越大，不要等坏了再处理，关上得了。用的时候再开。
【 在 slowaction 的大作中提到: 】
: 实现空闲连接超时的功能
: 这个检查链接有效性没有替代关系
空闲超时功能是个非常常见的功能
【 在 ylh1969 的大作中提到: 】
: 不是检查连接有效性，是检查连接的无用性。无用的连接关闭，不要占有资源。
: 打开的连接长时间不用就没法保证其可用性，夜长梦多，打开的连接，越长的时间不用，损坏的可能性越大。
: 如何你认为5分钟太长，可以缩短一些。这个时间等同于心跳时间间隔。
用在连接池管理上的不多见，当年也是争议挺大的，直到证明超时间隔与心跳间隔等价，才平息了质疑。
如果连接一直在被使用，根本就不需要心跳。
【 在 slowaction 的大作中提到: 】
: 空闲超时功能是个非常常见的功能
我见过一个项目，100多个客户端，1秒一个心跳，调用存储过程，数据库光为了心跳就开销不小。日志蹭蹭的涨。当需要找故障点时就如大海捞针。
【 在 slowaction 的大作中提到: 】
: 空闲超时功能是个非常常见的功能
业务请求等价于心跳就行了，这样有业务请求包时，不用发专门的心跳包。
我搞长连接就这么干。
【 在 ylh1969 的大作中提到: 】
: 我见过一个项目，100多个客户端，1秒一个心跳，调用存储过程，数据库光为了心跳就开销不小。日志蹭蹭的涨。当需要找故障点时就如大海捞针。
对的，心跳都是针对空闲连接的，就算没事，数据库也忙得很，好几十个客户端每人1秒一个，等有事时候数据库还得抽空给你干活。
【 在 z16166 的大作中提到: 】
: 业务请求等价于心跳就行了，这样有业务请求包时，不用发专门的心跳包。
: 我搞长连接就这么干。
我一样，就比你多一个空闲连接超时关闭的功能。
像ATM之类的终端几百个，工作时间很少，一天到晚玩心跳，数据库真累。
如果长连接不管，中途数据库关了又起了，连接失效。
【 在 z16166 的大作中提到: 】
: 业务请求等价于心跳就行了，这样有业务请求包时，不用发专门的心跳包。
: 我搞长连接就这么干。
场景不一样。一直尽可能保持连接，是为了推送广告或者紧急响应给客户[emc49]
【 在 ylh1969 的大作中提到: 】
: 我一样，就比你多一个空闲连接超时关闭的功能。
: 像ATM之类的终端几百个，工作时间很少，一天到晚玩心跳，数据库真累。
: 如果长连接不管，中途数据库关了又起了，连接失效。
说的是数据库连接呀，有这功能？起码当年没有。
当年要解决的问题是，短连接效率低，长连接不可靠，数据库负担也重，每个连接至少占数据库2M空间。两种观点争执不下。
连接池可以解决，心跳又加重了数据库负担。
【 在 z16166 的大作中提到: 】
: 场景不一样。一直尽可能保持连接，是为了推送广告或者紧急响应给客户
测试在32核32线程的计算密集型任务里，5个数据库连接系统吞吐量最大。
一般项目建议工作线程数一半的连接数。具体怎么好，自己测。
每个数据库应用环境都有一个最佳连接数，有数据库连接池的话，就可以通过连接数的配置测出最佳连接数。
如果采用心跳保活的话，密集的心跳，会严重影响系统吞吐量。
【 在 z16166 的大作中提到: 】
: 场景不一样。一直尽可能保持连接，是为了推送广告或者紧急响应给客户
这种逻辑如果跑在服务器, 完全应该用现成的java方案, 你说的都是常规操作
我说的是C服务器。
JAVA做服务器，有个困难。
C有函数指针数组，服务器框架可以自定义服务函数加在函数表里即可。
客户端包头里指示出远过程函数号即可，JAVA没有指针，更没有函数指针。不知道怎么弄。
【 在 KnightZorro 的大作中提到: 】
: 这种逻辑如果跑在服务器, 完全应该用现成的java方案, 你说的都是常规操作
自愈式连接池健康管理，不是常规操作吧？一般都是心跳保活大法。
目前没有听说采用保死策略的，就是连接空闲超时关闭。
JAVA的连接池，采用这个策略吗？请介绍下。
【 在 KnightZorro 的大作中提到: 】
: 这种逻辑如果跑在服务器, 完全应该用现成的java方案, 你说的都是常规操作
一个服务器，接几百个ATM，使用率非常之低。需要挂着几百个数据库连接，每分每秒的在进行大规模心跳操作？
【 在 KnightZorro 的大作中提到: 】
: 这种逻辑如果跑在服务器, 完全应该用现成的java方案, 你说的都是常规操作
你这完全是感觉自己发明了一个很厉害的技术
实际这是连接池的基础功能，几十年前都自带的
【 在 ylh1969 的大作中提到: 】
: 自愈式连接池健康管理，不是常规操作吧？一般都是心跳保活大法。
: 目前没有听说采用保死策略的，就是连接空闲超时关闭。
: JAVA的连接池，采用这个策略吗？请介绍下。
不是发明，是采用，我喜欢用’采用’这个词。
但是没有发现采用保死策略的，都是保活的。
你知道哪个连接池使用保死策略的，请告知。
当年制定这个方案争议挺大的，所有人都坚持保活方案。
连接池健康管理，有不管的，有心跳保活的，没听说保死的。
【 在 slowaction 的大作中提到: 】
: 你这完全是感觉自己发明了一个很厉害的技术
: 实际这是连接池的基础功能，几十年前都自带的
一个链接超时，这么简单的功能，都不能算个功能点
你不如去看看哪个链接没有超时功能
【 在 ylh1969 的大作中提到: 】
: 不是发明，是采用，我喜欢用’采用’这个词。
: 但是没有发现采用保死策略的，都是保活的。
: 你知道哪个连接池使用保死策略的，请告知。
我说的是效率问题。
一直有个争论，大并发服务器环境下，长连接还是短连接。
长连接占用数据库连接太多，可靠性差，中途数据库故障处理麻烦。
短连接效率低，开关数据库开销大。
无论长短大量连接使得数据库不堪重负，激烈竞争可能导致数据库崩溃。
连接池较好的解决了这个矛盾，提供有限连接和排队机制。
但是连接的健康管理是个麻烦。一般几种处理方法：
1，不管，等效长连接，长时间可能遭遇数据库宕机。可靠性差。
2，取用时打开，归还时关闭，等效短连接，开销大。
3，心跳保活，数据库开销大，影响性能。这个也是超时，秒级的。
4，自愈式，就是空闲超时关闭连接，分钟级超时处理。完美，可靠性高，密集使用避免了频繁的打开关闭操作，闲时数据库无开销。
超时只是手段，不重要，重要的是超时干啥。
怎样平衡数据库的开销和可靠性问题。
【 在 slowaction 的大作中提到: 】
: 一个链接超时，这么简单的功能，都不能算个功能点
: 你不如去看看哪个链接没有超时功能
19楼，3和4都是超时呀，我强调的是4，有谁超时按4办的？
【 在 slowaction 的大作中提到: 】
: 一个链接超时，这么简单的功能，都不能算个功能点
: 你不如去看看哪个链接没有超时功能
做个比喻吧，你看中国建筑，立樑结构，外国教堂穹拱结构，照你说，都是石头木头，有啥新鲜。
我说穹栱结构受力更合理，你跟我搅和都是石头木头。
我的意思，传统的心跳保活技术相当于立樑结构，自愈式相当于穹栱结构。
基础材料都是超时，但精度需求不同，实现的复杂度和系统承担的压力不同。
自愈式超时非常简单，关闭连接即可，保活的，需要根据不同情况，或者发心跳或者关闭重开，如果心跳不回（心跳不回不等于数据库故障，业务繁忙来不及回呢？）或重开失败，还得想办法处理。应用这边开销大，数据库那边负担大，对正常业务产生明显的资源争夺。每个连接每秒或几秒一次的心跳，不能把正在心跳的连接放出去，对空闲队列锁定时间太长了，严重影响工作线程的效率。
自愈式几分钟捋一遍空闲队列，如果系统繁忙，就没有需要关闭的，很快捋完解锁，对工作线程的干扰几乎没有。
泛型编程和自愈式连接池，是榨干数据库性能的利器。
问题还是，哪个连接池采用了自愈式？
【 在 slowaction 的大作中提到: 】
: 一个链接超时，这么简单的功能，都不能算个功能点
: 你不如去看看哪个链接没有超时功能
看19楼21楼，一开始我也是不管的，但是数据库服务器故障或维修，应用服务器就必须在数据库正常后restart。
采用心跳法太麻烦，数据库故障时，检查一圈就得几十秒，怎么弄1秒一跳。
保死法遇到这情况，自动关闭全部连接，再有取连接的，会收到错误码，自己处理去，与我无关。等数据库恢复业务就自动恢复了，所以叫自愈。
【 在 z16166 的大作中提到: 】
: 业务请求等价于心跳就行了，这样有业务请求包时，不用发专门的心跳包。
: 我搞长连接就这么干。
大清已经亡了上百年了
【 在 ylh1969 的大作中提到: 】
: 做个比喻吧，你看中国建筑，立樑结构，外国教堂穹拱结构，照你说，都是石头木头，有啥新鲜。
: 我说穹栱结构受力更合理，你跟我搅和都是石头木头。
: 我的意思，传统的心跳保活技术相当于立樑结构，自愈式相当于穹栱结构。
拜托看看日历吧
现在是2026不是1996
【 在 ylh1969 的大作中提到: 】
: 19楼，3和4都是超时呀，我强调的是4，有谁超时按4办的？
2026也没见哪个连接池采用保死方式的。
【 在 slowaction 的大作中提到: 】
: 拜托看看日历吧
: 现在是2026不是1996
有哪个连接池没有超时机制？
这个功能普通的不值一提
你说的你那个实现估计也是好多年以前的项目吧
【 在 ylh1969 的大作中提到: 】
: 2026也没见哪个连接池采用保死方式的。
还胡搅。鸡同鸭讲。以下是给正常网友看的：
2026，ai时代，保死的方法ai想不出来，人可以想出来，让ai实施即可。
19楼，3，普通的保活，有两个超时，一个是心跳周期，一个是心跳发出后等待回音的时限。
4，保死方案，只有一个超时，而且是低精度超时，不必安排专门的线程，一般使用主线程代管即可，不占用工作线程。
【 在 slowaction 的大作中提到: 】
: 有哪个连接池没有超时机制？
: 这个功能普通的不值一提
: 你说的你那个实现估计也是好多年以前的项目吧
大楼大坝依然豆腐渣，公路大桥依然车压趴。
【 在 slowaction 的大作中提到: 】
: 大清已经亡了上百年了
你上一次看开源代码或者配置连接池，最少也15年了吧？
白头宫女在，闲话说玄宗
【 在 ylh1969 的大作中提到: 】
: 还胡搅。鸡同鸭讲。以下是给正常网友看的：
: 2026，ai时代，保死的方法ai想不出来，人可以想出来，让ai实施即可。
: 19楼，3，普通的保活，有两个超时，一个是心跳周期，一个是心跳发出后等待回音的时限。
大道至简，不搞复杂理论，只求最简。
开源系统，包括连接池监控，好复杂哦，安装配置维护，真得把宫女熬白头。我们哪有时间玩这个。而且，它们的效率太低，系统开销太大，性能不行，无法满足需求。
神乎其神的连接池健康管理，原来如此简单。每次时钟就干这个。
二维连接池管理，多个连接池，每个连接池有多个连接。
void dbpool_check()
int n,i,num;
pool *pl;
resource *rs;
INT63+1 now;
char buf[32];
if(!dbpool) return;
now=now_usec();
pl=dbpool;
for(n=0;n<DBPOOLNUM;n++,pl++) {//对于每一个连接池
if(!pl->lnk) continue;
rs=pl->lnk;
num=pl->resource_num;
pthread_mutex_lock(&pl->mut);
for(i=0;i<num;i++,rs++) {//对于每一个连接
if(rs->next >= 0) {//空闲的
if(rs->SQL_Connect.dbh>-1 && (now-rs->timestamp)>299000000) {
//空闲时间太长了
___SQL_CloseDatabase__(&rs->SQL_Connect);
if(log_level)
ShowLog(log_level,"%s:Close DBpool[%d].lnk[%d],since %s",__FUNCTION__,
n,i,rusecstrfmt(buf,rs->timestamp,YEAR_TO_USEC));
} else {//占用的，只写日志。
if(rs->SQL_Connect.dbh>-1 && (now-rs->timestamp)>299000000) {
//占用时间太长了
ShowLog(3,"%s:dbpool[%d].lnk[%d] used by tid=%lX,since %s",
__FUNCTION__,n,i,rs->tid,
rusecstrfmt(buf,rs->timestamp,YEAR_TO_USEC));
pthread_mutex_unlock(&pl->mut);
【 在 slowaction 的大作中提到: 】
: 你上一次看开源代码或者配置连接池，最少也15年了吧？
: 白头宫女在，闲话说玄宗
我去
你把超时时间硬编码写在代码了
就这还连接池
【 在 ylh1969 的大作中提到: 】
: 大道至简，不搞复杂理论，只求最简。
: 开源系统，包括连接池监控，好复杂哦，安装配置维护，真得把宫女熬白头。我们哪有时间玩这个。而且，它们的效率太低，系统开销太大，性能不行，无法满足需求。
: 神乎其神的连接池健康管理，原来如此简单。每次时钟就干这个。
因为这个时间不敏感，不需要改变。改成配置文件也不难，但是没必要。
没有性能瓶颈，无需调优，这也是此法的优点。
即使漏几个时间片也没有任何问题。什么叫低精度定时器。
【 在 slowaction 的大作中提到: 】
: 我去
: 你把超时时间硬编码写在代码了
: 就这还连接池
你这连接池大小是硬编码，超时时间也是硬编码
这就是个玩具
别说超时时间这种普通功能，你写出花来也是个玩具
【 在 ylh1969 的大作中提到: 】
: 因为这个时间不敏感，不需要改变。改成配置文件也不难，但是没必要。
: 没有性能瓶颈，无需调优，这也是此法的优点。
: 即使漏几个时间片也没有任何问题。什么叫低精度定时器。
连接池大小和连接池数量都不是硬编码，那个大写的是变量。
static int DBPOOLNUM=0;
static pool *dbpool=0;
超时时间前边解释过了，无关紧要。1分钟5分钟10分钟都无所谓，没有区别。用10分钟也可以，但是在调试时等的着急。
用完等5分钟，连接都关闭了，就成功了，5分钟是我耐心的极限与系统无关。
只激活一个线程，反复发请求，只打开1个连接就对了，不可以稀里糊涂所有的连接都给开了。
这个程序是真正投产项目，跟公司有协议，离职5年内不得披露技术内容。现在10年了才可以说10年前的事。
但是直到现在也没见到比这个更好的连接池管理策略，所以发出来共享。简单有效是我的设计原则，因为我懒。
你有更简便更有效的方案吗？拿出来讨论下。
【 在 slowaction 的大作中提到: 】
: 你这连接池大小是硬编码，超时时间也是硬编码
: 这就是个玩具
: 别说超时时间这种普通功能，你写出花来也是个玩具
果然是十多年前的设计
没见过应该多学习
随便看一个连接池就知道超时是个非常普通的功能
顺路说一下，变量用全大写这是哪学来的毛病
【 在 ylh1969 的大作中提到: 】
: 连接池大小和连接池数量都不是硬编码，那个大写的是变量。
: static int DBPOOLNUM=0;
: static pool *dbpool=0;
哈，这是个遗留问题，内部变量，封装在模块内，与别人无关，就懒得改了。
再说这个程序本身并不是超时功能，只不过是低精度定时任务的一个嵌入模块。低精度定时线程才是你说的功能，那个线程里有个任务表，把这个函数塞进任务表即可。具体每15秒走一遍，就是说有15秒的误差，无所谓的啦，反正连接没关，不影响使用。
那么你超时干啥呢？可以说一下不？或者他们超时干的啥？我的超时就干了一件事：
___SQL_CloseDatabase__(&rs->SQL_Connect);
他们的有我的简单吗？如果比我简单，我就得好好学一下。
【 在 slowaction 的大作中提到: 】
: 果然是十多年前的设计
: 没见过应该多学习
: 随便看一个连接池就知道超时是个非常普通的功能
你知道有个透明计算得了自然科学奖么
你这个一等奖有困难，二等奖应该有机会
【 在 ylh1969 的大作中提到: 】
: 哈，这是个遗留问题，内部变量，封装在模块内，与别人无关，就懒得改了。
: 再说这个程序本身并不是超时功能，只不过是低精度定时任务的一个嵌入模块。低精度定时线程才是你说的功能，那个线程里有个任务表，把这个函数塞进任务表即可。具体每15秒走一遍，就是说有15秒的误差，无所谓的啦，反正连接没关，不影响使用。
: 那么你超时干啥呢？可以说一下不？或者他们超时干的啥？
不用了，你可以拿我的方案去领奖。
题目就是“最简连接池健康管理方案”。
可以使用低精度定时器，对应用干扰很小，每15秒干扰一次很快结束。
如果保活方案，1~3秒干扰一次每个连接都要限时3秒（3秒也不一定可靠，数据库忙可能来不及回复导致误判）的等待回复，对应用干扰太大了。
这个方案理所当然的可以扩展到任何连接，不限于数据库。
实际上也被用到网络连接，一个3维网络连接池，包括了交易路由功能，容错功能，负载均衡功能。
【 在 slowaction 的大作中提到: 】
: 你知道有个透明计算得了自然科学奖么
: 你这个一等奖有困难，二等奖应该有机会
很多数据库驱动都提供连接池功能，你才发现？你out了
【 在 ylh1969 (没谱) 的大作中提到: 】
: 有一个提高效率的方法，完美解决了当年的数据库连接，长连接和短连接之争。
: 数据库连接句柄打开开销较大，一般需要30~40ms，如果在功能模块里开，性能降低一半不止。如果常开，在多线程服务器环境不合适。
: 所以采用了数据库连接池，虽然很多数据库提供了内建的连接池，那与我无关。
: 连接池在开始时是一个连接也不开。第一个使用者取用时打开一个连接，用完归还时，如果是正常归还，不关闭，就加到空闲队列头。下一次有人用就优先取已经打开的。因数据库致命故障归还的，就关闭，回收资源，放到队尾。
你怎么定义无用？
【 在 ylh1969 (没谱) 的大作中提到: 】
: 不是检查连接有效性，是检查连接的无用性。无用的连接关闭，不要占有资源。
: 打开的连接长时间不用就没法保证其可用性，夜长梦多，打开的连接，越长的时间不用，损坏的可能性越大。
: 如何你认为5分钟太长，可以缩短一些。这个时间等同于心跳时间间隔。
: 可以证明，与心跳周期容错效果相同，开销要小得多。
你见识太少了，只要是个连接池就有这个功能
【 在 ylh1969 (没谱) 的大作中提到: 】
: 用在连接池管理上的不多见，当年也是争议挺大的，直到证明超时间隔与心跳间隔等价，才平息了质疑。
: 如果连接一直在被使用，根本就不需要心跳。
: 【 在 slowaction 的大作中提到: 】
: : 空闲超时功能是个非常常见的功能
java的引用相当于指针的功能
【 在 ylh1969 (没谱) 的大作中提到: 】
: 我说的是C服务器。
: JAVA做服务器，有个困难。
: C有函数指针数组，服务器框架可以自定义服务函数加在函数表里即可。
: 客户端包头里指示出远过程函数号即可，JAVA没有指针，更没有函数指针。不知道怎么弄。
怎么可能几百个，有初始值和最大值的，初始化的时候只有10个，满了之后开新的，直到达到最大值，然后就是最早开启的先关闭
【 在 ylh1969 (没谱) 的大作中提到: 】
: 一个服务器，接几百个ATM，使用率非常之低。需要挂着几百个数据库连接，每分每秒的在进行大规模心跳操作？
: 【 在 KnightZorro 的大作中提到: 】
: : 这种逻辑如果跑在服务器, 完全应该用现成的java方案, 你说的都是常规操作
因为没必要保死，连接池的功能决定了的，你随用随开那没用连接池一样
【 在 ylh1969 (没谱) 的大作中提到: 】
: 不是发明，是采用，我喜欢用’采用’这个词。
: 但是没有发现采用保死策略的，都是保活的。
: 你知道哪个连接池使用保死策略的，请告知。
: 当年制定这个方案争议挺大的，所有人都坚持保活方案。
打开状态在空闲队列里呆的时间太长。
if(rs->SQL_Connect.dbh>-1 && (now-rs->timestamp)>299000000)
【 在 nikezhang 的大作中提到: 】
: 你怎么定义无用？
长链接也不是永久连接，最多几分钟
【 在 ylh1969 (没谱) 的大作中提到: 】
: 我说的是效率问题。
: 一直有个争论，大并发服务器环境下，长连接还是短连接。
: 长连接占用数据库连接太多，可靠性差，中途数据库故障处理麻烦。
: 短连接效率低，开关数据库开销大。
保死？哪个？
【 在 nikezhang 的大作中提到: 】
: 你见识太少了，只要是个连接池就有这个功能
只有常量才是全大写，你这个错误用法是谁教你的？
【 在 ylh1969 (没谱) 的大作中提到: 】
: 连接池大小和连接池数量都不是硬编码，那个大写的是变量。
: static int DBPOOLNUM=0;
: static pool *dbpool=0;
不呀，5分钟之内不关，密集应用数据库始终开的。5分钟都不来，来一次花50ms开一下数据库不过分吧？
【 在 nikezhang 的大作中提到: 】
: 因为没必要保死，连接池的功能决定了的，你随用随开那没用连接池一样
你这个超过5分钟不用就关闭就是连接池自带的超时关闭功能，你就别自己造轮子了
【 在 ylh1969 (没谱) 的大作中提到: 】
: 有一个提高效率的方法，完美解决了当年的数据库连接，长连接和短连接之争。
: 数据库连接句柄打开开销较大，一般需要30~40ms，如果在功能模块里开，性能降低一半不止。如果常开，在多线程服务器环境不合适。
: 所以采用了数据库连接池，虽然很多数据库提供了内建的连接池，那与我无关。
: 连接池在开始时是一个连接也不开。第一个使用者取用时打开一个连接，用完归还时，如果是正常归还，不关闭，就加到空闲队列头。下一次有人用就优先取已经打开的。因数据库致命故障归还的，就关闭，回收资源，放到队尾。
如果你还是现用现开，那和玩具写法的每次select之前先connect，select之后再close也没什么区别，根本不能叫做连接池
【 在 ylh1969 (没谱) 的大作中提到: 】
: 有一个提高效率的方法，完美解决了当年的数据库连接，长连接和短连接之争。
: 数据库连接句柄打开开销较大，一般需要30~40ms，如果在功能模块里开，性能降低一半不止。如果常开，在多线程服务器环境不合适。
: 所以采用了数据库连接池，虽然很多数据库提供了内建的连接池，那与我无关。
: 连接池在开始时是一个连接也不开。第一个使用者取用时打开一个连接，用完归还时，如果是正常归还，不关闭，就加到空闲队列头。下一次有人用就优先取已经打开的。因数据库致命故障归还的，就关闭，回收资源，放到队尾。
那就是说，都会关闭的？
就是你说的，保基础的10个？
我保0个。
当初的确有人提出保部分，这就麻烦了，这一部分就得心跳。
【 在 nikezhang 的大作中提到: 】
: 长链接也不是永久连接，最多几分钟
要保持基础可用的数量
保证响应速度
你估计连正规的连接池功能列表都没读过
弄了个超时功能当宝贝
【 在 ylh1969 的大作中提到: 】
: 那就是说，都会关闭的？
: 就是你说的，保基础的10个？
: 我保0个。
不一回事，目的不同。
我见过一个数据库，用连接池限制连接数，我们按50个连接买的，实际要有400个左右的终端用户。
还好有我们自己的应用服务器，连接池开30个连接，让400个终端排队使用。
自己的连接池还有一个作用，通过设置连接数，可以测出来在你的应用环境下几个连接系统吞吐量最高。
我们一个项目，计算密集型，3台32核服务器，实测结果，每台5个连接吞吐量最高。一台12核用作交易管理器。数据库是2台8核sparc，ORACLE RAC。
业务是管理器从数据库读出数据，分配给3个服务器96个线程进行计算，结果存入数据库。
【 在 nikezhang 的大作中提到: 】
: 很多数据库驱动都提供连接池功能，你才发现？你out了
按下标访问函数？
【 在 nikezhang 的大作中提到: 】
: java的引用相当于指针的功能
自我检讨
【 在 nikezhang 的大作中提到: 】
: 只有常量才是全大写，你这个错误用法是谁教你的？
设置成保留0个，超时关闭即可。
【 在 nikezhang 的大作中提到: 】
: 你这个超过5分钟不用就关闭就是连接池自带的超时关闭功能，你就别自己造轮子了
用别人的轮子我吃过大亏呀！
我的交易中间件里有一个传输压缩功能，原先自己写的，经过压力测试，很可靠，
后来发现一个quicklz，又快压缩比又高，就改用它了。
一个应用项目停车场吧，开始挺好。大概就是CPUID那个补丁后，造成频频死机，想了很多办法也没解决。最后项目夭折。过了很久，在一次压力测试偶然发现，关闭压缩就好了，压缩就过不了。后来换回自己的轮子，问题解决。可是项目没救了。
后来测一下，补丁前的系统没事，补丁后的不灵。没有继续追它的源码了，没心情，不用就行。
【 在 nikezhang 的大作中提到: 】
: 你这个超过5分钟不用就关闭就是连接池自带的超时关闭功能，你就别自己造轮子了
这都哪跟哪
限制连接数和连接池没有一毛钱的关系
【 在 ylh1969 的大作中提到: 】
: 不一回事，目的不同。
: 我见过一个数据库，用连接池限制连接数，我们按50个连接买的，实际要有400个左右的终端用户。
: 还好有我们自己的应用服务器，连接池开30个连接，让400个终端排队使用。
就是用连接池限制连接数呀，400个人一拥而上，不堵死数据库才怪呢，跟挤公共汽车似的。
我有连接池，就让30个人上，其余排队。数据库轻松多了，也可靠多了。
【 在 slowaction 的大作中提到: 】
: 这都哪跟哪
: 限制连接数和连接池没有一毛钱的关系
并发限制是个独立的约束
和连接池没有任何关系
【 在 ylh1969 的大作中提到: 】
: 就是用连接池限制连接数呀，400个人一拥而上，不堵死数据库才怪呢，跟挤公共汽车似的。
: 我有连接池，就让30个人上，其余排队。数据库轻松多了，也可靠多了。
不保。就超时关闭。保的你就得心跳，心跳就麻烦，就会对应用造成干扰，不心跳就无法保证在闲置期间数据库宕机后的有效性。
心跳就会使应用频繁的等待取连接（几秒钟一次的干扰），响应速度更慢。
【 在 slowaction 的大作中提到: 】
: 要保持基础可用的数量
: 保证响应速度
: 你估计连正规的连接池功能列表都没读过
连接池就是并发性资源约束手段。
【 在 slowaction 的大作中提到: 】
: 并发限制是个独立的约束
: 和连接池没有任何关系
谁告诉你的需要用连接池实现并发限制？
你这数据库就你这程序一个用户，
别的业务不许用这个数据库服务？
运维终端也不许连？
你这连基本概念都不清楚，还敢设计连接池
【 在 ylh1969 的大作中提到: 】
: 连接池就是并发性资源约束手段。
自己的连接池还有一个作用，通过设置连接数，可以测出来在你的应用环境下几个连接系统吞吐量最高。
我们一个项目，计算密集型，3台32核服务器，实测结果，每台5个连接吞吐量最高。一台12核用作交易管理器。数据库是2台8核sparc，ORACLE RAC。
业务是管理器从数据库读出数据，（也是通过连接池）分配给3个服务器96个线程进行计算，结果存入数据库。
原因如下：
一个管理器1个连接，3个服务器5*3=15个连接，共16个，恰好是数据库引擎2*8=16个。
多一个少一个吞吐量都低。
32线程抢5个数据库连接。正好应用服务器与数据库引擎都达到性能饱和。
【 在 slowaction 的大作中提到: 】
: 谁告诉你的需要用连接池实现并发限制？
: 你这数据库就你这程序一个用户，
: 别的业务不许用这个数据库服务？
你说的这个和连接池有什么关系？
你连连接池干什么用的都不知道
【 在 ylh1969 的大作中提到: 】
: 自己的连接池还有一个作用，通过设置连接数，可以测出来在你的应用环境下几个连接系统吞吐量最高。
: 我们一个项目，计算密集型，3台32核服务器，实测结果，每台5个连接吞吐量最高。一台12核用作交易管理器。数据库是2台8核sparc，ORACLE RAC。
: 业务是管理器从数据库读出数据，（也是通过连接池）分配给3个服务器96个线程进行计算，结果存入数据库。
我玩一辈子并发计算了。
并发度就是用连接池控制的。连接池负责并发数管理，交易路由管理，负载均衡，服务器容错。。。。。连接池是并发管理的基础部件。
32核服务器32个线程怎么控制的？连接池呀，每个服务器32个连接就是32个线程呀！多了少了吞吐量都低，可以测的。
容错也是它呀，哪个服务器有问题就关闭哪个连接，任务分配给别的服务器。恢复了再加回来实现自愈。
负载均衡也是它呀，空闲连接与总连接数的比值就是权重。LVS就是不知道这个比值所以分不均。
【 在 slowaction 的大作中提到: 】
: 谁告诉你的需要用连接池实现并发限制？
: 你这数据库就你这程序一个用户，
: 别的业务不许用这个数据库服务？
玩了一辈子还把超时时间写死在代码里？
还用全大写变量？
【 在 ylh1969 的大作中提到: 】
: 我玩一辈子并发计算了。
: 并发度就是用连接池控制的。连接池负责并发数管理，交易路由管理，负载均衡，服务器容错。。。。。连接池是并发管理的基础部件。
: 32核服务器32个线程怎么控制的？连接池呀，每个服务器32个连接就是32个线程呀！多了少了吞吐量都低，可以测的。
这都小意思，我做的是工具，用我的工具的不用关心这个。给配置文件徒增许多参数，使用者麻烦不麻烦呀！我追求的是极简。因为我懒。
超时时间是性能的不敏感值，没必要配置呀，说了多少遍了！
【 在 slowaction 的大作中提到: 】
: 玩了一辈子还把超时时间写死在代码里？
: 还用全大写变量？
负载均衡和容错，人们通常认为是两个无关功能，同事是这么说的。但是我看来就是一回事。
这两个都是高大上的题目，我就用100多行搞定，就用连接池。
开始用LVS，负载均衡，即搞不定均衡也搞不定容错，还老大老复杂了，配置维护极其麻烦，工作还不可靠。经常把连接请求分配到坏服务器去。
还是自己造轮子，完全透明免维护。
一个晋升工程师的，写了个论文“交路计算”，这程序是12306用的。我的程序，就3行，还比他的好用，可是怎么拿成绩呀，哎。。。。。。
【 在 slowaction 的大作中提到: 】
: 玩了一辈子还把超时时间写死在代码里？
: 还用全大写变量？
数据库当然是许多项目共用，所以才需要连接池呀！我这组3*32服务器，就用16个数据库连接，不然就得96个连接了吧！数据库引擎当然更有能力为别人服务啦！
而且，没任务的时候多，连接都关闭了岂不更好？
别人用不用连接池我管不着，我自己不用就撒手。
【 在 slowaction 的大作中提到: 】
: 谁告诉你的需要用连接池实现并发限制？
: 你这数据库就你这程序一个用户，
: 别的业务不许用这个数据库服务？
只第一次开，以后就一直保持，而且是最后释放的先分配，栈式。不忙的话尽量少开。
5分钟没人用才关闭。
【 在 nikezhang 的大作中提到: 】
: 如果你还是现用现开，那和玩具写法的每次select之前先connect，select之后再close也没什么区别，根本不能叫做连接池
我是最后归还的先分配。早归还的如果不用就先关闭。
【 在 nikezhang 的大作中提到: 】
: 怎么可能几百个，有初始值和最大值的，初始化的时候只有10个，满了之后开新的，直到达到最大值，然后就是最早开启的先关闭
我说你这个人怎么一点逻辑没有啊，我都说了，32个线程共用用5（可以配置数量）个数据库连接，不用连接池用啥呀！
我猜你是大学老师，怎么那么轴呀！把那些知识点分门分科特清楚，融会贯通不行呀。
一个模块完成一堆功能不行吗！
在单位的时候，每年毕业季单位招人都是我去挑人，你这么轴的肯定刷了。
我就可能出这种答辩题:
32个线程共用5个数据库连接，采用什么方法？
【 在 slowaction 的大作中提到: 】
: 你说的这个和连接池有什么关系？
: 你连连接池干什么用的都不知道
问题是他那个轮子有我的简单吗？他那么多功能我又不用，像心跳什么的，
【 在 nikezhang 的大作中提到: 】
: 你这个超过5分钟不用就关闭就是连接池自带的超时关闭功能，你就别自己造轮子了
以前你自己定义一个变量，变量名是MTU
然后在这里扯了好几天MTU如何如何
你的MTU说的是你的那个变量名，不是网络概念那个MTU
现在你连授权限制，并发链接都和连接池搅和到一起
你说的连接池是不是又是你定义的？
【 在 ylh1969 的大作中提到: 】
: 我说你这个人怎么一点逻辑没有啊，我都说了，32个线程共用用5（可以配置数量）个数据库连接，不用连接池用啥呀！
: 我猜你是大学老师，怎么那么轴呀！把那些知识点分门分科特清楚，融会贯通不行呀。
: 一个模块完成一堆功能不行吗！
果然是老师，知识点都是分章节的，互相没关系。
你给答一下，32个线程共享5个数据库连接，怎么办！
我给你答一个：我那个MTU是与网络MTU有关的。当年单位用了个IBM的PS2做路由器，很笨，不会分包。我的数据包如果一次发个大包就过不去，所以设了一个MTU（最大传输单元），每次write不超过这个数就能过，超了就过不去。现在可能没有这么low的路由器了。不过中间件还保留了这个参数在配置文件里，可以空，就不切片呗。我都不记得当年争论的是你。
【 在 slowaction 的大作中提到: 】
: 以前你自己定义一个变量，变量名是MTU
: 然后在这里扯了好几天MTU如何如何
: 你的MTU说的是你的那个变量名，不是网络概念那个MTU
第一次听说把连接池当并发控制用的，囧
另外，玩了很多年数据库，库的负载中纯连接池相关的占比很低呀
【 在 slowaction 的大作中提到: 】
: 以前你自己定义一个变量，变量名是MTU然后在这里扯了好几天MTU如何如何你的MTU说的是你的那个变量名，不是网络概念那个 ...
居然（我忘了这是清华大学的坛子，失敬）！大并发就是池呀，各种池各种队列。连接池线程池内存池。。。。。池+队列，就是并发手段呀！
我们做服务器时，一般采用每个连接一个线程（TPC）模式。
一个多核服务器，最佳线程数是核数。
那么TPC模式问题来了，成千上万的客户端来袭，会不会把服务器挤崩？每个线程要用栈呀！
你说怎样限制并发数呢？一个办法是线程池模式，这需要应用程序员懂得异步IO，人家搞业务的，这要求太高了吧？
我的解决办法，是前置一个小服务器，负责承载大量客户端的接入，以万计的。线程池模式。在客户端与服务器间转发数据。
它前端是万计的客户端，还要承担扛DDOS攻击，后端是若干台服务器，每个服务器多核，有限连接，有限线程。要求负载均衡，容错。某个服务器失效就要把负荷分配给其他服务器，恢复后可以重新加入。
那么，你怎样设计这个架构呢？
【 在 xiechuanhust 的大作中提到: 】
: 第一次听说把连接池当并发控制用的，囧
: 另外，玩了很多年数据库，库的负载中纯连接池相关的占比很低呀
做设计最烦你这种先自己瞎理解一遍，把自己堵到死胡同，然后说必须要跳墙才能解决的
你有32个输入，有5个输出
哪个老师告诉你必须用连接池的？
教你变量全大写那个老师么？
你的计算程序明显不应该去碰数据库写入这种io操作
32个计算去抢5个io锁，这完全是神经病
他应该把结果扔到一个队列，然后去跑自己的运算
然后用5个线程去消费这些队列
用不用连接池并不重要
【 在 ylh1969 的大作中提到: 】
: 果然是老师，知识点都是分章节的，互相没关系。
: 你给答一下，32个线程共享5个数据库连接，怎么办！
: 我给你答一个：我那个MTU是与网络MTU有关的。当年单位用了个IBM的PS2做路由器，很笨，不会分包。我的数据包如果一次发个大包就过不去，所以设了一个MTU（最大传输单元），每次write不超过这个数就能过，超了就过不去。现在可能没有这么low的路由器了。不过中间件还保留了这个参数在配置文件里，可以空，就不切片呗。我都不记得当年争论的是你。
那就是线程池呀，这个架构对应用程序员来说要求有点高（塞到队列里还要等结果怎么弄？）。
我是做框架工具的，为应用服务，我的架构比你的用法简单。
get
使用，随便调什么语句什么过程调几次，多自由啊！
release
完事，不需要应用程序员懂啥进程线程协程啥的。
【 在 slowaction 的大作中提到: 】
: 做设计最烦你这种先自己瞎理解一遍，把自己堵到死胡同，然后说必须要跳墙才能解决的
: 你有32个输入，有5个输出
: 哪个老师告诉你必须用连接池的？
我的是一个框架工具，没有和某个具体应用绑定，那个3*32服务器只是一个实例，OLTP的更多一些，那可是数据库密集型（连接数一般放工作线程数的一半），我的框架都适用。要求就是使用简单。可靠。
【 在 slowaction 的大作中提到: 】
: 做设计最烦你这种先自己瞎理解一遍，把自己堵到死胡同，然后说必须要跳墙才能解决的
: 你有32个输入，有5个输出
: 哪个老师告诉你必须用连接池的？
这和线程池没有关系
数据库许可的最高并发
资源决定的并发限制
连接池的大小
这三个是不同的概念，不能混为一谈
32个生产者和5个消费者的问题
应该用中间队列来把计算和io隔开
连接池不是用来解决多生产者和消费者的
你这属于基本概念都不清楚，自己造了狗皮膏药，随地乱贴
【 在 ylh1969 的大作中提到: 】
: 那就是线程池呀，这个架构对应用程序员来说要求有点高。
: 我是做框架工具的，为应用服务，我的架构比你的用法简单。
: get
哥们，你那5个线程不是线程池是什么！
【 在 slowaction 的大作中提到: 】
: 这和线程池没有关系
: 数据库许可的最高并发
: 资源决定的并发限制
是你念念不忘你的32服务器
来来回回提
【 在 ylh1969 的大作中提到: 】
: 我的是一个框架工具，没有和某个具体应用绑定，那个3*32服务器只是一个实例，OLTP的更多一些，那可是数据库密集型（连接数一般放工作线程数的一半），我的框架都适用。要求就是使用简单。可靠。
我从开始就有5个线程，每个线程自己一个数据库链接
这和线程池或者连接池有什么关系？
【 在 ylh1969 的大作中提到: 】
: 哥们，你那5个线程不是线程池是什么！
不是数据库许可的，是应用需求的，需求多少给多少。数据库好多项目用呢，我不能一个人都占了。
你把存数据库这事想简单了，存库不是一蹴而就的，需要许多操作的，不同线程还有不同流程一个任务队列只能干一种事，你那个想法实际上用不了。
【 在 slowaction 的大作中提到: 】
: 这和线程池没有关系
: 数据库许可的最高并发
: 资源决定的并发限制
我们开始也这样呀，出问题才加的连接池的。
作业过程，数据库引擎宕机了，服务器就死了，得重开数据库重开服务器，麻烦大了。
后来才搞得连接池，连接池健康出问题才搞得自愈，这都是一步一步赶出来的。你们就会理论到理论一点实践经验没有。我一个同事，大牛，就不来这里，说是一帮老师弄不出啥来。
【 在 slowaction 的大作中提到: 】
: 我从开始就有5个线程，每个线程自己一个数据库链接
: 这和线程池或者连接池有什么关系？
你先说，这是不是线程池？
【 在 ylh1969 的大作中提到: 】
: 我们开始也这样呀，出问题才加的连接池的。
: 作业过程，数据库引擎宕机了，服务器就死了，得重开数据库重开服务器，麻烦大了。
: 后来才搞得连接池，连接池健康出问题才搞得自愈，这都是一步一步赶出来的。你们就会理论到理论一点实践经验没有。我一个同事，大牛，就不来这里，说是一帮老师弄不出啥来。
你连连接池是干什么的都搞不清楚
【 在 ylh1969 的大作中提到: 】
: 我们开始也这样呀，出问题才加的连接池的。
: 作业过程，数据库引擎宕机了，服务器就死了，得重开数据库重开服务器，麻烦大了。
: 后来才搞得连接池，连接池健康出问题才搞得自愈，这都是一步一步赶出来的。你们就会理论到理论一点实践经验没有。我一个同事，大牛，就不来这里，说是一帮老师弄不出啥来。
你这能把超时时间写死在代码里的，就别吹了
【 在 ylh1969 的大作中提到: 】
: 不是数据库许可的，是应用需求的，需求多少给多少。数据库好多项目用呢，我不能一个人都占了。
: 你把存数据库这事想简单了，存库不是一蹴而就的，需要许多操作的，不同线程还有不同流程一个任务队列只能干一种事，你那个想法实际上用不了。
通用框架，做个例子，可以干计算密集型也可用于OLTP。
前者可以测一下几个连接最好，后者一般配置线程数的一半。
【 在 slowaction 的大作中提到: 】
: 是你念念不忘你的32服务器
: 来来回回提
这里说的是连接池。
线程池也搞，不过不是这个贴的主题。
你弄得5线程守候一个队列就是线程池呀。
对我的应用场景不适合，我的服务器功能很多，数据库用法五花八门，弄几个任务队列呢？。我的你如果什么项目要用你自己用好了。
【 在 slowaction 的大作中提到: 】
: 你先说，这是不是线程池？
前面说了，连接池可以干很多事。
这个数据库连接池只搞了共享连接，限制连接数和健康管理
在网络连接池，包括这些，再加上：
交易路由管理，负载均衡和容错。
【 在 slowaction 的大作中提到: 】
: 你连连接池是干什么的都搞不清楚
这是一个投产项目。是经过很多项目逐步发展起来的。这个数字是不需要改变的。没必要增加配置项，也没必要宏定义，就这一个地方用。
【 在 slowaction 的大作中提到: 】
: 你这能把超时时间写死在代码里的，就别吹了
你前面不说是框架工具，不和具体项目绑定么
你写了个值得单发个帖子的连接池，然后只能用于这个项目？
【 在 ylh1969 的大作中提到: 】
: 这是一个投产项目。是经过很多项目逐步发展起来的。这个数字是不需要改变的。
通用的呀，任何项目都可以用，也推荐大家用，所以才发。
【 在 slowaction 的大作中提到: 】
: 你前面不说是框架工具，不和具体项目绑定么
: 你写了个值得单发个帖子的连接池，然后只能用于这个项目？
哦，这不是一个投产项目，是一大堆投产项目。
不够严谨，抱歉。
你从那个程序，看出来与任何具体原因有关的内容吗？改到各位自己的环境谁都可以用呀。
【 在 slowaction 的大作中提到: 】
: 你前面不说是框架工具，不和具体项目绑定么
: 你写了个值得单发个帖子的连接池，然后只能用于这个项目？
没人会用一个不能配置超时时间的连接池
并且你这连接池还不保持最少可用连接
【 在 ylh1969 的大作中提到: 】
: 通用的呀，任何项目都可以用，也推荐大家用，所以才发。
一组或几组连接句柄，用于多个任务共享链接资源。
【 在 slowaction 的大作中提到: 】
: 你连连接池是干什么的都搞不清楚
保持最少可用连接就得保证这些连接可用，为了保证可用，就得心跳，你知道啥叫心跳吗？
为了心跳就得经常锁定空闲队列，心跳是秒级，心跳是很慢的，空闲队列锁定时间会很长，这期间应用会取不到资源，得等，会严重影响系统响应时间。
如果你有一个系统，可以试试 保活数量0，关闭时间5分钟，大并发压力测一下哪个配置响应快。
如果数据库忙（别人也用），心跳响应会慢，会误判。我们别的系统心跳误判导致的故障可多了。
所以我的方案彻底取消心跳。
事实上，我这个方案的系统平均响应时间比你快得多。
【 在 slowaction 的大作中提到: 】
: 没人会用一个不能配置超时时间的连接池
: 并且你这连接池还不保持最少可用连接
你最大的问题就是自己把自己限制死了
你那个教你变量全大写的老师教你的必须锁定空闲队列？
【 在 ylh1969 的大作中提到: 】
: 保持最少可用连接就得保证这些连接可用，为了保证可用，就得心跳，你知道啥叫心跳吗？
: 为了心跳就得经常锁定空闲队列，心跳是秒级，心跳是很慢的，空闲队列锁定时间会很长，这期间应用会取不到资源，得等，会严重影响系统响应时间。
: 事实上，我这个方案的系统平均响应时间比你快得多。
也可以把须跳的链接从空闲队列里取出来做心跳。但是依然是数据库负担。即使空闲也是1秒好几个请求的负担。数据库里还得搞个存储过程响应这些心跳。
做个压力测试吧，再做个数据库忙时压力测试。
【 在 slowaction 的大作中提到: 】
: 你最大的问题就是自己把自己限制死了
: 你那个教你变量全大写的老师教你的必须锁定空闲队列？
好多个非常清晰的概念，应该在设计的时候分别实现的功能
被你搞成一坨烂泥
【 在 ylh1969 的大作中提到: 】
: 做个压力测试吧，再做个数据库忙时压力测试。
谢谢老师，你的学生我不会收的。
我们是企业，要的是功能不关心概念。术语概念听听就好，黑猫白猫，抓住耗子就是好猫。没时间评价抓耗子的动作符合哪条定理。
我们就是土，弄个泛型的序列化反序列化函数，是整个交易中间件核心系统，就叫个打包拆包程序。
【 在 slowaction 的大作中提到: 】
: 好多个非常清晰的概念，应该在设计的时候分别实现的功能
: 被你搞成一坨烂泥
对了，作压力测试时可以加一个鲁棒性测试，在最大压力时断开数据库 ，一会儿再恢复，，看看你的应用能活过来不。这个做不到，一大堆概念何用。
【 在 slowaction 的大作中提到: 】
: 好多个非常清晰的概念，应该在设计的时候分别实现的功能
: 被你搞成一坨烂泥
方案设计期间有这个讨论，要不要保活一部分，那就需要管理高水位低水位，是否必要动态增加连接数问题。这需要外部干涉服务器的运行。
这太麻烦了，既然能够测出最佳连接数，高水位就是它，低水位就是0，增加连接数并不能提高系统吞吐量，那就不加。不需要的功能砍，得到最简管理方案，也是最可靠，吞吐量最大，响应时间最快的方案。我懒。赞成马斯克造车，能砍的都砍。
【 在 slowaction 的大作中提到: 】
: 没人会用一个不能配置超时时间的连接池
: 并且你这连接池还不保持最少可用连接
10年前都有这机制了！
怕学生进去嘲笑你变量全大写？
嘲笑连接池超时时间不能配置？
【 在 ylh1969 的大作中提到: 】
: 谢谢老师，你的学生我不会收的。
: 我们是企业，要的是功能不关心概念。术语概念听听就好，黑猫白猫，抓住耗子就是好猫。没时间评价抓耗子的动作符合哪条定理。
: 我们就是土，弄个泛型的序列化反序列化函数，是整个交易中间件核心系统，就叫个打包拆包程序。
20年前就用了。
【 在 fairyaz 的大作中提到: 】
: 10年前都有这机制了！
30楼的程序，你知道为啥用二维数据库连接池吗？
多个池，各自有不同的连接数。
来源是，铁路售票服务器。一个业务服务器为各个业务部门所用。
春运时，抢票那是非常紧张，各级业务部门也非常关心自己范围的业绩，经常会要进行实时进度统计，这个统计会严重影响前台售票作业。一度禁止在业务高峰进行统计分析作业。可是人们就是需要这时候查看呀，怎么解决？
这时候连接池上手了。建立若干用户角色，比方，售票业务，调度业务，账务业务，营销管理，每个角色对各个表有不同的权限。每个池按一个用户角色登录数据库，配给不同数量的连接数。
登录服务器的前端用户按门分类，给一个证书，证书里有一个DBLABEL，这个DBLABEL确定它可以使用哪个数据库连接池。
假如这么安排，售票池40个连接，调度池4个连接，账务3个，管理3（业务紧张时1）个。
这样管理团队就可以随便查询啦，不管多少管理客户端，排队使用这个池即可，不会对繁忙的售票业务造成过大干扰。愿意安排多少作业点由业务部门定，我们不管，反正资源就这么多了。
【 在 slowaction 的大作中提到: 】
: 你连连接池是干什么的都搞不清楚
越说越暴露你不知道连接池干什么用的
统计消耗性能，你用连接池有毛用
【 在 ylh1969 的大作中提到: 】
: 30楼的程序，你知道为啥用二维数据库连接池吗？
: 多个池，各自有不同的连接数。
: 来源是，铁路售票服务器。一个业务服务器为各个业务部门所用。
越发说明你们做题行，解决问题不行。
【 在 slowaction 的大作中提到: 】
: 越说越暴露你不知道连接池干什么用的
: 统计消耗性能，你用连接池有毛用
来源是，铁路售票服务器。一个业务服务器为各个业务部门所用。
春运时，抢票那是非常紧张，各级业务部门也非常关心自己范围的业绩，经常会要进行实时进度统计，这个统计会严重影响前台售票作业。一度禁止在业务高峰进行统计分析作业。可是人们就是需要这时候查看呀，怎么解决？
这时候连接池上手了。建立若干用户角色，比方，售票业务，调度业务，账务业务，营销管理，每个角色对各个表有不同的权限。每个池按一个用户角色登录数据库，配给不同数量的连接数。
登录服务器的前端用户按门分类，给一个证书，证书里有一个DBLABEL，这个DBLABEL确定它可以使用哪个数据库连接池。
假如这么安排，售票池40个连接，调度池4个连接，账务3个，管理3（业务紧张时1）个。
这样管理团队就可以随便查询啦，不管多少管理客户端，排队使用这个池即可，不会对繁忙的售票业务造成过大干扰。愿意安排多少作业点由业务部门定，我们不管，反正资源就这么多了。
那时候售票端400多，调度十来个，账务十来个，管理也不少路局的，分局的，客票中心的，各站的。。。随便多少，想统计就统计，出不来结果等着呗。
你明白连接池怎么用了吗？
你就知道个连接池的概念，然后认为他什么问题都能解决
统计慢你也指望连接池，一脑袋浆糊
【 在 ylh1969 的大作中提到: 】
: 越发说明你们做题行，解决问题不行。
: 来源是，铁路售票服务器。一个业务服务器为各个业务部门所用。
: 春运时，抢票那是非常紧张，各级业务部门也非常关心自己范围的业绩，经常会要进行实时进度统计，这个统计会严重影响前台售票作业。一度禁止在业务高峰进行统计分析作业。可是人们就是需要这时候查看呀，怎么解决？
你这啥也不懂，
统计功能会锁表会有大量的计算和内存占用
你用连接池有鸡毛用
【 在 ylh1969 的大作中提到: 】
: 越发说明你们做题行，解决问题不行。
: 来源是，铁路售票服务器。一个业务服务器为各个业务部门所用。
: 春运时，抢票那是非常紧张，各级业务部门也非常关心自己范围的业绩，经常会要进行实时进度统计，这个统计会严重影响前台售票作业。一度禁止在业务高峰进行统计分析作业。可是人们就是需要这时候查看呀，怎么解决？
只给他1~3个连接，10个人要统计也只有这几个任务在干，其他排队等着，10个人来统计估计这机器会死。
【 在 slowaction 的大作中提到: 】
: 你这啥也不懂，
: 统计功能会锁表会有大量的计算和内存占用
: 你用连接池有鸡毛用
你是不是认为给统计的1个链接，给卖票的100个链接
统计的就不会影响卖票了？
数据库负荷和链接有什么关系
你这明显啥也不懂，说的越多约露怯
【 在 ylh1969 的大作中提到: 】
: 只给他1~3个连接，10个人要统计也只有这几个任务在干，其他排队等着，10个人来统计估计这机器会死。
更说明你脑子非常轴。
连接池做配给制呀，像极了银行的***，分字头配窗口。
事实上并不是上一个统计就干不了活，但是上多了肯定不行。就这个道理。
实时统计，写程序的懂，脏读，对售票影响小。所以会出现查票有买票无的情况。
【 在 slowaction 的大作中提到: 】
: 你是不是认为给统计的1个链接，给卖票的100个链接
: 统计的就不会影响卖票了？
: 数据库负荷和链接有什么关系
数据库负荷和他用多少个链接没关系
和连接池也没关系
你就知道个连接池，举了两个例子都裸唇不对马嘴
整个版的水平都被你拉低了
【 在 ylh1969 的大作中提到: 】
: 更说明你脑子非常轴。
: 连接池做配给制呀，像极了银行的，
: 实时统计，写程序的懂，脏读，对售票影响小。所以会出现查票有买票无的情况。
这次我虚心向你请教。
1.连接池的定义。
2.它的适用场合。
3.所起的作用。
我是恢复高考第一届的计算机专业，真没学过连接池。几十年就在运输生产第一线摸爬滚打，理论知识明显不足，请见谅。
【 在 slowaction 的大作中提到: 】
: 越说越暴露你不知道连接池干什么用的
: 统计消耗性能，你用连接池有毛用
连接池解决频繁连接和断开数据库的开销和时延问题
首先，他只能解决连接的速度问题，不能解决数据库操作的负荷问题。
你说的统计场景，他一个做分析的业务能干出1000个普通查询的性能消耗。所以限制他的连接数几乎不解决任何问题。
这种场景应该读写分开，必要的时候复制一个离线库给统计用。
连接池适用于多个消费者，但是他并不需要时刻操作数据库的场景。
比如你说的购票场景，乘客用12306.只有他查询的时候，他读一下数据库，其他时候他看车次，选择车次的时候，不需要持有数据库链接。这个场景可能几百个乘客对应一个链接就够用。这时候要保证有空闲连接可以随时使用。不能让乘客等着建立新链接。
【 在 ylh1969 的大作中提到: 】
: 这次我虚心向你请教。
: 1.连接池的定义。
: 2.它的适用场合。
定义？我前边100楼说的对吗？包括但不限于数据库。
【 在 slowaction 的大作中提到: 】
: 连接池解决频繁连接和断开数据库的开销和时延问题
: 首先，他只能解决连接的速度问题，不能解决数据库操作的负荷问题。
: 你说的统计场景，他一个做分析的业务能干出1000个普通查询的性能消耗。所以限制他的连接数几乎不解决任何问题。
共享不是他的核心特征
他的核心特征是不实时创建和不实时关闭，用个缓冲池来动态管理
最大空闲时间是他的基本参数
所以你说的自愈，这是连接池的基本参数
【 在 ylh1969 的大作中提到: 】
: 定义？我前边100楼说的对吗？包括但不限于数据库。
好的。但是问题不是绝对的。我可以做到基本不实时创建和销毁连接。长时间静默后的连接请求，创建一下，开销30～50ms，不过分吧，后续的请求都不用这个开销啦。如果整个系统5分钟都没有一个请求，关闭它也不是什么了不得的开销，对吧？就算整个系统5分钟一个请求，消耗50ms也没问题吧？因为sql数据库本身不是实时系统，任何操作都不保证时间，oltp只是以人的反应速度为参照，多50ms少50ms不会有感觉。
【 在 slowaction 的大作中提到: 】
: 共享不是他的核心特征
: 他的核心特征是不实时创建和不实时关闭，用个缓冲池来动态管理
: 最大空闲时间是他的基本参数
你可以保留一定的空闲连接
这并不需要你说的什么心跳
超时了你关了，然后在开一部分，
你不维护，
和你的超时关闭是一个逻辑
【 在 ylh1969 的大作中提到: 】
: 好的。但是问题不是绝对的。我可以做到基本不实时创建和销毁连接。长时间静默后的连接请求，创建一下，开销30～50ms，不过分吧，后续的请求都不用这个开销啦。如果整个系统5分钟都没有一个请求，关闭它也不是什么了不得的开销，对吧？就算整个系统5分钟一个请求，消耗50ms也没问题吧？因为sql数据库本身不是实时系统，任何操作都不保证时间，oltp只是以人的反应速度为参照，多50ms少50ms不会有感觉。
查了一下，跟你说的基本一致。后边有：
不止数据库，Redis、HTTP、RPC等所有基于TCP长连接的客户端，都有对应连接池，底层逻辑完全一致：复用TCP连接，限制并发连接总数。
就是说，有限制并发连接数的功能。我就是从这个需求开始搞连接池，就像猫捉老鼠，该窜就窜出去了，没有考虑用哪条物理定律计算一下。
【 在 slowaction 的大作中提到: 】
: 共享不是他的核心特征
: 他的核心特征是不实时创建和不实时关闭，用个缓冲池来动态管理
: 最大空闲时间是他的基本参数
不保留又怎么样，oltp场合谁会在意那50ms呢！医保的终端点一下半天没反应你不是也没辙吗？
【 在 slowaction 的大作中提到: 】
: 你可以保留一定的空闲连接
: 这并不需要你说的什么心跳
: 超时了你关了，然后在开一部分，
连接池核心需求就是不需要实时建立连接
你不在乎，你折腾连接池干什么
【 在 ylh1969 的大作中提到: 】
: 不保留又怎么样，oltp场合谁会在意那50ms呢！医保的终端点一下半天没反应你不是也没辙吗？
作业密度高时就在乎，作业密度低时就不在乎。问题不是绝对的，是有条件的。
如果整个系统5分钟都没有一个请求，那就不在乎。如果一秒钟一万个请求就在乎，就需要控制，只准一部分人先富起来，其余排队。
我折腾连接池就为了限制并发度呀，任何并发系统都有最佳并行度，连接池就是最简单的控制并发度的工具呀，我懒。
如果5分钟以内总是有一个请求，那就自动保持一个连接，懂了吗？自动保持部分连接的工作不需要我做呀，我懒。你勤快你做一个客户端，1分钟打服务器一拳。
【 在 slowaction 的大作中提到: 】
: 连接池核心需求就是不需要实时建立连接
: 你不在乎，你折腾连接池干什么
你就这业务理解还做交易的？
股票开市前和开市后查询量差好多个数量级
火车票是定点放票，也会有时点爆发
【 在 ylh1969 的大作中提到: 】
: 作业密度高时就在乎，作业密度低时就不在乎。问题不是绝对的，是有条件的。
: 如果整个系统5分钟都没有一个请求，那就不在乎。如果一秒钟一万个请求就在乎，就需要控制，只准一部分人先富起来，其余排队。
: 我折腾连接池就为了限制并发度呀，任何并发系统都有最佳并行度，连接池就是最简单的控制并发度的工具呀，我懒。
对呀，我的方案就是为了解决这个问题呀，密集交易来临，连接就不会关闭呀！
密集交易来临就必须限制并行度达到系统最佳吞吐量，过高的并行度吞吐量会下降，甚至会憋死数据库。
就像车到站，乱挤谁也上不去。
12306最后解决问题就靠池和队呀。
【 在 slowaction 的大作中提到: 】
: 你就这业务理解还做交易的？
: 股票开市前和开市后查询量差好多个数量级
: 火车票是定点放票，也会有时点爆发
时点的时候，你的连接池是空的
你没解决任何问题
【 在 ylh1969 的大作中提到: 】
: 对呀，我的方案就是为了解决这个问题呀，密集交易来临，连接就不会关闭呀！
连接用完排队呀！归还一个上一个。池和队是配套设施。这里没讨论队就是了，那个没什么好讨论的。
排着队上是最快的，一拥而上死的快。
【 在 slowaction 的大作中提到: 】
: 时点的时候，你的连接池是空的
: 你没解决任何问题
需要你发挥作用的时候，你退化成没有连接池了
不需要你的时候，你这个那个好像挺厉害
实际没有毛用
交易系统就是要抗住时点并发，
其他时候，没有性能要求
【 在 ylh1969 的大作中提到: 】
: 连接用完排队呀！归还一个上一个。
你怎么没逻辑呀，谁说的有队就没池啦！
归还连接时，給队发个signal不行吗！（这也就是我为啥造轮子，通用的连接池不会给我的队列发signal）。
还要我给你讲讲池和队的衔接逻辑吗？
你就这点逻辑水平，你的学生可咋办呀，愁死了。
【 在 slowaction 的大作中提到: 】
: 需要你发挥作用的时候，你退化成没有连接池了
: 不需要你的时候，你这个那个好像挺厉害
: 实际没有毛用
时点来临的时候，你的连接池是空的
就这一点，你这设计就是废物
【 在 ylh1969 的大作中提到: 】
: 你怎么没逻辑呀，谁说的有队就没池啦！
: 归还连接时，給队发个signal不行吗！（这也就是我为啥造轮子，通用的连接池不会给我的队列发signal）。
: 还要我给你讲讲池和队的衔接逻辑吗？
你的回答总是出乎我意料，我就是解决高峰并发的呀，这个方案完美解决高峰并发，oltp和OLAP并发问题。系统运行极其平稳。
【 在 slowaction 的大作中提到: 】
: 需要你发挥作用的时候，你退化成没有连接池了
: 不需要你的时候，你这个那个好像挺厉害
: 实际没有毛用
所谓空就是忙，所有的连接都在忙，池才会空，这就是系统最大吞吐量，不能再增加了，再加系统会变慢。
一个任务完成，就归还连接下一个任务上，有序queue就是最快的。
不懂你的时点是啥，大概是我们说的业务峰值。
【 在 slowaction 的大作中提到: 】
: 时点来临的时候，你的连接池是空的
: 就这一点，你这设计就是废物
时点来的时候，你的连接池是不是空的？
你是不是要新建很多连接
讨论个技术问题不需要东拉西扯
从你用全大写的变量就知道你的水平
细节问题能处理好的程序，未必是个好程序
但是用全大写变量和写死超时时间这种错误都会范，那绝对是个烂程序
【 在 ylh1969 的大作中提到: 】
: 你的回答总是出乎我意料，我就是解决高峰并发的呀，这个方案完美解决高峰并发，oltp和OLAP并发问题。系统运行极其平稳。
什么叫时点？
任何时候都不需要建立新链接，空了后续任务只需要排队。有归还连接时就上一个。
OLTP交易都非常短，毫秒级就归还连接，连接周转非常之快。在输入参数时，不需要服务器。参数收齐才找服务器，发出业务请求，服务器才取数据库连接，干完了马上归还，这期间一般毫秒级，然后向客户端返回信息。几千个客户端用几十个连接就够。用完也不会增加新连接，新的网络请求连接池没有就进入队列，直到排到取得连接。
数据库是有一定并行能力的，少量olap可以与OLTP并行的。
我就是用连接池的限制并行度的能力，限制olap的数量，就可以减少对OLTP的影响。各单位可以在业务繁忙时统计，等着别着急慢慢来。
【 在 slowaction 的大作中提到: 】
: 时点来的时候，你的连接池是不是空的？
: 你是不是要新建很多连接
: 讨论个技术问题不需要东拉西扯
139楼推荐给各位看官。
“细节问题能处理好的程序，未必是个好程序
但是用全大写变量和写死超时时间这种错误都会范，那绝对是个烂程序”
这句话经典。
会捉老鼠的猫，未必是好猫，不漂亮的猫绝对是烂猫。这就是教育的问题所在。
企业要的是会捉老鼠的猫，你们给的是漂亮猫。
不喜欢你这样老师的学生，不是怕他指出我的错误，我的问题明摆着他能指出来我会很赞赏，给他加分，我不喜欢的是，他没有逻辑，不会融会贯通举一反三。可能在看到老鼠时还在解偏微分方程。
教育与生产脱节，是最大的问题。
【 在 slowaction 的大作中提到: 】
: 时点来的时候，你的连接池是不是空的？
: 你是不是要新建很多连接
: 讨论个技术问题不需要东拉西扯
你拿个所有连接池都有的超时时间配置参数当宝贝一样
你这已经不是脱节的问题了，是已经被淘汰了
【 在 ylh1969 的大作中提到: 】
: 139楼推荐给各位看官。
: “细节问题能处理好的程序，未必是个好程序
: 但是用全大写变量和写死超时时间这种错误都会范，那绝对是个烂程序”
我的是最简设计，不是加法是减法，告诉你可以减少什么可以使系统的性能更高，工作更可靠。
保留的活连接可以砍掉，心跳可以砍掉。可设置的超时参数可以没有，大量的参数取消，简化连接池的配置管理，整个系统完全免维护，具有极强的鲁棒性。
这些你都没看懂，老师白当了。
你需要的参数，活连接的最低值，连接的上限，连接的扩展上限，连接耗尽时的队列长度，任务在队列中最长等待时限，心跳周期，心跳等待回复的时限，空闲超时时限。統统砍掉，使用者不需要理解这些。用不着的功能根本不写，我懒。
【 在 slowaction 的大作中提到: 】
: 你拿个所有连接池都有的超时时间配置参数当宝贝一样
: 你这已经不是脱节的问题了，是已经被淘汰了
首先，你基本功非常差，用全大写的变量和不能配置的参数
其次，你把一个任何一个连接池都带的超时参数，认为非常有价值，完全不了解技术发展
最后，你对业务的理解也非常差，认为统计类业务可以用限制他的连接数来限制他对数据库的负荷
只会像孔乙己一样的讲似是而非的大道理
这是一个被技术淘汰的人的典型特征
【 在 ylh1969 的大作中提到: 】
: 我的是最简设计，不是加法是减法，告诉你可以减少什么可以使系统的性能更高，工作更可靠。
: 保留的活连接可以砍掉，心跳可以砍掉。可设置的超时参数可以没有，大量的参数取消，简化连接池的配置管理，整个系统完全免维护，具有极强的鲁棒性。
: 这些你都没看懂，老师白当了。
一个任何一个连接池都带的超时参数，我认为非常没有价值，固定即可。
这个参数对系统吞吐量，系统延时，系统鲁棒性完全没有意义。
其他时间参数及其它参数完全不需要。那些有害无益的功能都砍掉。是对现有技术的最优简化。
大道至简，这个道理你不懂，所以你们教出来的学生落后于时代。教育落后时代至少10年，以至于华为腾讯阿里要自己办学校了，现在的毕业生，企业真用不了。
我自己也是，来到企业，学过的东西2%有用的都没有，一年之内全面知识更新才能胜任工作。
你再看看143楼，我编辑过了。
【 在 slowaction 的大作中提到: 】
: 首先，你基本功非常差，用全大写的变量和不能配置的参数
: 其次，你把一个任何一个连接池都带的超时参数，认为非常有价值，完全不了解技术发展
: 最后，你对业务的理解也非常差，认为统计类业务可以用限制他的连接数来限制他对数据库的负荷
看看这个帖子的标题
任何一个实现都带的功能，你发篇长文，好像实现了什么了不起的东西
你不感觉可笑么
【 在 ylh1969 的大作中提到: 】
: 一个任何一个连接池都带的超时参数，我认为非常没有价值，固定即可。
: 这个参数对系统吞吐量，系统延时，系统鲁棒性完全没有意义。
: 其他时间参数及其它参数完全不需要。那些有害无益的功能都砍掉。是对现有技术的最优简化。
你几乎每个帖子都编辑
你已经老了
【 在 ylh1969 的大作中提到: 】
: 一个任何一个连接池都带的超时参数，我认为非常没有价值，固定即可。
: 这个参数对系统吞吐量，系统延时，系统鲁棒性完全没有意义。
: 其他时间参数及其它参数完全不需要。那些有害无益的功能都砍掉。是对现有技术的最优简化。
大家回复我才知道，你们那个系统，原来可以优化掉那么多东西。当然许多参数当年也知道，包括部分活连接，当年争论过才砍掉的。
【 在 slowaction 的大作中提到: 】
: 看看这个帖子的标题
: 任何一个实现都带的功能，你发篇长文，好像实现了什么了不起的东西
: 你不感觉可笑么
你坚持你的300秒不需要修改
请问如果你的数据库管理员把连接超时配置了240秒，你怎么办
【 在 ylh1969 的大作中提到: 】
: 一个任何一个连接池都带的超时参数，我认为非常没有价值，固定即可。
: 这个参数对系统吞吐量，系统延时，系统鲁棒性完全没有意义。
: 其他时间参数及其它参数完全不需要。那些有害无益的功能都砍掉。是对现有技术的最优简化。
加上配置没有难度，加上就是，不是讨论的根本节点。
FREE_LINK_TIMEOUT=300。
程序里加一个getenv()配个参数即可以了
【 在 slowaction 的大作中提到: 】
: 你坚持你的300秒不需要修改
: 请问如果你的数据库管理员把连接超时配置了240秒，你怎么办
这个网站只有在发表成功之后再次修改才会显示有修改
因为敏感词没发成功，修改敏感词后发表，并不会显示修改
所以显示修改和敏感词没关系
【 在 ylh1969 的大作中提到: 】
: 敏感词太多，经过多次编辑才能发出来。
你前面不是还斩钉截铁的说不需要配置么，300秒包打天下？
这个那个一堆理论，极简设计之类的
管理员通知，他改了配置到240秒
你去和他说你的极简理论吧
你知不知道你非常可笑
【 在 ylh1969 的大作中提到: 】
: 加上配置没有难度，加上就是，不是讨论的根本节点。
蠢才
变量不能用全大写
【 在 ylh1969 的大作中提到: 】
: 加上配置没有难度，加上就是，不是讨论的根本节点。
: FREE_LINK_TIMEOUT=300。
: 程序里加一个getenv()配个参数即可以了
发帖失败，所以只能先少写点，一点点加。后编辑的失败后可以再改，所以后续内容很慢。
发回复时只能少写。被拒绝就不好弄了。
【 在 slowaction 的大作中提到: 】
: 这个网站只有在发表成功之后再次修改才会显示有修改
: 因为敏感词没发成功，修改敏感词后发表，并不会显示修改
: 所以显示修改和敏感词没关系
语法没有这个规定。
我们讨论的是方法，我又没让你用我的程序。你如果写程序随便你怎么写。
【 在 slowaction 的大作中提到: 】
: 蠢才
: 变量不能用全大写
他会征求我的意见。
你认为需要加上就是了，有那么难吗？
我们讨论的是算法，你说的问题存在，都是细枝末节，不难改吧？
值得争论的问题是，要不要保留部分活连接，实践来看，不需要。这能省很多事。我懒。
【 在 slowaction 的大作中提到: 】
: 你前面不是还斩钉截铁的说不需要配置么，300秒包打天下？
: 这个那个一堆理论，极简设计之类的
: 管理员通知，他改了配置到240秒
好的设计就是兼容各种场景的
如果是可以配置的，现场改个配置文件，有时候都不需要重新启动程序
你写死了，就需要从新编译发版本，
这事超级麻烦
你前面几十篇帖子信誓旦旦不需要修改，
不是难不难，
而是你太自以为是，这么明显的问题都看不到
那些大道理从你嘴里说出来，让人笑掉大牙
【 在 ylh1969 的大作中提到: 】
: 他会征求我的意见。
: 你认为需要加上就是了，有那么难吗？
贴段程序，本来想露脸，屁股漏出来了
【 在 ylh1969 的大作中提到: 】
: 语法没有这个规定。
: 我们讨论的是方法，我又没让你用我的程序。你如果写程序随便你怎么写。
你连个超时时间需要配置这事都搞不明白
没资格讨论其他问题
【 在 ylh1969 的大作中提到: 】
: 他会征求我的意见。
: 你认为需要加上就是了，有那么难吗？
: 我们讨论的是算法，你说的问题存在，都是细枝末节，不难改吧？
你前面还说实践看来不需要改超时时间呢
你的实践经验看起来毛用没有
【 在 ylh1969 的大作中提到: 】
: 他会征求我的意见。
: 你认为需要加上就是了，有那么难吗？
: 我们讨论的是算法，你说的问题存在，都是细枝末节，不难改吧？
告诉大家，连接池健康管理，原来可以这么简单。
你也可以这么简单不足之处你自己改就行了，保留活连接的事，可以省，省了就减少很多麻烦。
核心是保死还是保活的争论，其他都是细枝末节。
【 在 slowaction 的大作中提到: 】
: 贴段程序，本来想露脸，屁股漏出来了
你想告诉别人的东西
所有的连接池都有，并且是可配置的，那个变量还是小写
【 在 ylh1969 的大作中提到: 】
: 告诉大家，连接池健康管理，原来可以这么简单。
: 你也可以这么简单不足之处你自己改就行了，保留活连接的事，可以省，省了就减少很多麻烦。
: 核心是保死还是保活的争论，其他都是细枝末节。
只能说明，我的连接池健康管理策略，连你这么轴的都能看懂。
想加啥你就加呗，想用啥变量你就用，我又没让你用我的程序。
我的是极简，你看看还能简化啥。至于需要加啥，你自己加。
【 在 slowaction 的大作中提到: 】
: 你想告诉别人的东西
: 所有的连接池都有，并且是可配置的，那个变量还是小写
我想告诉别人的东西，是可以减什么。至于有人认为不能减的，就不减。这没什么好说的。
【 在 slowaction 的大作中提到: 】
: 你想告诉别人的东西
: 所有的连接池都有，并且是可配置的，那个变量还是小写
咋咋呼呼贴段程序
结果全是毛病，
连超时时间需要配置这事都嘴硬几十篇帖子说300秒不用修改，还极简设计。
太丢人了。
全部c程序员的档次都被你拉低了
【 在 ylh1969 的大作中提到: 】
: 只能说明，我的连接池健康管理策略，连你这么轴的都能看懂。
: 想加啥你就加呗，想用啥变量你就用，我又没让你用我的程序。
: 我的是极简，你看看还能简化啥。至于需要加啥，你自己加。
现在的教育，落后十年了，就你这思维模式
【 在 slowaction 的大作中提到: 】
: 咋咋呼呼贴段程序
: 结果全是毛病，
: 连超时时间需要配置这事都嘴硬几十篇帖子说300秒不用修改，还极简设计。
可以减什么？
减了超时了时间可以配置
结果现场数据库改配置，自己傻了吧
【 在 ylh1969 的大作中提到: 】
: 我想告诉别人的东西，是可以减什么。至于有人认为不能减的，就不减。这没什么好说的。
你从头到尾贴程序 举场景 讲理论
没有一次站的住脚
就剩无病呻吟了。
鲁迅有个小说里有个九斤老太太，你应该去看一下
那是你的前辈
【 在 ylh1969 的大作中提到: 】
: 现在的教育，落后十年了，就你这思维模式
因为你一直嘴硬说不需要改，还极简
年纪大了，水平还这么差，就别谈具体问题了
空对空的扯点纯理论就行了
【 在 ylh1969 的大作中提到: 】
: 想加啥你就加，这点事跟祥林嫂似的说八百遍。
: 关键是不保活，可以大幅度提高数据库的效率。
你早这么讨论多好
夸夸其谈没人在意的
自己非要帖段代码，暴露出自己特别菜，自讨苦吃
【 在 ylh1969 的大作中提到: 】
: 讨论没有意义了。
: 告诉大家，连接池健康管理，原来可以这么简单。
: 你也可以这么简单不足之处你自己改就行了，保留活连接的事，可以省，省了就减少很多麻烦。
140楼你还没有回答。
【 在 slowaction 的大作中提到: 】
: 你早这么讨论多好
: 夸夸其谈没人在意的
: 自己非要帖段代码，暴露出自己特别菜，自讨苦吃
实践中没有这种情况，事物要发展的看。最开始的做法是长连接，业务终端永远连接，不管有没有业务。这种情况怎么可能数据库 主动超时断联！发展到连接池技术，为什么要凭空搞这个！哪个理论要求的，哪个老师教你的！
后来因为长连接数据库负担太大，竞争过于激烈，导致崩溃风险过高，这样就产生了约束控制数据库并行连接数的需求，搞了连接池。你连 连接池约束并行度的功能都不知道，回去改改你的教案吧。
这个算法用了10年也没人提出修改超时参数的需求。如果谁用了这个方法，需要改，那他就加上，这根本不是技术问题，你拿这个揪住不放，显得你高明是不是？恰恰看出你思维逻辑混乱，毫无实践经验，抓不住注意矛盾，解决不了问题的关键。是一只抓不住耗子的宠物猫。
【 在 slowaction 的大作中提到: 】
: 可以减什么？
: 减了超时了时间可以配置
: 结果现场数据库改配置，自己傻了吧
这段代码就是说明，这个参数不需要改，经过多年实践，没有改的必要。
设计数据库超时断联就是因为有太多连接占着茅坑不拉屎。
连接池已经解决这个问题，所以这个设置不必要。哪个DBA提出来要设置，不能随便来吧，必须要讨论的吧，讨论结果需要满足方方面面的需求吧？我方需求6分钟以上，某方说必须240秒，他要说出理由，如果必要，我改程序。这一切都由项目协调机构决定。
【 在 slowaction 的大作中提到: 】
: 你早这么讨论多好
: 夸夸其谈没人在意的
: 自己非要帖段代码，暴露出自己特别菜，自讨苦吃
你在这里长篇大论两配置参数写死的合理性
只能证明
1.你老了
2.现实生活没人搭理你
【 在 ylh1969 的大作中提到: 】
: 这段代码就是说明，这个参数不需要改，经过多年实践，没有改的必要。
: 设计数据库超时断联就是因为有太多连接占着茅坑不拉屎。
: 连接池已经解决这个问题，所以这个设置不必要。哪个DBA提出来要设置，不能随便来吧，必须要讨论的吧，讨论结果需要满足方方面面的需求吧？我方需求6分钟以上，某方说必须240秒，他要说出理由，如果必要，我改程序。这一切都由项目协调机构决定。
你坚持要保留一定数量的活连接而且不用心跳，请问如果你的数据库管理员把连接超时配置了240秒，你怎么办？
回答不了了吧！
【 在 slowaction 的大作中提到: 】
: 你坚持你的300秒不需要修改
: 请问如果你的数据库管理员把连接超时配置了240秒，你怎么办
没人搭理是因为现在的年轻人太可怜了，饭碗都保不住，谁会去关心大并发数据库怎么处理呢？一般是这需求都是大企业，搞大项目的，都是在经济上行企业蓬勃发展，业务猛烈扩张才有的压力和动力去研究。
我是恢复高考第一届的计算机专业，上学时有工资，因为成绩好中途还涨了一次工资。毕业回单位后，到了信息部门，就我是科班出身，老员工都是其他专业改行的。所以到单位就是挑大梁的，做什么工作领导说了算，怎么干我说了算。那个年代企业信息应用都采用文件系统，不信任数据库。当年就一个DBASE算是数据库，还是单用户的。谈不上并行计算，大并发应用。是我开创了多用户关系数据库系统在大并发业务中的应用，在我们企业。
现在的年轻人，毕业了有人要吗？就业了还不知道哪天丢饭碗，哪有心思考虑什么大并发的问题。这类问题哪里轮得到他们考虑。
【 在 slowaction 的大作中提到: 】
: 你在这里长篇大论两配置参数写死的合理性
: 只能证明
: 1.你老了
改配置然后动态更新，这是软件的基本功能
看看你这没见过世面的样子
【 在 ylh1969 的大作中提到: 】
: 你坚持要保留一定数量的活连接而且不用心跳，请问如果你的数据库管理员把连接超时配置了240秒，你怎么办？
: 回答不了了吧！
我就问你，你的活连接没心跳怎么办！改哪个配置？加心跳？你回答我的问题，少说废话。
【 在 slowaction 的大作中提到: 】
: 改配置然后动态更新，这是软件的基本功能
: 看看你这没见过世面的样子
你问这个问题和数据库管理员改了超时时间没有任何关系
原来怎么运行，现在怎么运行
【 在 ylh1969 的大作中提到: 】
: 我就问你，你的活连接没心跳怎么办！改哪个配置？加心跳？你回答我的问题，少说废话。
你问这个问题和数据库管理员改了超时时间没有任何关系
原来怎么运行，现在怎么运行
【 在 ylh1969 的大作中提到: 】
: 我就问你，你的活连接没心跳怎么办！改哪个配置？加心跳？你回答我的问题，少说废话。
那么你的活连接不做心跳会死。
做心跳会拖累数据库，而且管理复杂，故障率高数据库忙时会误判。误判会出大麻烦。
最可行的就是取消活连接，这就是我的方案，参数是否可变这不是关键问题。这个贴提出的核心问题就是不要活连接。
【 在 slowaction 的大作中提到: 】
: 你问这个问题和数据库管理员改了超时时间没有任何关系
: 原来怎么运行，现在怎么运行
他死不死和有没有心跳有什么关系？
你从头到尾一脑袋浆糊，
碰到问题就东拉西扯
从来不能聚焦一个问题
【 在 ylh1969 的大作中提到: 】
: 那么你的活连接不做心跳会死。
: 做心跳会拖累数据库，而且管理复杂，故障率高数据库忙时会误判。
你的活连接不做心跳数据库一断就死了呀，再取用就完蛋了呀，哪有可靠性可言！
只要你有活连接就不存在数据库240秒断联(这个断联会打死你的活连接）的需要啊 既然你不需要凭什么我需要！既然我不需要，凭什么我要改变这个参数！172楼已经解释清楚了，你还反复提，有意思吗？你能不能考虑问题全面一点呀，这么密切的逻辑关联你还需要念叨1000遍吗？
我不需要改这个参数，你需要你改，没有技术难度，我说几遍了？
【 在 slowaction 的大作中提到: 】
: 他死不死和有没有心跳有什么关系？
: 你从头到尾一脑袋浆糊，
: 碰到问题就东拉西扯
240秒是数据库的配置
你管的着么
用什么机制也不能保证数据库断了他不死
你连这些机制都是干什么用的都不知道
祥林嫂一样说你40年前如何如何
【 在 ylh1969 的大作中提到: 】
: 你的活连接不做心跳数据库一断就死了呀，再取用就完蛋了呀，哪有可靠性可言！
: 只要你有活连接就不存在数据库240秒断联(这个断联会打死你的活连接）的需要啊 既然你不需要凭什么我需要！既然我不需要，凭什么我要改变这个参数！172楼已经解释清楚了，你还反复提，有意思吗？你能不能考虑问题全面一点呀，这么密切的逻辑关联你还需要念叨1000遍吗？
: 我不需要改这个参数，你需要你改，没有技术难度，我说几遍了？
数据库断了，把应用打死，谁能这么操作，搞破坏吗？
你的连接池都解决不了这个问题，你会容忍DBA胡作非为吗？不经批准擅改数据库配置，导致系统瘫痪，等着开除呢！
【 在 slowaction 的大作中提到: 】
: 240秒是数据库的配置
: 你管的着么
: 用什么机制也不能保证数据库断了他不死
服务端配置240秒，你配置300秒，
你这机制就是废的，你认为不需要改？
老糊涂了吧
【 在 ylh1969 的大作中提到: 】
: 你的活连接不做心跳数据库一断就死了呀，再取用就完蛋了呀，哪有可靠性可言！
: 只要你有活连接就不存在数据库240秒断联(这个断联会打死你的活连接）的需要啊 既然你不需要凭什么我需要！既然我不需要，凭什么我要改变这个参数！172楼已经解释清楚了，你还反复提，有意思吗？你能不能考虑问题全面一点呀，这么密切的逻辑关联你还需要念叨1000遍吗？
: 我不需要改这个参数，你需要你改，没有技术难度，我说几遍了？
那你的活连接呢？不一样死吗？
你的方案没有比我更优啊！
我的会自愈呀，再过60秒我也会关闭这些连接的。
就算不幸这个连接被取用，在操作失败后归还即可，以系统故障归还的连接会被关闭。继续取用可以重新打开。
你理解什么叫自愈了吗？
【 在 slowaction 的大作中提到: 】
: 服务端配置240秒，你配置300秒，
: 你这机制就是废的，你认为不需要改？
: 老糊涂了吧
不经批准做这个配置者，开除。
是你小糊涂了吧！
【 在 slowaction 的大作中提到: 】
: 服务端配置240秒，你配置300秒，
: 你这机制就是废的，你认为不需要改？
: 老糊涂了吧
数据库断了，应用就要死？
那是做应用的蠢
应用必须处理链接失效的情况，
没有机制可以保证连接一定有效
【 在 ylh1969 的大作中提到: 】
: 数据库断了，把应用打死，谁能这么操作，搞破坏吗？
: 你的连接池都解决不了这个问题，你会容忍DBA胡作非为吗？不经批准擅改数据库配置，导致系统瘫痪，等着开除呢！
我可以改120秒，
你改不了吧？
【 在 ylh1969 的大作中提到: 】
: 那你的活连接呢？不一样死吗？
: 你的方案没有比我更优啊！
那你120秒死。
【 在 slowaction 的大作中提到: 】
: 我可以改120秒，
: 你改不了吧？
要不怎么说你一脑袋浆糊呢
参数可以自适应，发现外部环境变了
首先可以自己调整参数
其次可以日志报警
而你，写死了300秒，什么也不会干
只知道讲你上大学涨工资之类的废话
【 在 ylh1969 的大作中提到: 】
: 不经批准做这个配置者，开除。
: 是你小糊涂了吧！
看来你没有搞过大系统，你敢改，找开除呢！
【 在 slowaction 的大作中提到: 】
: 我可以改120秒，
: 你改不了吧？
我的会自愈呀，300秒内我也会关闭这些连接的。
就算不幸这时间内这个连接被取用，在操作失败后归还即可，以系统故障归还的连接会被关闭。继续取用可以重新打开。
你理解什么叫自愈了吗？
你违规私改数据库，结果就是系统断断续续出故障，日志里当然会有，很快就会抓住元凶，绳之以法。
【 在 slowaction 的大作中提到: 】
: 要不怎么说你一脑袋浆糊呢
: 参数可以自适应，发现外部环境变了
: 首先可以自己调整参数
技术上讲不出道理，
扯别的没用
你在原单位倚老卖老别人可能不搭理你
网上可没人惯着你
如果数据库超时时间配置了，240
连接池超时时间必须比240少
你哪年的大学生也没用
【 在 ylh1969 的大作中提到: 】
: 看来你没有搞过大系统，你敢改，找开除呢！
194楼就是技术上的道理，我的系统瘫不了，你的系统没救。
【 在 slowaction 的大作中提到: 】
: 技术上讲不出道理，
: 扯别的没用
: 你在原单位倚老卖老别人可能不搭理你
想不明白为什么服务端240，为什么客户端不能配置300？
去医院看看吧
【 在 ylh1969 的大作中提到: 】
: 我的会自愈呀，300秒内我也会关闭这些连接的。
: 就算不幸这时间内这个连接被取用，在操作失败后归还即可，以系统故障归还的连接会被关闭。继续取用可以重新打开。
: 你理解什么叫自愈了吗？
客户端配置300，就不允许数据库配小于360，懂吗！
我这边是生产运营系统，DBA是维护支持系统，它得听我的，懂吗，我不会下改240断联的命令，没人敢瞎改！瞎改有日志很快会被抓住，承担责任。
【 在 slowaction 的大作中提到: 】
: 想不明白为什么服务端240，为什么客户端不能配置300？
: 去医院看看吧
别人的连接池允许，数据库爱怎么配怎么配
如果有别的业务也用这个数据库，可以允许他改配置
你的实现不行？
所以你和你的连接池都会被淘汰
【 在 ylh1969 的大作中提到: 】
: 客户端配置300，就不允许数据库配小于360，懂吗！
那你回你们单位去讲你的连接池吧
互联网没人惯着你
【 在 ylh1969 的大作中提到: 】
: 客户端配置300，就不允许数据库配小于360，懂吗！
: 我这边是生产运营系统，DBA是维护支持系统，它得听我的，懂吗，我不会下改240断联的命令，没人敢瞎改！
不是我们单位，是所有的生产单位都不会发生这种事，你纯粹是闭门造车，胡思乱想。洗洗睡吧。
【 在 slowaction 的大作中提到: 】
: 那你回你们单位去讲你的连接池吧
: 互联网没人惯着你
当然，项目投产前必然要讲。现在运行着呢，好多年了，那个程序就是告诉大家，这个参数根本没必要改。
【 在 slowaction 的大作中提到: 】
: 那你回你们单位去讲你的连接池吧
: 互联网没人惯着你
加个配置有那么难吗！说一遍就行了，有必要反复说吗？
我没让谁用我的程序，只说了一个算法，连接池健康管理，可以不留活口，简单，可靠，鲁棒性高，性能高。谁做连接池，可以采用这种算法。具体的，自己写程序，有问题，问我。
你说的问题，加个配置即可。
【 在 slowaction 的大作中提到: 】
: 别人的连接池允许，数据库爱怎么配怎么配
: 如果有别的业务也用这个数据库，可以允许他改配置
: 你的实现不行？
UPDRS量表你可以做一下，能通过再来讨论技术问题吧
【 在 ylh1969 的大作中提到: 】
: 不是我们单位，是所有的生产单位都不会发生这种事，你纯粹是闭门造车，胡思乱想。洗洗睡吧。
不难，
但是你的设计不行
【 在 ylh1969 的大作中提到: 】
: 加个配置有那么难吗！说一遍就行了，有必要反复说吗？
你不一直说300秒不用改么？
【 在 ylh1969 的大作中提到: 】
: 加个配置有那么难吗！说一遍就行了，有必要反复说吗？
: 我没让谁用我的程序，只说了一个算法，连接池健康管理，可以不留活口，简单，可靠，鲁棒性高。谁做连接池，可以采用这种算法。具体的，自己写程序，有问题，问我。
: 你说的问题，加个配置即可。
我是不用改，谁需要谁改，程序自己写。这不是技术问题。
【 在 slowaction 的大作中提到: 】
: 你不一直说300秒不用改么？
你不懂主要矛盾和次要矛盾。
我的方案怎么说也比你的方案强，你遇到数据库断联就死透了，我的遇到不合适的配置，晃晃悠悠还可以走，如果系统繁忙，根本就不会出问题。问题也可以很快被找出。见194楼。
你的逻辑能力太差，找不到问题的关键点，在不是问题的问题上反复纠缠。真担心你的学生毕业了会干啥。你们现在不学逻辑课了吗？我们那会儿是有逻辑课的。
【 在 slowaction 的大作中提到: 】
: 不难，
: 但是你的设计不行
你看194楼吧。我就是不改也死不了，忙没事，闲也没事，就在那个间隙里会有事，而且很快恢复。自愈嘛。
你弄得保活连接才会死。
我知道了，你们学校实验室的DBA是大拿，你们得听他的。我们企业DBA就是个服务生，得听生产部门的。这使这个实现有了差别。不要紧哦，我说的是算法，你照这个流程做就可以，具体实现你自己按你的需求来就行。
在学生实习中你可以提要求，变量不能全大写，超时要配置，做不好你可以扣分不让他毕业。
我的DBA搞事情我也可以开除他。
所以我们没有什么好争论的。
大家呢，思考一下连接池健康管理，是保活呢还是一个活口不留。
【 在 slowaction 的大作中提到: 】
: 别人的连接池允许，数据库爱怎么配怎么配
: 如果有别的业务也用这个数据库，可以允许他改配置
: 你的实现不行？
发信人: xiechuanhust (mavina), 信区: CProgramming
标 题: Re: 一个提高数据库连接效率的方法-自愈式连接池
发信站: 水木社区 (Fri Jul 10 21:44:09 2026), 站内
第一次听说把连接池当并发控制用的，囧
另外，玩了很多年数据库，库的负载中纯连接池相关的占比很低呀
这位也是你学生吧，还是你学弟，一个老师教的？
连用连接池控制并发度都不知道？
连接池还可以用来负载均衡和容错。
这都是20年前使用的技术，你们落后时代至少20年了。
回去改教案吧。
【 在 slowaction 的大作中提到: 】
: 这都哪跟哪
: 限制连接数和连接池没有一毛钱的关系
不是现用现开，第一次用开，之后就不用开了。
以后不开也不关，就是连接池的标准功能。
【 在 nikezhang 的大作中提到: 】
: 如果你还是现用现开，那和玩具写法的每次select之前先connect，select之后再close也没什么区别，根本不能叫做连接池
技术上你已经被淘汰了
只能靠回忆20年前找点安慰
【 在 ylh1969 的大作中提到: 】
: 你看194楼吧。我就是不改也死不了，忙没事，闲也没事，就在那个间隙里会有事，而且很快恢复。自愈嘛。
: 你弄得保活连接才会死。
: 我知道了，你们学校实验室的DBA是大拿，你们得听他的。我们企业DBA就是个服务生，得听生产部门的。这使这个实现有了差别。不要紧哦，我说的是算法，你照这个流程做就可以，具体实现你自己按你的需求来就行。
应该说tcp诞生后就有了
【 在 ylh1969 的大作中提到: 】
: 20年前就用了。
: 【 在 fairyaz 的大作中提到: 】
: : 10年前都有这机制了！
: FROM 221.221.55.* [北京–丰台区 联通]