好，咱们直接聊Spring Boot配置多数据源这事儿。你是不是也遇到过这种场景：一个项目里既要连MySQL存业务数据，又要连Redis做缓存，甚至还得接个MongoDB存日志？这种时候，单数据源就完全不够用了。很多新手一上来就慌了，觉得配置多数据源是个天大的难题，但其实说白了，就是给Spring Boot多指定几个连接池的事儿。关键在于，你得搞清楚Spring Boot的自动配置机制——它默认只配一个数据源，你得手动把第二个、第三个数据源拆出来，让它们各管各的，互不干扰。就像你家装了两个水龙头，一个接热水管，一个接冷水管，虽然都从同一个总闸来，但各自独立工作，不会混在一起。
具体怎么操作呢？先从配置文件说起。我习惯用application.yml，因为清晰好读。比如你有个主数据源叫primary，再有个从数据源叫secondary，那就这样写：spring.datasource.primary.url=jdbc:mysql://localhost:3306/db1，spring.datasource.primary.username=root，spring.datasource.primary.password=123456，然后再用同样的格式写上secondary的配置。注意，这里的primary和secondary不是Spring Boot的内置属性名，而是你自定义的前缀。Spring Boot本身只认spring.datasource.url这种不带后缀的，但咱们要配置多个，就得自己定义前缀。然后在代码里通过@ConfigurationProperties注解把这些前缀对应的配置绑定到DataSource对象上。这一步是基础，就像搭积木前先准备好零件一样。
接下来是核心：创建数据源Bean。你需要写两个配置类，比如PrimaryDataSourceConfig和SecondaryDataSourceConfig。每个类里都定义一个@Bean方法，返回一个DataSource，并加上@Primary注解来标记主数据源。@Primary这个注解很重要，它告诉Spring Boot：当有多个同类型的Bean时，优先注入这个。比如你的Service层需要注入DataSource，如果没加@Primary，Spring会报错说“找到多个Bean，不知道用哪个”。所以主数据源必须加@Primary，从数据源不加，或者加个@Qualifier来区分。但有个坑：如果你用了Spring Boot的自动配置，它会默认创建一个叫dataSource的Bean，如果你再手动创建两个，就会冲突。解决办法是在启动类上排除DataSourceAutoConfiguration，用@SpringBootApplication(exclude = {DataSourceAutoConfiguration.class})。这样Spring Boot就不自动配数据源了，全由你手动控制。
光有数据源还不够，你还得告诉Spring怎么管理事务和JPA。每个数据源需要对应一个独立的JPA配置，包括EntityManagerFactory和TransactionManager。比如主数据源对应的EntityManagerFactory，你要指定它扫描哪些实体类包路径，比如.primary.entity；从数据源就扫描.secondary.entity。同样，事务管理器也要分开，主事务管理器加@Primary，从事务管理器用@Qualifier区分。这一步容易踩坑：很多人忘了给每个数据源配独立的JPA属性，比如hibernate.ddl-auto、show-sql这些，结果发现主数据源的表自动创建了，从数据源的表却没了。解决办法很简单，在每个配置类里单独定义JpaProperties，然后用@Primary区分开。
实际开发中，你还会遇到更复杂的场景：比如动态切换数据源。什么叫动态切换？就是同一个方法里，根据业务逻辑决定用哪个数据源，而不是在代码里硬编码。这时候就得用AbstractRoutingDataSource了。这个类是Spring提供的一个抽象类，它本身不连数据库，而是根据一个lookupKey来动态选择实际的数据源。你只需要重写它的determineCurrentLookupKey方法，返回一个字符串，比如“primary”或“secondary”。然后配合一个ThreadLocal变量，在方法调用前设置当前线程要用哪个数据源，调用完后清除。这样就能实现读写分离、分库分表这些高级功能。比如你有个用户服务，读请求走从库，写请求走主库，用动态数据源就能轻松搞定。
不过，动态数据源有个隐藏的坑：事务管理。如果你在同一个事务里既读主库又读从库，Spring的事务管理器是绑定到EntityManagerFactory上的，而每个数据源有自己的EntityManagerFactory，这就可能导致跨库事务失败。解决办法有两种：一是把事务拆分成多个小事务，每个事务只操作一个数据源；二是用分布式事务方案，比如Atomikos或Seata。但说实话，大部分业务场景用不着分布式事务，拆事务就够了。比如你一个方法里先写主库，再读从库，那就把写操作单独开一个事务，读操作再开另一个事务，用@Transactional(transactionManager = "primaryTransactionManager")和@Transactional(transactionManager = "secondaryTransactionManager")分别指定。这样虽然麻烦点，但能保证一致性。
说个大家容易忽略的：连接池配置。多数据源意味着多个连接池，每个连接池的初始大小、最大连接数、超时时间都得单独设置。比如主库并发高，连接池可以设大一点，比如最大20个；从库只是报表查询，设5个就够了。这些参数写在配置文件里，用spring.datasource.primary.hikari.maximum-pool-size=20这种格式。注意，HikariCP是Spring Boot默认的连接池，性能很好，但如果你用了其他连接池比如Druid，就得单独引入依赖并配置。另外，别忘了监控：每个数据源的连接池状态、慢SQL这些都要能看到。用Druid的话，它自带监控页面；用HikariCP就要配合Actuator来暴露metrics。说实话，很多项目上线后出问题，都是因为连接池配置不合理，要么太小导致请求排队，要么太大把数据库打爆。多数据源场景下，这个问题会被放大，因为每个连接池都是独立的，你得分别调优。
写到这里，你应该感觉到了：配置多数据源本身不难，难的是把细节想周全。比如不同数据源之间的数据一致性怎么保证？日志怎么隔离？异常怎么处理？这些都需要你在设计阶段就考虑进去。我见过最糟糕的案例，是一个团队把所有数据源的配置都塞在一个配置类里，结果代码乱成一团，改一个参数要翻半天。我的建议是：每个数据源独立一个配置类，用@Profile区分环境，甚至用不同模块来隔离。比如主库相关代码放module-primary，从库放module-secondary，这样编译时就分开了，维护起来也清爽。如果你跟我一样有代码洁癖，还可以用Spring Data的Repository接口来区分，每个数据源对应一个Repository包，用@EnableJpaRepositories指定扫描路径，这样连注入都不用操心，完全解耦。
Spring Boot配置多数据源就像搭积木，零件就那几个：DataSource、EntityManagerFactory、TransactionManager、JpaProperties。关键是理清它们之间的关系，以及怎么用@Primary和@Qualifier来避免冲突。如果你只是做个小工具，配两个数据源就够了；如果是企业级应用，那就得考虑动态切换、连接池调优、事务隔离这些高级玩法。但不管怎样，记住一点：代码是给人看的，配置要清晰、要可维护。别为了炫技搞得太复杂，简单可靠才是王道。
