1. 连接池基础与TongWeb集成第一次在TongWeb里配置GBase数据库连接池时我犯了个低级错误——直接把最大连接数设成了1000结果系统刚上线就崩溃了。后来才明白连接池不是越大越好它本质上是个数据库连接的共享停车场。想象一下停车场太小连接数不足会导致车辆排队但太大连接数过多又会浪费土地资源服务器内存。TongWeb作为国产中间件的代表对GBase这类国产数据库的支持相当友好。在tongweb.xml配置文件中连接池的核心参数就像汽车的油门和刹车resource namejdbc/gbaseDemo authContainer typejavax.sql.DataSource maxTotal50 maxIdle10 minIdle5 maxWaitMillis5000 driverClassNamecom.gbase.jdbc.Driver urljdbc:gbase://192.168.1.100:5258/dbname usernameapp_user password加密密码/这里有个坑要注意GBase的JDBC驱动类名和MySQL不同必须用com.gbase.jdbc.Driver。我有次手快写成MySQL的驱动类排查了半天连接失败的问题。2. 电商场景下的参数调优实战去年给某电商平台做618大促优化时我们通过压力测试发现当并发用户达到3000时订单提交接口的响应时间从200ms飙升到5秒。用jconsole监控发现数据库连接获取等待时间占比高达70%。2.1 连接数计算公式经过反复测试我们总结出黄金公式最大连接数 (核心线程数 × 平均查询时间) / 目标吞吐量比如系统有8核CPU平均SQL执行时间50ms要求每秒处理1000请求(8 × 0.05) / (1/1000) 400但实际配置要留20%余量最终设成320。这里有个经验值4核服务器建议初始值50-1008核可以150-300。2.2 超时参数陷阱!-- 关键超时参数 -- property nameremoveAbandonedTimeout value300/ property namevalidationQuery valueSELECT 1/ property nametestOnBorrow valuetrue/removeAbandonedTimeout我们设成300秒超过5分钟未关闭的连接会被强制回收validationQueryGBase需要用SELECT 1而不是MySQL的SELECT 1 FROM DUAL测试环境建议testOnBorrowtrue生产环境改成testWhileIdletrue更高效3. 性能监控与问题定位有次凌晨收到报警发现数据库CPU飙到90%。用netstat -nat|grep 5258|wc -l查看到有800多个连接但应用服务器实际只需要200个。最后发现是连接泄漏——某段代码在try块里获取连接却在finally块里漏了关闭。3.1 监控指标看板我们在Grafana配置了关键监控项活跃连接数健康状态应该在最大连接数的60-80%等待线程数持续大于0说明连接不足获取连接平均耗时超过100ms需要预警归还连接率正常应该接近100%3.2 内存优化技巧GBase连接比较吃内存每个连接大约消耗3-5MB。如果设置500连接光连接池就要占2.5GB内存。我们的优化方案使用connectionProperties添加useServerPrepStmtsfalse设置defaultFetchSize100避免一次性拉取过多数据启用cachePrepStmts减少SQL解析开销4. 高可用架构设计去年双11当天某台GBase服务器宕机幸亏我们做了以下准备4.1 故障转移配置urljdbc:gbase://primary:5258,secondary:5258/dbname?failoverEnabletrue主备切换超时设成connectTimeout10socketTimeout30配合TongWeb的alternateUsernameAllowedtrue实现账号自动切换4.2 连接池预热大促前通过初始化脚本预热连接池// 启动时执行 for(int i0; iminIdle; i){ Connection conn dataSource.getConnection(); conn.close(); // 不是真的关闭是放回池里 }这个技巧让系统在流量突增时避免了连接建立的性能抖动。实测显示预热后首屏渲染时间降低了40%。5. 批处理任务优化处理月度报表时发现10万行的数据导出要30分钟。调整策略单独配置batchPool连接池设置defaultAutoCommitfalse使用fetchSize5000减少网络往返添加rewriteBatchedStatementstrue参数最终耗时压缩到8分钟。关键是要把批处理连接池和在线业务池隔离避免长时间事务影响实时请求。