企业官网建设流程全解析

1. 项目概述

在真实的业务开发里，一个SpringBoot应用只连一个数据库的场景，说实话，越来越少了。我最近接手的一个老系统重构项目，就遇到了典型的“数据孤岛”问题：用户主数据在MySQL的user_center库，订单交易流水在另一个MySQL实例的order_db库，而一些运营报表数据又躺在单独的PostgreSQL里。如果还硬着头皮用一个数据源，写一堆跨库join的SQL或者手动在代码里切换连接，那维护起来简直就是一场灾难，代码会变得又臭又长，性能也堪忧。所以，“多数据源”配置，从一个“炫技”的亮点，变成了中大型项目里一个必须掌握的基础设施能力。

简单来说，SpringBoot多数据源的核心目标就一个：让应用能够透明、灵活地同时连接并操作多个不同的数据库。这里的“不同”可能是完全不同的数据库类型（如MySQL和PostgreSQL），也可能是同一数据库类型下的不同实例或不同Schema。实现方式上，社区里主流的有两大流派，各有各的适用场景和脾气。第一种是“静态配置派”，通过在application.yml里明确定义多个DataSourceBean，然后用@Primary和@Qualifier来手动指定注入哪个。这种方式直白、可控，适合数据源数量固定、切换逻辑简单的场景。第二种则是“动态路由派”，通常借助像dynamic-datasource-spring-boot-starter这样的第三方组件，它内置了一个基于AOP的动态数据源路由器，可以根据方法上的注解（如@DS(“slave”)）或者自定义规则，在运行时动态决定使用哪个连接，特别适合读写分离、分库分表这类需要频繁切换的场景。

无论选哪种，搞明白背后的原理，知道怎么避开那些坑，比如经典的“failed to configure a datasource: ‘url’ attribute”报错，才能真正让多数据源为你的项目服务，而不是添乱。接下来，我就结合自己的踩坑经验，把这“两派”武功的招式、心法以及实战中的“避坑指南”给你拆解清楚。

2. 核心思路与方案选型

在动手写代码之前，先花点时间想清楚你的业务场景到底适合哪种模式，这能省下后面至少80%的调试时间。选择不是非此即彼，但有一个清晰的倾向性。

2.1 静态配置派：简单直接，手动管理

这种方式的思路非常符合Spring的传统哲学：一切皆Bean。你需要在配置类里，显式地创建两个或多个DataSource的Bean，并为它们配置好各自的驱动、URL、用户名、密码等连接属性。然后，Spring的IoC容器里就会存在多个同类型的DataSourceBean。为了让Spring在自动装配时知道该用哪个，你需要用@Primary注解标记其中一个作为默认数据源（通常是你主要的业务库），而对于其他数据源，在注入时则必须使用@Qualifier注解按Bean的名字来精确指定。

它的优势在于绝对的控制力。每一个数据源的生命周期、属性配置都完全掌握在你手里，没有黑魔法。调试的时候也一目了然，Bean定义清晰。但缺点也同样明显：切换繁琐。每次操作非默认数据源，你都得在Service或Mapper层显式地通过@Qualifier注入对应的DataSource或JdbcTemplate，或者获取对应的SqlSessionFactory。这会导致业务代码和数据源配置产生耦合，如果数据源多了，代码里会散落着各种@Qualifier，维护起来心累。

所以，它最适合的场景是：数据源数量很少（比如就2个），且切换模式固定。例如，一个主业务库+一个独立的日志库，日志库只在写审计日志时使用，这种边界清晰的场景，用静态配置反而更清爽。

2.2 动态路由派：注解驱动，自动切换

当你的场景变得复杂，比如最常见的“一主多从”读写分离，或者按照业务模块分库（用户一个库，商品一个库），静态配置就显得力不从心了。你不可能在每一个查询方法里都去手动指定用哪个从库。这时，动态路由方案就派上用场了。

它的核心思想是引入一个抽象层：一个AbstractRoutingDataSource。这个类本身也是DataSource，但它并不真正持有数据库连接，而是一个“路由器”。它内部维护了一个Map，映射着数据源的标识（Key）和真实的DataSource对象（Value）。同时，它提供了一个determineCurrentLookupKey()方法，这个方法返回的字符串，就是当前操作应该使用哪个数据源的Key。如何决定这个Key呢？通常的做法是利用Spring AOP，在方法执行前，解析方法或类上的特定注解（例如@DS(“slave1”)），将数据源Key设置到一个线程安全的上下文（如ThreadLocal）中，AbstractRoutingDataSource再从这里面取出Key，完成路由。

社区里最成熟的实现就是dynamic-datasource-spring-boot-starter，它把上述流程封装得非常好，你只需要引入依赖，在配置文件中定义好多个数据源，然后在方法上加@DS注解就行了，几乎零侵入。它的优势是解耦和灵活，业务代码无需关心底层连接细节，通过注解声明意图即可。非常适合动态性强的场景。

2.3 选型决策要点

怎么选？我总结了一个简单的决策树：

1. 数据源数量与变动频率：数量固定（≤3个）且几乎不变，选静态；数量可能增加或需要动态增减，选动态。
2. 切换逻辑复杂度：切换规则简单固定（如按Dao类固定），静态勉强可用；切换规则复杂（按方法、按参数、按业务规则），必须用动态。
3. 团队熟悉度与项目阶段：如果是老项目小范围改造，团队对Spring原生配置更熟，可以用静态快速上线。如果是新项目，且预见有多数据源需求，强烈建议直接从动态方案开始，长远看更省事。
4. 第三方集成：如果你的项目已经大量使用了MyBatis-Plus，那么用其作者提供的dynamic-datasource-spring-boot-starter会有更好的集成体验和社区支持。

我个人的经验是，在微服务架构下，动态路由方案几乎是标配。它带来的代码整洁度和扩展性，远超过其引入的微小复杂度。

3. 静态配置方式详解与实操

理论说完，我们来真刀真枪地配置。假设我们有一个电商系统，主业务库trade_db（MySQL）和积分库points_db（MySQL，不同实例），我们就用静态配置来实现。

3.1 环境准备与依赖

首先，创建一个标准的SpringBoot项目。在pom.xml中，我们需要引入数据库驱动和连接池依赖。这里我推荐使用HikariCP，它是SpringBoot 2.x后的默认连接池，性能非常好。

<dependencies> <!-- SpringBoot Web Starter (根据你的项目类型选择) --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- SpringBoot JDBC 支持 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-jdbc</artifactId> </dependency> <!-- MySQL 驱动 --> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <!-- 如果使用MyBatis，还需要引入mybatis-spring-boot-starter --> <!-- <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.3.0</version> </dependency> --> </dependencies>

3.2 多数据源配置类编写

这是静态配置的核心。我们不再依赖application.yml中的spring.datasource自动配置，因为那个只会帮我们创建一个默认的DataSourceBean。我们需要自己写一个配置类，手动创建多个Bean。

import com.zaxxer.hikari.HikariDataSource; import org.springframework.boot.context.properties.ConfigurationProperties; import org.springframework.boot.jdbc.DataSourceBuilder; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.context.annotation.Primary; import javax.sql.DataSource; @Configuration public class DataSourceConfig { /** * 主数据源 (trade_db) * 使用 @Primary 注解，表示当存在多个同类型Bean时，优先注入这个 */ @Primary // 关键注解！ @Bean(name = "primaryDataSource") @ConfigurationProperties(prefix = "spring.datasource.primary") // 绑定配置前缀 public DataSource primaryDataSource() { // 这里用DataSourceBuilder创建，它会自动根据classpath中的连接池创建对应的实例（如Hikari） return DataSourceBuilder.create().build(); } /** * 次数据源 (points_db) */ @Bean(name = "secondaryDataSource") @ConfigurationProperties(prefix = "spring.datasource.secondary") public DataSource secondaryDataSource() { return DataSourceBuilder.create().build(); } }

关键点解析：

1. @Primary：这个注解至关重要。Spring在自动装配时，如果发现多个DataSource类型的Bean，又没有明确指定（通过@Qualifier），就会报错。@Primary告诉Spring：“如果纠结，就选我当默认的。” 通常你的核心业务库应该被标记为@Primary。
2. @ConfigurationProperties：这是SpringBoot的魔法。它将application.yml中spring.datasource.primary和spring.datasource.secondary下面的所有属性（url,username,password,driver-class-name,hikari配置等）自动绑定到DataSourceBuilder创建的对象上。这样我们就不需要在代码里硬编码连接信息了。
3. @Bean(name = “...”)：给Bean起个名字，方便后面用@Qualifier引用。

3.3 配置文件 application.yml

接下来，在application.yml中配置两个数据源的具体连接信息。

spring: datasource: # 主数据源配置 primary: jdbc-url: jdbc:mysql://localhost:3306/trade_db?useUnicode=true&characterEncoding=utf-8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: your_primary_password driver-class-name: com.mysql.cj.jdbc.Driver hikari: connection-timeout: 30000 maximum-pool-size: 20 minimum-idle: 5 # 次数据源配置 secondary: jdbc-url: jdbc:mysql://192.168.1.100:3306/points_db?useUnicode=true&characterEncoding=utf-8&useSSL=false&serverTimezone=Asia/Shanghai username: points_user password: your_secondary_password driver-class-name: com.mysql.cj.jdbc.Driver hikari: connection-timeout: 30000 maximum-pool-size: 15 minimum-idle: 3

注意：这里使用的是jdbc-url，而不是url。在SpringBoot 2.x及以上版本，如果你同时配置了url和jdbc-url，且使用了HikariCP，可能会因为属性覆盖问题导致配置不生效。为了清晰和避免冲突，统一使用jdbc-url是更稳妥的做法。这也是很多同学遇到“failed to configure a datasource”错误的一个潜在原因。

3.4 在Service或DAO层使用

配置好了，怎么用呢？假设我们有一个OrderService需要操作主库，一个PointsService需要操作积分库。

import org.springframework.beans.factory.annotation.Autowired; import org.springframework.beans.factory.annotation.Qualifier; import org.springframework.jdbc.core.JdbcTemplate; import org.springframework.stereotype.Service; import javax.sql.DataSource; @Service public class OrderService { // 注入主数据源（由于有@Primary，可以不用@Qualifier，但显式指定更清晰） @Autowired @Qualifier("primaryDataSource") private DataSource primaryDataSource; // 通常我们更常用JdbcTemplate private JdbcTemplate primaryJdbcTemplate; @Autowired public void setPrimaryDataSource(@Qualifier("primaryDataSource") DataSource dataSource) { this.primaryJdbcTemplate = new JdbcTemplate(dataSource); } public void createOrder(Order order) { String sql = "INSERT INTO orders(...) VALUES (...)"; // 使用 primaryJdbcTemplate 操作主库 primaryJdbcTemplate.update(sql, ...); } } @Service public class PointsService { // 注入次数据源，必须使用@Qualifier指定Bean名称 @Autowired @Qualifier("secondaryDataSource") private DataSource secondaryDataSource; private JdbcTemplate secondaryJdbcTemplate; @Autowired public void setSecondaryDataSource(@Qualifier("secondaryDataSource") DataSource dataSource) { this.secondaryJdbcTemplate = new JdbcTemplate(dataSource); } public void addPoints(Long userId, int points) { String sql = "UPDATE user_points SET points = points + ? WHERE user_id = ?"; // 使用 secondaryJdbcTemplate 操作积分库 secondaryJdbcTemplate.update(sql, points, userId); } }

如果你用的是MyBatis，那么还需要为每个数据源配置独立的SqlSessionFactory和MapperScannerConfigurer，并指定它们各自的DataSource和Mapper接口包路径，过程类似但更繁琐一些。

3.5 静态配置的优缺点与避坑点

优点：

• 原理简单，易于理解和调试。
• 对每个数据源的控制粒度极细，可以分别定制连接池参数。
• 不依赖第三方库，纯Spring原生支持。

缺点：

• 代码侵入性强，业务层需要感知数据源。
• 扩展性差，新增数据源需要修改配置类和所有使用到的地方。
• 事务管理复杂，如果需要跨数据源的事务（分布式事务），需要引入额外的框架如JTA。

避坑指南：

1. “Failed to configure a DataSource: ‘url’ attribute is not specified”：这是最常见的错误。根本原因是SpringBoot的自动配置（DataSourceAutoConfiguration）试图为你创建一个默认数据源，但在你的配置里它找不到spring.datasource.url。解决方案：在主启动类上排除DataSourceAutoConfiguration的自动配置：@SpringBootApplication(exclude = {DataSourceAutoConfiguration.class})。这样SpringBoot就不会尝试自动创建数据源，完全由你的配置类接管。
2. 连接池配置不生效：检查是否使用了正确的属性前缀（如spring.datasource.primary.hikari.*），并且确保没有在代码里用setXXX()方法覆盖了配置文件的值。
3. 事务失效：在静态多数据源下，Spring的@Transactional注解默认只对@Primary标记的数据源生效。如果你在操作次数据源的方法上加了@Transactional，它可能不会按你期望的回滚。对于需要跨数据源事务的场景，建议使用Seata等分布式事务解决方案，或者将不同数据源的操作拆分成独立的事务方法。

4. 动态路由方式详解与实操（基于dynamic-datasource）

对于大多数需要灵活切换的场景，我强烈推荐使用dynamic-datasource-spring-boot-starter。它极大地简化了多数据源的开发。下面我们以实现一个“一主二从”的读写分离场景为例。

4.1 引入依赖

首先，在pom.xml中添加依赖。注意选择与你的SpringBoot版本兼容的版本。

<dependency> <groupId>com.baomidou</groupId> <artifactId>dynamic-datasource-spring-boot-starter</artifactId> <version>3.6.1</version> <!-- 请使用最新稳定版 --> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency>

4.2 配置文件 application.yml

配置变得异常简洁。你只需要在一个spring.datasource.dynamic节点下，定义你的所有数据源。

spring: datasource: dynamic: primary: master # 设置默认的数据源（主库），默认值为master strict: false # 是否启用严格模式。严格模式下未匹配到指定数据源会抛异常，非严格模式下则使用默认数据源 datasource: # 主库 master master: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/master_db?useSSL=false&serverTimezone=Asia/Shanghai username: root password: master_password # 从库 slave_1 slave_1: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://192.168.1.101:3306/slave_db?useSSL=false&serverTimezone=Asia/Shanghai username: slave_user password: slave_password # 从库 slave_2 slave_2: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://192.168.1.102:3306/slave_db?useSSL=false&serverTimezone=Asia/Shanghai username: slave_user password: slave_password # 以下是可选的全局配置，如连接池参数 hikari: connection-timeout: 30000 maximum-pool-size: 15 minimum-idle: 5

4.3 使用 @DS 注解切换数据源

这是最核心、最优雅的部分。你不需要在代码里注入不同的JdbcTemplate或DataSource，只需要在方法或类上添加一个@DS注解。

import com.baomidou.dynamic.datasource.annotation.DS; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.jdbc.core.JdbcTemplate; import org.springframework.stereotype.Service; @Service public class UserService { // 这里注入的是动态数据源路由包装后的 JdbcTemplate @Autowired private JdbcTemplate jdbcTemplate; // 写操作，使用主库。如果类上没注解，方法上也没注解，则使用默认的primary数据源（master） @DS("master") // 显式指定主库，清晰明确 public void createUser(User user) { String sql = "INSERT INTO users(...) VALUES (...)"; jdbcTemplate.update(sql, ...); } // 读操作1，使用从库slave_1。通过注解轻松实现读写分离 @DS("slave_1") public User getUserByIdFromSlave1(Long id) { String sql = "SELECT * FROM users WHERE id = ?"; return jdbcTemplate.queryForObject(sql, new BeanPropertyRowMapper<>(User.class), id); } // 读操作2，使用从库slave_2。可以配合负载均衡策略轮询使用从库 @DS("slave_2") public List<User> getAllUsersFromSlave2() { String sql = "SELECT * FROM users"; return jdbcTemplate.query(sql, new BeanPropertyRowMapper<>(User.class)); } // 不指定@DS，则使用默认数据源（master） public User getDefaultUser(Long id) { // 这个方法会使用 master 数据源 String sql = "SELECT * FROM users WHERE id = ?"; return jdbcTemplate.queryForObject(sql, new BeanPropertyRowMapper<>(User.class), id); } }

注解的作用域：

• @DS可以标注在方法上，优先级最高。
• 也可以标注在类上，那么这个类里所有方法默认都使用这个数据源。
• 如果方法和类上都有注解，方法上的会覆盖类上的。
• 如果都没有，则使用spring.datasource.dynamic.primary指定的默认数据源。

4.4 进阶用法与原理浅析

dynamic-datasource的强大不止于此。它底层依赖于AbstractRoutingDataSource和Spring AOP。当你调用一个被@DS注解的方法时，会发生以下几步：

1. AOP拦截器（DsProcessor）会先于方法执行。
2. 拦截器解析@DS注解的值，得到数据源Key（如“slave_1”）。
3. 将这个Key设置到一个ThreadLocal变量中（DynamicDataSourceContextHolder）。
4. 方法内部的数据库操作（通过JdbcTemplate、MyBatis Mapper等）需要获取连接时，会调用AbstractRoutingDataSource的determineCurrentLookupKey()方法。
5. 该方法从ThreadLocal中取出Key，然后从预先注册好的数据源Map中找到对应的真实DataSource，获取连接。
6. 方法执行完毕后，AOP后置处理会清理ThreadLocal中的Key，避免内存泄漏和上下文污染。

基于这个原理，你可以实现更复杂的路由策略：

• SPEL表达式：@DS(“#session.tenantId”)，可以根据会话中的租户ID动态路由到不同的数据库（多租户场景）。
• 自定义策略：实现DynamicDataSourceStrategy接口，可以定义负载均衡策略，比如随机、轮询、负载最低等，然后在@DS注解中不指定具体从库名，而是指定一个分组名，如@DS(“slave”)，框架会自动根据策略从slave_1和slave_2中选择一个。

4.5 动态路由的优缺点与避坑点

优点：

• 接近零侵入：业务代码只需添加注解，与数据源解耦。
• 灵活强大：支持注解、SPEL、自定义策略等多种路由方式。
• 功能丰富：内置读写分离、多租户等常见场景支持，社区活跃。
• 与MyBatis-Plus集成无缝：如果是MyBatis-Plus用户，体验更佳。

缺点：

• 引入第三方依赖：需要管理依赖版本和兼容性。
• 理解成本稍高：需要对其AOP和ThreadLocal的机制有一定了解，才能更好地排查问题。
• 事务上下文管理：同样需要注意事务边界内的数据源切换问题。

避坑指南：

1. 事务内切换失效：这是动态数据源最常见的问题。@Transactional和@DS都是基于Spring AOP实现的。如果它们在同一个方法上，并且@Transactional的切面先执行，它就会先获取一个数据库连接（此时数据源Key可能还没被@DS的切面设置），导致后续操作始终使用这个连接，@DS注解失效。解决方案：确保@DS注解的切面优先级高于@Transactional。dynamic-datasourcestarter已经处理了这一点，但如果你有自定义切面，需要注意顺序。更稳妥的做法是，将@DS注解放在Service方法上，而将@Transactional注解放在调用Service方法的上层（如Controller或另一个无@DS注解的Service方法）。
2. ThreadLocal污染：如果在方法内启用了新线程（如@Async异步方法），新线程无法继承父线程的ThreadLocal数据源Key，会导致切换到默认数据源。解决方案：需要手动传递数据源Key，或使用支持ThreadLocal传递的线程池包装器。
3. 配置错误：确保spring.datasource.dynamic.datasource下的每个数据源key（如master,slave_1）与@DS注解中使用的字符串完全一致，包括大小写。
4. 连接池配置：虽然可以在spring.datasource.dynamic.hikari下配置全局参数，但如果你需要对某个特定数据源（如主库）进行特殊配置，可以这样写：

   spring: datasource: dynamic: datasource: master: url: ... hikari: # 主库独有配置 maximum-pool-size: 30 connection-timeout: 10000

5. 事务管理与跨数据源问题

多数据源环境下，事务管理是一个必须严肃对待的问题。Spring的@Transactional注解及其背后的事务管理器（PlatformTransactionManager）默认是针对单个数据源工作的。

5.1 单数据源事务

在静态配置中，如果你为每个数据源都配置了独立的DataSourceTransactionManager，那么@Transactional注解会默认使用@Primary标记的那个。对于非主数据源的操作，你需要通过@Transactional注解的transactionManager属性来指定对应的事务管理器Bean名称。

在动态路由（dynamic-datasource）中，它提供了一个统一的DynamicDataSourceTransactionManager，能够根据当前线程上下文中@DS注解指定的数据源，自动选择对应的事务管理器（底层是管理对应的真实数据源连接）。所以，在同一个Service方法内部，如果所有数据库操作都通过同一个@DS注解路由到同一个物理数据库，那么事务是正常工作的。

5.2 跨数据源事务（分布式事务）的挑战

真正的难题在于跨数据源事务，即一个业务方法需要同时更新主库和积分库，并且要求要么都成功，要么都回滚。例如，用户下单成功后，既要更新订单库，又要增加用户积分。这是一个典型的分布式事务场景。

• 方案一：最大努力通知（最终一致性）：这是互联网高并发场景下最常用的折中方案。先执行核心操作（如创建订单）并提交本地事务。然后，通过消息队列（如RocketMQ、Kafka）或定时任务，异步地去执行积分增加操作。如果积分增加失败，则通过重试机制不断尝试，直到成功。这保证了最终数据是一致的，但中间可能有短暂的不一致状态。适用场景：对强一致性要求不高，允许短暂延迟的最终一致性业务。
• 方案二：使用分布式事务框架：如果需要强一致性，可以引入Seata、Atomikos等分布式事务解决方案。以Seata为例，它提供了AT、TCC等模式。你需要部署Seata服务端（TC），并在每个微服务（或每个数据源所在的应用）中集成Seata客户端。通过一个全局事务ID（XID）将多个本地事务关联起来，由Seata来协调它们的提交和回滚。优点：保证了强一致性。缺点：性能有损耗，架构复杂度高，需要额外维护Seata服务。
• 方案三：业务设计规避：这是最高明的做法。重新审视业务，看能否通过设计避免跨库更新。比如，能否将积分变更记录先写入订单库的本地表，然后通过Binlog监听同步到积分库？或者，能否将用户和积分数据放在同一个数据库的不同的Schema中？原则：能不用分布式事务，就尽量不用。

5.3 实战建议

1. 评估业务容忍度：首先明确你的业务对一致性的要求是“强一致”还是“最终一致”。大部分互联网业务（如扣库存后发消息通知、更新订单状态后送积分）都可以接受最终一致性。
2. 优先使用本地事务：确保每个Service方法内部，通过@DS注解只操作一个物理数据库。跨库操作拆分成多个方法，并通过上层逻辑（或消息）来协调。
3. 异步解耦：对于跨库写操作，优先考虑使用消息队列异步化。订单创建成功后，发一条“积分增加”消息到MQ，由专门的积分服务消费处理。这样订单库的事务很快提交，用户体验好，系统吞吐量高。
4. 慎用分布式事务框架：除非是金融、交易核心等对资金强一致性有绝对要求的场景，否则不要轻易引入完整的分布式事务框架，它们带来的运维和性能成本可能超出你的预期。

6. 性能调优与监控

多数据源意味着更多的数据库连接。如果配置不当，很容易导致连接池耗尽、数据库压力过大。

6.1 连接池参数调优

无论是静态还是动态配置，连接池（如HikariCP）的参数都至关重要。以下是一些关键参数的经验值（需要根据实际压力测试调整）：

配置示例 (application.yml):

spring: datasource: dynamic: datasource: master: url: ... hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 30000 idle-timeout: 600000 max-lifetime: 1800000 validation-timeout: 5000 connection-test-query: SELECT 1 # MySQL建议，用于连接健康检查

6.2 监控与诊断

多数据源运行起来后，监控是必不可少的。

1. 连接池监控：HikariCP提供了JMX监控。你可以通过/actuator/metrics/hikaricp.connections.*端点（需要SpringBoot Actuator）查看活跃、空闲、等待的连接数。如果hikaricp.connections.pending（等待连接数）持续很高，说明连接池大小可能不足或存在连接泄漏。
2. 慢SQL监控：每个数据源都应开启慢查询日志。在MySQL中，设置long_query_time，并定期分析慢日志。可以使用Alibaba的Druid连接池替代HikariCP，它内置了强大的SQL监控和防火墙功能。
3. 应用层监控：在关键的业务方法上，通过AOP或手动埋点，记录每个数据源的操作耗时、次数。这能帮你发现哪个数据源是瓶颈，或者哪个业务的数据库访问模式有问题。
4. 使用SpringBoot Admin：这是一个很好的可视化监控工具，可以集中查看多个SpringBoot应用的健康状态、指标和日志，方便你统一监控多数据源应用。

6.3 一个常见的性能陷阱：连接泄漏

这是多数据源环境下尤其要注意的问题。表现是运行一段时间后，应用无法获取数据库连接，日志报Connection is not available, request timed out after ...。

排查步骤：

1. 检查连接池配置：确认maxLifetime小于数据库的wait_timeout。
2. 检查代码：是否在所有数据库操作后都正确关闭了Connection、Statement、ResultSet？推荐使用try-with-resources语法或确保在finally块中关闭。
3. 检查事务：是否有长时间未提交的事务（@Transactional方法执行时间过长）？长事务会长时间占用连接。
4. 使用诊断工具：启用HikariCP的leakDetectionThreshold参数（例如设为60000，单位毫秒），它会打印出疑似泄漏连接的堆栈跟踪，帮你快速定位问题代码。

7. 生产环境部署与最佳实践

将多数据源应用部署到生产环境，除了代码正确，还需要在部署和运维层面做好准备。

7.1 配置分离与加密

数据库密码等敏感信息绝不能硬编码在application.yml中提交到代码仓库。

• 使用配置中心：将application.yml中spring.datasource部分的配置抽离出来，放到Apollo、Nacos等配置中心。应用启动时从配置中心拉取。
• 密码加密：如果配置必须放在文件中，应对密码进行加密。SpringBoot支持使用Jasypt进行属性加密。在配置文件中存储加密后的密文，在启动时通过环境变量传入密钥进行解密。
• 环境区分：使用application-{profile}.yml（如application-prod.yml）来管理不同环境（开发、测试、生产）的配置，通过spring.profiles.active激活。

7.2 高可用与故障转移

对于动态路由的读写分离场景，从库（Slave）的高可用很重要。

• 健康检查：dynamic-datasource支持为数据源配置健康检查。确保从库宕机时，能自动将其从负载均衡池中剔除。
• 多从库负载均衡：如前所述，利用@DS(“slave”)配合轮询、随机等负载均衡策略，避免流量打挂单个从库。
• 主库故障转移：主库（Master）的高可用通常依赖于数据库层面的主从复制与VIP切换（如MHA、Orchestrator），应用层面需要配合实现重连机制或故障感知。更现代的架构会使用数据库中间件（如MyCat、ShardingSphere-Proxy）或云数据库服务来屏蔽底层细节。

7.3 版本升级与回滚

升级涉及多数据源的依赖（如dynamic-datasource版本）或SpringBoot版本时：

1. 充分测试：在测试环境模拟生产流量，重点测试数据源切换、事务、连接池行为。
2. 阅读变更日志：仔细阅读新版本dynamic-datasource的Release Notes，看是否有不兼容的配置项变更。
3. 灰度发布：如果可能，先对非核心业务或部分实例进行升级，观察一段时间无误后再全量升级。
4. 准备回滚方案：确保能快速回滚到旧版本。这意味着数据库Schema的变更也要考虑向前兼容。

7.4 日志与排查

为多数据源应用配置清晰的日志，便于线上排查问题。

• 开启SQL日志：在开发测试环境，可以配置mybatis.configuration.log-impl=org.apache.ibatis.logging.stdout.StdOutImpl来打印SQL语句，但生产环境不要开启，性能损耗大且不安全。
• 标记数据源：在日志框架（如Logback/SLF4J）的Pattern中，通过MDC（Mapped Diagnostic Context）将当前线程使用的数据源Key（可以从DynamicDataSourceContextHolder获取）打印出来。这样每条日志都能知道对应哪个数据库操作，排查问题时一目了然。
• 关键操作审计：对于重要的写操作（尤其是跨数据源协调的操作），记录操作流水到独立的审计日志表或Elasticsearch中，包括操作人、时间、数据源、影响行数等，便于事后追溯和对账。

从我个人的经验来看，多数据源从“配得通”到“用得好、管得稳”，中间隔着大量的细节和实战经验。它不仅仅是加几个配置和注解，更涉及到连接池调优、事务边界设计、监控告警等一系列工程实践。希望这篇从原理到实操、从配置到生产的详细拆解，能帮你避开我当年踩过的那些坑，真正驾驭好多数据源这把利器。