我先扔个场景给你——你写了个Spring Boot应用，数据库连得好好的，突然业务方说“我们要加一个报表库，数据从另一个系统同步过来”。你一想，简单，改配置呗。结果一改，发现原来的业务全乱了，连库连错了。这时候你才意识到，一个数据源根本不够用。
多数据源这事儿，说白了就是你的应用需要同时操作两个或更多数据库。比如一个主库做读写，一个从库做查询；或者一个业务库，一个日志库；甚至一个MySQL、一个Oracle混着用。Spring Boot默认只配一个数据源，你多加一个，它就懵了。这时候Druid就派上用场了——它不只是连接池，还自带多数据源的支持，监控、防火墙、加密，一套带走。你不需要自己写复杂的配置类，也不用操心事务切来切去，Druid帮你把活儿干了。
那怎么配？你先在pom.xml里把Druid的Spring Boot Starter加上。版本别乱选，用最新的稳定版。然后application.yml里写数据源配置，两个数据源就写两组，分别叫datasource.primary和datasource.secondary。Druid的配置项很多，但核心就几个：url、username、password、driver-class-name。别忘了设置initial-size和max-active，不然生产环境一上来就撑爆连接数。还有，每个数据源的filters要单独配，比如stat和wall，监控和防火墙都开起来。
配置写完了，还没完。你得告诉Spring Boot哪个数据源是主，哪个是从。这时候需要写两个配置类，分别扫描不同的Mapper包。比如主数据源扫描.mapper.primary，从数据源扫描.mapper.secondary。用@Primary注解标记主数据源，不然Spring会报“多个Bean”的错。事务管理器也要分开配，一个叫primaryTransactionManager，一个叫secondaryTransactionManager。这样你在Service层用@Transactional的时候，可以指定用哪个数据源的事务。
但有个坑你得注意：事务切面不能跨数据源。比如你在一个方法里先写主库，再读从库，事务只会管主库，从库那边该查还是查。你要做分布式事务，得用Seata或者Atomikos，Druid本身不提供这个能力。所以设计业务的时候，尽量把跨数据源的操作拆分成独立的方法，别在一个事务里揉两个库。
还有监控这块，Druid的Web监控Servlet和Filter要单独配置。你可以在启动类或者配置类里注册一个ServletRegistrationBean和一个FilterRegistrationBean。监控路径默认是/druid/*，建议改个复杂的路径，或者加个鉴权，不然谁都能看你的SQL执行情况。登录页面还能看到慢查询、连接池占用、SQL防火墙拦截记录，线上排查问题特别有用。
Druid还有一个你容易忽略的功能——密码加密。生产环境数据库密码不能明文写在配置文件里，Druid提供了ConfigTools类，可以生成公钥和私钥。你只需要把加密后的密码配进去，启动时用公钥解密。很多团队图省事直接写明文，结果被爬虫扫到GitHub上的配置文件，数据库直接裸奔。
说点实战经验。多数据源最怕的是配置混乱。建议你在项目里建一个config包，专门放数据源和事务的配置类。每个数据源的定义要清晰，比如primary是业务库，secondary是日志库，命名别搞成ds1、ds2这种，三个月后你自己都看不懂。还有，连接池大小要根据业务量动态调整，别死磕固定值。Druid的监控页面能实时看到活跃连接数，你观察一周，把initial-size和max-active调到一个合理的区间。
Druid多数据源配置不是复制粘贴就能跑通的，你得理解每个配置项的意义，还要会处理事务边界和监控安全。但一旦配好了，你的应用就像装了个双引擎，一个库挂了另一个还能撑一阵。下次业务方再提“加个库”的要求，你心里就有底了。
