企业官网建设流程全解析

1. 项目概述：为什么一个连接池要管多个库？

你有没有遇到过这种场景：一个后台服务既要查用户中心的MySQL，又要写订单日志到PostgreSQL，还得定时从Oracle同步基础配置，甚至偶尔调用SQL Server里的历史报表视图。这时候如果每个数据库都配一套独立的Druid连接池——四套配置、四套监控指标、四套健康检查逻辑，光是YAML文件就容易看花眼，更别说上线后排查“为什么订单日志写慢了但用户登录没影响”这种问题时，得在四个监控面板之间反复切换。

这就是“Druid连接池实现自定义场景的多数据库连接”的真实起点：它不是为炫技而生的架构玩具，而是面向中大型业务系统里数据源异构化、职责边界清晰化、运维可观测性统一化这三重现实压力所给出的务实解法。核心关键词是Druid、多数据库、自定义场景、连接池——注意，这里说的“多数据库”不是指分库分表那种逻辑库，而是物理上完全独立、协议不同、驱动各异、账号隔离的真实数据库实例；而“自定义场景”，恰恰是它区别于Spring Boot自动装配的要害：比如某次大促前需要临时给订单库加专属连接池参数（最小空闲数拉到20、超时时间缩到3秒），但用户库保持默认策略；又比如灰度发布时，新版本服务只允许访问测试环境的PostgreSQL，老版本仍走生产MySQL，这种动态路由能力，原生Druid根本不提供。

我带过的几个项目里，最典型的是某高校教务系统的微服务改造。它原本是单体Java应用，数据库层混用MySQL（主业务）、SQL Server（学籍档案）、达梦（国产化适配模块）。迁移到Spring Cloud后，团队第一反应是“每个服务配一个数据源”，结果API网关一压测，发现80%的线程卡在Druid的getConnection()阻塞队列里——不是数据库慢，是三个数据源共用同一套连接池参数，MySQL的慢查询把SQL Server的快速查询请求全堵死了。后来我们把连接池拆成三个独立实例，再用一个轻量级路由层做统一封装，问题当场解决。这件事让我意识到：多数据源管理的本质，从来不是“能不能连上”，而是“如何让不同SLA要求的数据库，在同一套连接池框架下互不干扰地呼吸”。

所以这篇内容适合谁？如果你正在做以下任何一件事，它就值得你逐行读完：

• 正在将单体应用拆分为微服务，且各服务依赖不同数据库；
• 需要支持国产数据库（如达梦、人大金仓）与MySQL共存的混合部署；
• 在做数据库中间件POC，想验证Druid能否作为底层连接池支撑ShardingSphere或MyCat；
• 被DBA要求对不同库设置差异化的连接回收策略（比如Oracle必须30分钟强制重连，MySQL可设为2小时）；
• 或者只是单纯被“dataSourceBean注入冲突”折磨过，想搞懂Spring里@Primary和@Qualifier背后到底发生了什么。

接下来的内容，不会复述Druid官网那几页配置说明。我会带你从零开始，亲手搭出一个能同时管理MySQL、PostgreSQL、H2（用于本地测试）的Druid连接池集群，并重点拆解三个实战中最痛的环节：如何让每个数据源拥有独立的监控埋点（避免Prometheus抓到一堆混淆的druid_pool_active_count）、如何在运行时动态切换数据源而不重启（比如故障时自动降级到备用库）、以及怎么用最少的代码侵入，让MyBatis的@SelectProvider方法自动识别当前该走哪个库。所有方案均经过生产环境验证，参数值直接抄作业即可。

2. 架构设计与选型逻辑：为什么不用ShardingSphere或MyCat？

2.1 多数据源方案的三类技术路径

在动手写代码前，必须先厘清一个关键认知：“多数据库连接”不等于“分布式数据库”。很多开发者一看到标题就本能想到ShardingSphere或MyCat，这是典型的路径依赖。实际上，针对“一个应用连多个异构库”这个需求，业界存在三种截然不同的技术路径，它们解决的问题域完全不同：

提示：选择Druid多实例方案的核心理由，是它把“连接管理”和“SQL执行”彻底解耦。Druid只负责高效创建、复用、销毁物理连接；而“该连哪个库”这个决策权，交还给业务层——这正是“自定义场景”的题中之义。

2.2 Druid为何是首选？对比HikariCP与Tomcat JDBC

既然确定走“多实例”路线，为什么选Druid而不是更轻量的HikariCP？这里有个常被忽略的硬性约束：国产数据库兼容性。某次给某政务系统做国产化适配时，我们试过HikariCP连接达梦数据库，结果在高并发下频繁抛出java.sql.SQLException: Connection is not available, request timed out after 30000ms。排查发现是HikariCP的connection-test-query默认值SELECT 1不被达梦识别（达梦要求SELECT 1 FROM DUAL），而Druid的validationQuery支持按数据库类型自动适配，且内置了达梦、人大金仓等国产库的专用检测逻辑。

更关键的是监控维度。HikariCP的Metrics只有active、idle、pending三个基础指标，而Druid提供了42个细粒度监控项，包括：

• poolingCount（当前池中连接数）
• notFullCount（未达最大连接数的次数）
• connectCount（累计创建连接数）
• closeCount（累计关闭连接数）
• executeCount（SQL执行总次数）
• errorCount（SQL执行错误数）

这些指标对定位“多库混用”场景下的隐性问题至关重要。比如当PostgreSQL连接池的notFullCount持续为0，但executeCount增长缓慢，基本可以断定是网络层存在间歇性丢包（因为连接池始终不敢扩容，怕新建连接失败）；而MySQL池的errorCount突增但executeCount平稳，则大概率是SQL语法错误或权限问题。这种诊断能力，是HikariCP无法提供的。

2.3 “自定义场景”的本质：动态路由 vs 静态绑定

很多教程教你怎么用AbstractRoutingDataSource实现多数据源，但它们漏掉了一个致命细节：静态配置的路由键（lookupKey）在Spring容器启动时就固化了，无法响应运行时变化。比如某电商系统要求“大促期间所有订单查询强制走读库”，如果路由逻辑写死在determineCurrentLookupKey()里，就得改代码、发版、重启——这显然违背“自定义场景”的灵活性要求。

我们的方案采用两级路由机制：

• 一级路由（静态）：基于Spring Profile或配置中心开关，决定启用哪些数据源（如spring.profiles.active=prod,oracle-enabled）；
• 二级路由（动态）：通过ThreadLocal存储当前线程的DataSourceKey，由AOP切面在DAO方法执行前注入，支持注解驱动（如@TargetDataSource("order_postgres")）或规则引擎（如“当userId % 10 < 3时走测试库”）。

这种设计让“自定义场景”真正落地：

• 测试环境：所有方法默认走H2内存库，仅加@TargetDataSource("mysql_prod")的才连生产库；
• 灰度环境：通过Nacos配置target-datasource-strategy=userid-modulo，动态分流；
• 故障应急：运维人员在控制台输入set datasource fallback to mysql_backup，5秒内生效。

注意：Druid本身不提供路由能力，它只是被路由的目标。真正的“自定义”发生在路由层——这也是为什么本项目标题强调“Druid连接池实现...”，而非“Druid实现...”。理解这一点，才能避免后续踩坑。

3. 核心实现与实操细节：从配置到动态切换

3.1 基础配置：为每个数据库定制Druid连接池

先看最基础的三库配置（MySQL、PostgreSQL、H2）。关键不是“怎么配”，而是“为什么这样配”。以MySQL为例，这是某金融系统生产环境的实际参数：

spring: datasource: mysql: url: jdbc:mysql://192.168.10.100:3306/user_center?useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true username: user_rw password: ${MYSQL_PASSWORD} driver-class-name: com.mysql.cj.jdbc.Driver # Druid特有配置 druid: initial-size: 5 min-idle: 10 max-active: 50 max-wait: 60000 time-between-eviction-runs-millis: 60000 min-evictable-idle-time-millis: 300000 validation-query: SELECT 1 test-while-idle: true test-on-borrow: false test-on-return: false pool-prepared-statements: true max-pool-prepared-statement-per-connection-size: 20 filters: stat,wall,log4j2 connection-properties: druid.stat.mergeSql=true;druid.stat.slowSqlMillis=5000

参数选择逻辑详解：

• initial-size: 5：应用启动时预热5个连接，避免首请求因建连延迟超时。实测某支付系统首请求耗时从1200ms降至210ms；
• min-idle: 10：保持10个空闲连接，应对突发流量。设得太低（如3）会导致高峰期频繁创建/销毁连接，CPU飙升；设得太高（如30）则浪费数据库连接数，Oracle默认上限仅200；
• max-active: 50：计算依据是QPS × 平均SQL耗时 × 2。假设订单库QPS为200，平均SQL耗时100ms，则理论需40个连接，预留25%余量得50；
• time-between-eviction-runs-millis: 60000：每60秒扫描一次空闲连接。太短（如10秒）会增加Druid线程CPU占用；太长（如300秒）导致失效连接清理不及时；
• validation-query: SELECT 1：MySQL用SELECT 1，PostgreSQL必须用SELECT 1 AS a（否则报错），H2用SELECT 1 FROM INFORMATION_SCHEMA.SYSTEM_USERS。这是多库配置最容易出错的点——不同数据库的校验SQL必须严格区分。

PostgreSQL配置的关键差异：

spring: datasource: postgres: url: jdbc:postgresql://192.168.10.101:5432/order_log?currentSchema=public&sslmode=disable username: log_writer password: ${PG_PASSWORD} driver-class-name: org.postgresql.Driver druid: # PostgreSQL专用参数 validation-query: SELECT 1 AS a # 关键！PostgreSQL对连接泄漏更敏感，需缩短空闲时间 min-evictable-idle-time-millis: 180000 # 3分钟，比MySQL的5分钟更激进 # 启用PreparedStatement缓存（PostgreSQL 9.2+支持） pool-prepared-statements: true

H2内存库配置（仅开发/测试用）：

spring: datasource: h2: url: jdbc:h2:mem:testdb;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE username: sa password: driver-class-name: org.h2.Driver druid: # H2无需复杂连接管理 initial-size: 1 min-idle: 1 max-active: 20 # 关闭校验（H2内存库极稳定） test-while-idle: false validation-query: ""

实操心得：所有druid.*参数必须加在对应数据源的命名空间下（如spring.datasource.mysql.druid.*），而非全局spring.datasource.druid.*。否则Spring Boot会尝试用同一套参数初始化所有数据源，导致PostgreSQL因validation-query不匹配而启动失败。

3.2 多数据源Bean注册：避免@Primary冲突的终极解法

Spring Boot 2.0+默认只允许一个@PrimaryDataSource Bean，否则启动报错No qualifying bean of type 'javax.sql.DataSource'。网上常见解法是“把主数据源标为@Primary，其他用@Qualifier”，但这会导致MyBatis的SqlSessionFactory只能注入主数据源，其他库无法使用MyBatis。

我们的解法是彻底放弃Spring Boot的自动配置，手动注册所有DruidDataSource Bean：

@Configuration public class DataSourceConfig { @Bean("mysqlDataSource") @ConfigurationProperties("spring.datasource.mysql") public DruidDataSource mysqlDataSource() { return DruidDataSourceBuilder.create().build(); } @Bean("postgresDataSource") @ConfigurationProperties("spring.datasource.postgres") public DruidDataSource postgresDataSource() { return DruidDataSourceBuilder.create().build(); } @Bean("h2DataSource") @ConfigurationProperties("spring.datasource.h2") public DruidDataSource h2DataSource() { return DruidDataSourceBuilder.create().build(); } // 关键：为每个数据源单独配置SqlSessionFactory @Bean("mysqlSqlSessionFactory") public SqlSessionFactory mysqlSqlSessionFactory(@Qualifier("mysqlDataSource") DataSource dataSource) throws Exception { SqlSessionFactoryBean factoryBean = new SqlSessionFactoryBean(); factoryBean.setDataSource(dataSource); factoryBean.setMapperLocations(new PathMatchingResourcePatternResolver() .getResources("classpath:mapper/mysql/*.xml")); return factoryBean.getObject(); } @Bean("postgresSqlSessionFactory") public SqlSessionFactory postgresSqlSessionFactory(@Qualifier("postgresDataSource") DataSource dataSource) throws Exception { SqlSessionFactoryBean factoryBean = new SqlSessionFactoryBean(); factoryBean.setDataSource(dataSource); factoryBean.setMapperLocations(new PathMatchingResourcePatternResolver() .getResources("classpath:mapper/postgres/*.xml")); return factoryBean.getObject(); } }

这样做的好处：

• 每个SqlSessionFactory绑定唯一数据源，Mapper XML文件按库分离（mapper/mysql/UserMapper.xmlvsmapper/postgres/OrderLogMapper.xml）；
• 业务代码中通过@Autowired @Qualifier("mysqlSqlSessionFactory")明确指定使用哪个；
• 完全规避@Primary冲突，且支持未来无缝接入更多数据库。

注意：@ConfigurationProperties的prefix必须与YAML中的key完全一致（包括大小写）。曾有团队因写成@ConfigurationProperties("spring.datasource.Mysql")（M大写）导致配置未生效，排查3小时才发现是大小写问题。

3.3 动态路由实现：ThreadLocal + AOP的黄金组合

现在有了三个独立的Druid连接池，下一步是让业务代码能“按需取用”。我们采用经典的AbstractRoutingDataSource，但重写其determineCurrentLookupKey()方法，使其从ThreadLocal读取动态键：

public class DynamicRoutingDataSource extends AbstractRoutingDataSource { private static final ThreadLocal<String> CONTEXT_HOLDER = new ThreadLocal<>(); public static void setDataSourceKey(String key) { CONTEXT_HOLDER.set(key); } public static String getDataSourceKey() { return CONTEXT_HOLDER.get(); } public static void clearDataSourceKey() { CONTEXT_HOLDER.remove(); } @Override protected Object determineCurrentLookupKey() { String key = CONTEXT_HOLDER.get(); if (key == null) { // 默认回退到mysql return "mysql"; } return key; } }

然后配置这个动态路由数据源，将其作为所有DAO操作的统一入口：

@Bean @Primary public DataSource routingDataSource() { DynamicRoutingDataSource routingDataSource = new DynamicRoutingDataSource(); Map<Object, Object> targetDataSources = new HashMap<>(); targetDataSources.put("mysql", mysqlDataSource()); targetDataSources.put("postgres", postgresDataSource()); targetDataSources.put("h2", h2DataSource()); routingDataSource.setTargetDataSources(targetDataSources); routingDataSource.setDefaultTargetDataSource(mysqlDataSource()); // 默认走MySQL return routingDataSource; }

最后，用AOP在DAO方法执行前注入路由键：

@Aspect @Component public class DataSourceAspect { @Around("@annotation(targetDataSource)") public Object routeToDataSource(ProceedingJoinPoint joinPoint, TargetDataSource targetDataSource) throws Throwable { String key = targetDataSource.value(); DynamicRoutingDataSource.setDataSourceKey(key); try { return joinPoint.proceed(); } finally { DynamicRoutingDataSource.clearDataSourceKey(); // 必须清理，避免线程复用污染 } } }

业务代码中只需加注解：

@Repository public class OrderLogDao { @Autowired private SqlSessionTemplate sqlSessionTemplate; // 使用routingDataSource创建的模板 @TargetDataSource("postgres") public void insertOrderLog(OrderLog log) { sqlSessionTemplate.insert("OrderLogMapper.insert", log); } }

实操心得：DynamicRoutingDataSource.clearDataSourceKey()必须放在finally块中。我们曾在线上遇到诡异问题——某个HTTP请求因异常未清理ThreadLocal，导致后续复用该线程的请求全部路由到错误的库。加入finally后，问题消失。

3.4 监控埋点：为每个数据源生成独立Prometheus指标

Druid内置的DruidStatManagerFacade默认将所有数据源的指标汇总到同一组Metric，这在多库场景下毫无意义。我们需要为每个DruidDataSource单独暴露指标。

首先，禁用Druid的自动监控：

spring: datasource: druid: web-stat-filter: false stat-view-servlet: false

然后为每个数据源手动注册DruidStatManagerFacade：

@Bean public ServletWebServerFactory servletContainer() { TomcatServletWebServerFactory tomcat = new TomcatServletWebServerFactory(); // 为MySQL注册监控端点 tomcat.addAdditionalTomcatConnectors(createDruidStatConnector("mysql", "/druid/mysql")); // 为PostgreSQL注册监控端点 tomcat.addAdditionalTomcatConnectors(createDruidStatConnector("postgres", "/druid/postgres")); return tomcat; } private Connector createDruidStatConnector(String dataSourceName, String path) { Connector connector = new Connector("org.apache.coyote.http11.Http11NioProtocol"); connector.setScheme("http"); connector.setPort(8080); connector.setSecure(false); connector.setRedirectPort(8443); // 关键：为每个数据源创建独立的StatFilter StatFilter statFilter = new StatFilter(); statFilter.setDbType("mysql"); // 根据数据源类型设置 // 注册到Druid的统计管理器 DruidStatManagerFacade.getInstance().addStatFilter(statFilter, dataSourceName); return connector; }

最终效果：访问http://localhost:8080/druid/mysql看到MySQL池的实时指标，http://localhost:8080/druid/postgres看到PostgreSQL池的指标，完全隔离。

提示：Druid的StatFilter必须在DruidDataSource初始化后注册，否则指标为空。因此addStatFilter()不能放在@Bean方法里，而要在ServletWebServerFactory中延迟执行。

4. 常见问题与避坑指南：那些文档里不会写的真相

4.1 连接泄漏：90%的“连接池打满”都是假象

现象：应用运行几天后，Druid监控显示ActiveCount=50（已达max-active），但PoolingCount却只有10，WaitThreadCount飙升到200+，所有请求超时。

排查过程：

1. 首先确认是否真泄漏——执行show processlist（MySQL）或select * from pg_stat_activity（PostgreSQL），发现大量Sleep状态连接；
2. 检查Druid日志，搜索abandon关键字，发现大量discard long time none received connection；
3. 最终定位到某段代码：

// 错误示范：未关闭ResultSet public List<User> findUsers() { Connection conn = dataSource.getConnection(); PreparedStatement ps = conn.prepareStatement("SELECT * FROM user"); ResultSet rs = ps.executeQuery(); // rs未关闭！ return parse(rs); // 解析后rs被GC，但Druid不知道 }

根本原因：Druid的连接回收依赖Connection.close()，而ResultSet和PreparedStatement的关闭不是强制的。当ResultSet未关闭时，Druid认为该连接仍在使用，拒绝回收。

解决方案：

• 强制规范：所有DAO方法必须用try-with-resources；
• Druid兜底：在druid配置中开启remove-abandoned-on-borrow: true和remove-abandoned-timeout-millis: 60000，自动回收超60秒未归还的连接；
• 监控告警：在Prometheus中设置告警规则druid_pool_active_count{job="myapp"} / druid_pool_max_active{job="myapp"} > 0.8。

实操心得：我们给所有团队立下铁律——任何手动获取Connection的代码，必须经过三人Code Review。这条规矩实施后，连接泄漏问题下降92%。

4.2 数据库驱动冲突：mysql-connector-java 8.x的隐藏陷阱

现象：应用启动时报错java.lang.NoClassDefFoundError: com/mysql/cj/jdbc/Driver，但明明pom.xml里已声明依赖。

根因：Druid 1.2.8+默认使用com.mysql.cj.jdbc.Driver，而某些老项目仍用com.mysql.jdbc.Driver（5.x驱动）。更隐蔽的是，Spring Boot 2.3+的spring-boot-starter-jdbc会自动引入mysql-connector-java8.x，但若项目中又显式引入了5.x版本，Maven依赖树会出现冲突，导致类加载失败。

验证方法：

mvn dependency:tree | grep mysql

若输出中同时出现mysql:mysql-connector-java:5.1.49和mysql:mysql-connector-java:8.0.33，即存在冲突。

解决步骤：

1. 在pom.xml中排除旧版本：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-jdbc</artifactId> <exclusions> <exclusion> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> </exclusion> </exclusions> </dependency>

2. 显式声明8.x驱动：

<dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> </dependency>

3. 更新Druid配置中的driver-class-name为com.mysql.cj.jdbc.Driver。

注意：MySQL 8.x驱动要求URL中必须包含serverTimezone参数，否则报错The server time zone value 'XXX' is unrecognized。这是新手最常踩的坑。

4.3 国产数据库适配：达梦的三个致命参数

某政务项目对接达梦数据库时，出现两个诡异问题：

• 问题1：连接池初始化成功，但首次查询报错java.sql.SQLException: socket creation error；
• 问题2：高并发下连接池频繁重建，CreateCount指标每分钟增长50+。

排查发现，达梦官方文档要求三个关键参数必须显式设置：

spring: datasource: dameng: url: jdbc:dm://192.168.10.102:5236?socketTimeout=30000&loginTimeout=10000&zeroDateTimeBehavior=convertToNull username: sysdba password: ${DM_PASSWORD} driver-class-name: dm.jdbc.driver.DmDriver druid: # 达梦专用 validation-query: SELECT 1 FROM DUAL # 关键！达梦的连接检测必须用DUAL表 test-while-idle: true # 达梦对空闲连接更敏感，需缩短检测间隔 time-between-eviction-runs-millis: 30000 # 必须关闭PreparedStatement缓存（达梦不支持） pool-prepared-statements: false

其中socketTimeout=30000解决第一个问题（网络超时），pool-prepared-statements: false解决第二个问题（达梦的PreparedStatement缓存机制与Druid冲突）。

实操心得：对接任何国产数据库，第一件事不是写SQL，而是去官网找《JDBC编程指南》，把“连接参数”“校验SQL”“驱动类名”三个字段抄下来，贴在工位上。我们团队为此制作了《国产数据库JDBC速查表》，覆盖达梦、人大金仓、神舟通用、南大通用四大厂商，已内部使用三年零失误。

4.4 Spring事务失效：@Transactional为何不生效？

现象：在一个Service方法中，先调用mysqlDao.updateUser()，再调用postgresDao.insertLog()，加了@Transactional注解，但MySQL更新成功、PostgreSQL插入失败时，MySQL的更新未回滚。

原因：@Transactional默认只作用于单个DataSource。当方法内调用多个数据源时，Spring的事务管理器（PlatformTransactionManager）只能管理其中一个。

解决方案有二：

• 简单场景（非强一致性）：放弃跨库事务，用“本地事务+消息队列”最终一致性。例如MySQL更新后发MQ消息，由独立消费者处理PostgreSQL日志写入；
• 强一致性场景：引入Atomikos，配置JTA事务管理器：

@Bean(name = "jtaTransactionManager") public JtaTransactionManager transactionManager() { JtaTransactionManager manager = new JtaTransactionManager(); manager.setTransactionManager(transactionManager()); manager.setUserTransaction(userTransaction()); return manager; }

但代价是性能下降30%-50%，且配置复杂。

我的建议：95%的业务场景都不需要跨库事务。与其花两周调试Atomikos，不如重构业务逻辑——把“用户更新”和“日志写入”拆成两个独立API，用Saga模式协调。某电商系统实践表明，这种重构反而提升了系统可用性。

5. 生产级增强：从能用到好用的五个关键升级

5.1 连接池参数动态化：配置中心驱动的实时调优

Druid的参数在应用启动后即固化，但生产环境常需动态调整。比如大促前要把MySQL池的max-active从50提到100，传统做法是改配置、重启——这不可接受。

我们基于Nacos实现参数热更新：

@Component @RefreshScope public class DruidConfigRefresher { @Autowired private DruidDataSource mysqlDataSource; @Value("${druid.mysql.max-active:50}") private int maxActive; @EventListener public void onConfigChange(RefreshEvent event) { if (event.getScope().contains("druid")) { mysqlDataSource.setMaxActive(maxActive); log.info("Druid maxActive updated to {}", maxActive); } } }

配合Nacos配置：

druid.mysql.max-active=100 druid.postgres.min-idle=15

注意：不是所有Druid参数都支持运行时修改。initial-size、driver-class-name等初始化参数修改无效，必须重启。可动态修改的参数列表见Druid官方文档DruidDataSource类的setXxx()方法。

5.2 故障自动降级：当PostgreSQL宕机时，无缝切到MySQL备份库

核心逻辑：定期探测各数据源健康状态，当连续3次探测失败，自动将路由键映射到备用库。

@Component public class DataSourceHealthChecker { @Autowired private DruidDataSource postgresDataSource; @Autowired private DruidDataSource mysqlBackupDataSource; private final Map<String, AtomicInteger> failureCount = new ConcurrentHashMap<>(); @Scheduled(fixedRate = 30000) // 每30秒检测 public void checkPostgresHealth() { try { Connection conn = postgresDataSource.getConnection(); conn.close(); failureCount.computeIfPresent("postgres", (k, v) -> { v.set(0); return v; }); } catch (Exception e) { AtomicInteger count = failureCount.computeIfAbsent("postgres", k -> new AtomicInteger(0)); if (count.incrementAndGet() >= 3) { // 触发降级 DynamicRoutingDataSource.setFallback("postgres", "mysql_backup"); log.warn("PostgreSQL health check failed 3 times, fallback to mysql_backup"); } } } }

实操心得：降级逻辑必须幂等。我们曾因未加锁导致多次触发降级，造成MySQL备份库被打爆。现改为AtomicInteger计数+ConcurrentHashMap存储，确保线程安全。

5.3 SQL审计增强：精准定位慢查询归属库

Druid的stat过滤器默认将所有SQL汇总，无法区分是MySQL还是PostgreSQL的慢查询。我们通过FilterChainImpl注入库标识：

public class DatabaseTypeFilter extends FilterAdapter { @Override public void statementExecuteBefore(FilterChain chain, StatementProxy statement, String sql) throws SQLException { String dbType = statement.getConnectionProxy().getDirectDataSource().getDbType(); MDC.put("db_type", dbType); // 写入日志上下文 super.statementExecuteBefore(chain, statement, sql); } }

配合Logback配置：

<appender name="SQL_LOG" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>logs/sql.log</file> <encoder> <pattern>%d{HH:mm:ss.SSS} [%thread] [%X{db_type}] %-5level %logger{36} - %msg%n</pattern> </encoder> </appender>

日志中每条SQL前都会标注[mysql]或[postgres]，排查问题时一目了然。

5.4 连接池优雅停机：K8s滚动更新不丢连接

K8s滚动更新时，旧Pod收到SIGTERM信号后应等待所有连接归还Druid池，再退出。否则正在执行的SQL会被中断，引发数据不一致。

@Component public class GracefulShutdown implements DisposableBean { @Autowired private DruidDataSource mysqlDataSource; @Autowired private DruidDataSource postgresDataSource; @Override public void destroy() throws Exception { log.info("Starting graceful shutdown..."); // 等待所有连接归还，最多30秒 mysqlDataSource.close(); postgresDataSource.close(); log.info("All data sources closed"); } }

K8s Deployment中配置：

livenessProbe: httpGet: path: /actuator/health port: 8080 readinessProbe: httpGet: path: /actuator/health port: 8080 terminationGracePeriodSeconds: 60 # 给足关闭时间

5.5 容器化部署优化：JVM参数与Druid的协同

在Docker中运行时，常因JVM堆内存设置不当导致Druid OOM。关键原则：Druid的连接池内存占用 ≈ max-active × 单连接内存（约2MB）。

例如MySQL池max-active=50，则需预留100MB堆内存给连接池。若JVM堆设为512MB，实际可用内存仅剩412MB，极易OOM。

推荐配置：

# Dockerfile FROM openjdk:11-jre-slim ENV JAVA_OPTS="-Xms512m -Xmx1024m -XX:MaxMetaspaceSize=256m -XX:+UseG1GC" CMD java $JAVA_OPTS -jar app.jar

并设置Druid参数：

druid: max-active: 30 # 根据JVM堆大小反推 pool-prepared-statements: true max-pool-prepared-statement-per-connection-size: 10

最后分享一个小技巧：在K8s中用kubectl exec -it <pod> -- jmap -histo:live <pid>查看堆中DruidPooledConnection实例数，若远超max-active，说明存在连接泄漏，立即排查。

我在实际使用中发现，把Druid连接池当成“黑盒”来用是最危险的。它不像HikariCP那样追求极致轻量，而是以“企业级可观测性”为核心设计哲学。每一个参数背后，都对应着数据库的某种物理限制（如