1. 为什么需要动态数据源管理想象一下你正在运营一个电商平台大促期间流量暴涨数据库压力骤增。传统的单数据源架构就像只有一条高速公路所有车辆都挤在一起结果就是系统响应变慢用户体验直线下降。这时候读写分离就像在高速旁边开辟专用车道——主库处理写操作从库分担读请求流量自然就分散开了。但真实场景往往更复杂。你可能需要根据业务模块垂直拆分用户库、订单库、商品库实现地理级别的多活部署北京机房、上海机房应对突发故障时的快速切换主库宕机秒切备库Dynamic-Datasource这个框架就像个智能交通调度系统它能帮你用注解轻松指定操作走哪个库DS(slave)自动负载均衡读请求到多个从库运行时动态增减数据源而不重启服务保持事务一致性虽然这确实是个技术难点我在去年双十一项目里就深有体会当QPS突破5万时动态数据源管理让数据库集群的CPU负载始终保持在60%以下而传统架构早就崩了。2. 快速搭建读写分离环境2.1 基础配置三件套先看Maven依赖注意要排除SpringBoot默认的HikariCP自动配置dependency groupIdcom.baomidou/groupId artifactIddynamic-datasource-spring-boot-starter/artifactId version3.6.1/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency配置文件示例application.yml更清晰spring: datasource: dynamic: primary: master strict: true # 没匹配到数据源就抛异常 datasource: master: url: jdbc:mysql://192.168.1.100:3306/order_master?useSSLfalse username: admin password: ENC(密文密码) # 支持加密 driver-class-name: com.mysql.cj.jdbc.Driver slave_1: url: jdbc:mysql://192.168.1.101:3306/order_slave?useSSLfalse username: readonly password: ENC(密文密码) slave_2: url: jdbc:mysql://192.168.1.102:3306/order_slave?useSSLfalse username: readonly password: ENC(密文密码)2.2 注解驱动的数据源切换在Service层使用DS注解就像给方法贴标签Service public class OrderServiceImpl implements OrderService { DS(slave) // 默认走从库 public Order getOrder(Long id) { return orderMapper.selectById(id); } DS(master) // 写操作切主库 public void createOrder(Order order) { orderMapper.insert(order); } }有个坑我踩过DS注解在类和方法上同时存在时方法注解优先级更高。曾经因为没注意这个导致全类方法都走了从库写入全失败。2.3 事务处理的正确姿势跨数据源事务要用DSTransactionalDSTransactional public void placeOrder(Order order) { // 操作主库 orderMapper.insert(order); // 操作商品库 productMapper.updateStock(order.getProductId()); }注意这个限制如果需要在事务中捕获异常做业务处理得用编程式事务。我在库存扣减场景就遇到过——扣减失败不能直接抛异常要返回特定错误码。3. 动态数据源进阶玩法3.1 运行时增减数据源数据库扩容时这样动态添加新节点Autowired private DataSource dataSource; public void addSlaveNode(String name, String url) { DynamicRoutingDataSource ds (DynamicRoutingDataSource) dataSource; DruidDataSource newDataSource new DruidDataSource(); newDataSource.setUrl(url); // 其他配置... ds.addDataSource(name, newDataSource); }移除故障节点更简单ds.removeDataSource(slave_3);3.2 智能路由策略默认轮询负载均衡可能不适合所有场景。比如我们有个需求北京用户的查询要优先路由到北京机房。自定义路由策略示例public class RegionRoutingStrategy implements DynamicDataSourceStrategy { Override public String determineDataSourceKey( ListString dataSourceKeys) { // 从ThreadLocal获取用户区域 String region UserContext.getRegion(); return dataSourceKeys.stream() .filter(key - key.contains(region)) .findFirst() .orElse(default); } }在配置中指定策略spring: datasource: dynamic: strategy: com.yourpackage.RegionRoutingStrategy3.3 与MyBatis-Plus的深度整合如果你用MyBatis-Plus这个配置能让分页查询自动走从库Configuration public class MybatisPlusConfig { Bean DS(slave) public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor()); return interceptor; } }4. 生产环境避坑指南4.1 连接池配置优化Druid推荐配置根据机器配置调整master: initial-size: 5 max-active: 20 min-idle: 5 max-wait: 60000 validation-query: SELECT 1 test-while-idle: true time-between-eviction-runs-millis: 60000曾经因为没配test-while-idle半夜连接失效导致大量报错。监控指标要重点关注ActiveCount活跃连接数WaitThreadCount等待连接的线程数MaxWait获取连接最长时间4.2 多级降级方案设计数据源访问的优先级策略优先读本地从库本地从库不可用读异地从库极端情况读主库要控制比例用Spring的Retryable实现自动重试Retryable(value SQLException.class, maxAttempts 3, backoff Backoff(delay 1000)) DS(slave) public Product getProduct(Long id) { return productMapper.selectById(id); }4.3 监控告警体系通过Druid的StatViewServlet暴露监控端点Bean public ServletRegistrationBeanStatViewServlet druidServlet() { ServletRegistrationBeanStatViewServlet reg new ServletRegistrationBean(); reg.setServlet(new StatViewServlet()); reg.addUrlMappings(/druid/*); return reg; }关键报警项连接获取超时次数活跃连接数超过阈值从库延迟时间通过SHOW SLAVE STATUS获取5. 真实案例电商大促备战去年双十一我们做了这些优化压测阶段动态添加了3个只读实例// 模拟脚本自动扩容 for (int i 4; i 6; i) { addSlaveNode(slave_ i, jdbc:mysql://new-node- i :3306/order_slave); }配置读写分离权重slave_1: weight: 30 # 性能好的实例分配更高权重 slave_2: weight: 20 slave_3: weight: 50关键业务强制走主库DS(master) public ListOrder getRecentOrders(Long userId) { // 用户最近订单必须读主库保证实时性 }最终效果查询平均响应时间从120ms降到45ms主库写入QPS下降60%零数据不一致投诉
SpringBoot集成Dynamic-Datasource：从读写分离到动态数据源管理的实战解析
发布时间：2026/6/23 8:34:23
1. 为什么需要动态数据源管理想象一下你正在运营一个电商平台大促期间流量暴涨数据库压力骤增。传统的单数据源架构就像只有一条高速公路所有车辆都挤在一起结果就是系统响应变慢用户体验直线下降。这时候读写分离就像在高速旁边开辟专用车道——主库处理写操作从库分担读请求流量自然就分散开了。但真实场景往往更复杂。你可能需要根据业务模块垂直拆分用户库、订单库、商品库实现地理级别的多活部署北京机房、上海机房应对突发故障时的快速切换主库宕机秒切备库Dynamic-Datasource这个框架就像个智能交通调度系统它能帮你用注解轻松指定操作走哪个库DS(slave)自动负载均衡读请求到多个从库运行时动态增减数据源而不重启服务保持事务一致性虽然这确实是个技术难点我在去年双十一项目里就深有体会当QPS突破5万时动态数据源管理让数据库集群的CPU负载始终保持在60%以下而传统架构早就崩了。2. 快速搭建读写分离环境2.1 基础配置三件套先看Maven依赖注意要排除SpringBoot默认的HikariCP自动配置dependency groupIdcom.baomidou/groupId artifactIddynamic-datasource-spring-boot-starter/artifactId version3.6.1/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency配置文件示例application.yml更清晰spring: datasource: dynamic: primary: master strict: true # 没匹配到数据源就抛异常 datasource: master: url: jdbc:mysql://192.168.1.100:3306/order_master?useSSLfalse username: admin password: ENC(密文密码) # 支持加密 driver-class-name: com.mysql.cj.jdbc.Driver slave_1: url: jdbc:mysql://192.168.1.101:3306/order_slave?useSSLfalse username: readonly password: ENC(密文密码) slave_2: url: jdbc:mysql://192.168.1.102:3306/order_slave?useSSLfalse username: readonly password: ENC(密文密码)2.2 注解驱动的数据源切换在Service层使用DS注解就像给方法贴标签Service public class OrderServiceImpl implements OrderService { DS(slave) // 默认走从库 public Order getOrder(Long id) { return orderMapper.selectById(id); } DS(master) // 写操作切主库 public void createOrder(Order order) { orderMapper.insert(order); } }有个坑我踩过DS注解在类和方法上同时存在时方法注解优先级更高。曾经因为没注意这个导致全类方法都走了从库写入全失败。2.3 事务处理的正确姿势跨数据源事务要用DSTransactionalDSTransactional public void placeOrder(Order order) { // 操作主库 orderMapper.insert(order); // 操作商品库 productMapper.updateStock(order.getProductId()); }注意这个限制如果需要在事务中捕获异常做业务处理得用编程式事务。我在库存扣减场景就遇到过——扣减失败不能直接抛异常要返回特定错误码。3. 动态数据源进阶玩法3.1 运行时增减数据源数据库扩容时这样动态添加新节点Autowired private DataSource dataSource; public void addSlaveNode(String name, String url) { DynamicRoutingDataSource ds (DynamicRoutingDataSource) dataSource; DruidDataSource newDataSource new DruidDataSource(); newDataSource.setUrl(url); // 其他配置... ds.addDataSource(name, newDataSource); }移除故障节点更简单ds.removeDataSource(slave_3);3.2 智能路由策略默认轮询负载均衡可能不适合所有场景。比如我们有个需求北京用户的查询要优先路由到北京机房。自定义路由策略示例public class RegionRoutingStrategy implements DynamicDataSourceStrategy { Override public String determineDataSourceKey( ListString dataSourceKeys) { // 从ThreadLocal获取用户区域 String region UserContext.getRegion(); return dataSourceKeys.stream() .filter(key - key.contains(region)) .findFirst() .orElse(default); } }在配置中指定策略spring: datasource: dynamic: strategy: com.yourpackage.RegionRoutingStrategy3.3 与MyBatis-Plus的深度整合如果你用MyBatis-Plus这个配置能让分页查询自动走从库Configuration public class MybatisPlusConfig { Bean DS(slave) public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor()); return interceptor; } }4. 生产环境避坑指南4.1 连接池配置优化Druid推荐配置根据机器配置调整master: initial-size: 5 max-active: 20 min-idle: 5 max-wait: 60000 validation-query: SELECT 1 test-while-idle: true time-between-eviction-runs-millis: 60000曾经因为没配test-while-idle半夜连接失效导致大量报错。监控指标要重点关注ActiveCount活跃连接数WaitThreadCount等待连接的线程数MaxWait获取连接最长时间4.2 多级降级方案设计数据源访问的优先级策略优先读本地从库本地从库不可用读异地从库极端情况读主库要控制比例用Spring的Retryable实现自动重试Retryable(value SQLException.class, maxAttempts 3, backoff Backoff(delay 1000)) DS(slave) public Product getProduct(Long id) { return productMapper.selectById(id); }4.3 监控告警体系通过Druid的StatViewServlet暴露监控端点Bean public ServletRegistrationBeanStatViewServlet druidServlet() { ServletRegistrationBeanStatViewServlet reg new ServletRegistrationBean(); reg.setServlet(new StatViewServlet()); reg.addUrlMappings(/druid/*); return reg; }关键报警项连接获取超时次数活跃连接数超过阈值从库延迟时间通过SHOW SLAVE STATUS获取5. 真实案例电商大促备战去年双十一我们做了这些优化压测阶段动态添加了3个只读实例// 模拟脚本自动扩容 for (int i 4; i 6; i) { addSlaveNode(slave_ i, jdbc:mysql://new-node- i :3306/order_slave); }配置读写分离权重slave_1: weight: 30 # 性能好的实例分配更高权重 slave_2: weight: 20 slave_3: weight: 50关键业务强制走主库DS(master) public ListOrder getRecentOrders(Long userId) { // 用户最近订单必须读主库保证实时性 }最终效果查询平均响应时间从120ms降到45ms主库写入QPS下降60%零数据不一致投诉
