基于 SpringBoot 实现 MySQL 读写分离的问题

时间:2022-08-26 16:16:59

-     前言     -

首先思考一个问题: 在高并发的场景中,关于数据库都有哪些优化的手段? 常用的实现方法有以下几种:读写分离、加缓存、主从架构集群、分库分表等,在互联网应用中,大部分都是读多写少的场景,设置两个库,主库和读库。

主库的职能是负责写,从库主要是负责读 , 可以建立读库集群 , 通过读写职能在数据源上的隔离达到减少读写冲突、 释压数据库负载、保护数据库的目的。在实际的使用中,凡是涉及到写的部分直接切换到主库,读的部分直接切换到读库,这就是典型的读写分离技术。本文将聚焦读写分离,探讨如何实现它。

 

基于 SpringBoot 实现 MySQL 读写分离的问题

主从同步的局限性: 这里分为主数据库和从数据库,主数据库和从数据库保持数据库结构的一致 , 主库负责写 , 当写入数据的时候 , 会自动同步数据到从数据库;从数据库负责读 , 当读请求来的时候 , 直接从读库读取数据 , 主数据库会自动进行数据复制到从数据库中。不过本篇博客不介绍这部分配置的知识 , 因为它更偏运维工作一点。

这里涉及到一个问题:主从复制的延迟问题。 当写入到主数据库的过程中 , 突然来了一个读请求 , 而此时数据还没有完全同步 , 就会出现读请求的数据读不到或者读出的数据比原始值少的情况。具体的解决方法最简单的就是将读请求暂时指向主库 , 但是同时也失去了主从分离的部分意义。也就是说在严格意义上的数据一致性场景中 , 读写分离并非是完全适合的 , 注意更新的时效性是读写分离使用的缺点。

好了 , 这部分只是了解 , 接下来我们看下具体如何通过 java 代码来实现读写分离:

该项目需要引入如下依赖:SpringBoot、Spring-aop、Spring-jdbc、aspectjweaver 等。

-     主从数据源的配置     -

我们需要配置主从数据库 , 主从数据库的配置一般都是写在配置文件里面。通过@ConfigurationProperties 注解 , 可以将配置文件(一般命名为:application.Properties)里的属性映射到具体的类属性上 , 从而读取到写入的值注入到具体的代码配置中 , 按照习惯大于约定的原则 , 主库我们都是注为 master , 从库注为 slave。

本项目采用了阿里的 druid 数据库连接池 , 使用 build 建造者模式创建 DataSource 对象 , DataSource 就是代码层面抽象出来的数据源 , 接着需要配置 sessionFactory、sqlTemplate、事务管理器等:

  1. /**
  2. * 主从配置
  3. *
  4. * @author wyq
  5. */
  6. @Configuration
  7. @MapperScan(basePackages = "com.wyq.mysqlreadwriteseparate.mapper", sqlSessionTemplateRef = "sqlTemplate")
  8. public class DataSourceConfig {
  9.  
  10. /**
  11. * 主库
  12. */
  13. @Bean
  14. @ConfigurationProperties(prefix = "spring.datasource.master")
  15. public DataSource master() {
  16. return DruidDataSourceBuilder.create().build();
  17. }
  18.  
  19. /**
  20. * 从库
  21. */
  22. @Bean
  23. @ConfigurationProperties(prefix = "spring.datasource.slave")
  24. public DataSource slaver() {
  25. return DruidDataSourceBuilder.create().build();
  26. }
  27.  
  28. /**
  29. * 实例化数据源路由
  30. */
  31. @Bean
  32. public DataSourceRouter dynamicDB(@Qualifier("master") DataSource masterDataSource,
  33. @Autowired(required = false) @Qualifier("slaver") DataSource slaveDataSource) {
  34. DataSourceRouter dynamicDataSource = new DataSourceRouter();
  35. Map<Object, Object> targetDataSources = new HashMap<>();
  36. targetDataSources.put(DataSourceEnum.MASTER.getDataSourceName(), masterDataSource);
  37. if (slaveDataSource != null) {
  38. targetDataSources.put(DataSourceEnum.SLAVE.getDataSourceName(), slaveDataSource);
  39. }
  40. dynamicDataSource.setTargetDataSources(targetDataSources);
  41. dynamicDataSource.setDefaultTargetDataSource(masterDataSource);
  42. return dynamicDataSource;
  43. }
  44.  
  45. /**
  46. * 配置sessionFactory
  47. * @param dynamicDataSource
  48. * @return
  49. * @throws Exception
  50. */
  51. @Bean
  52. public SqlSessionFactory sessionFactory(@Qualifier("dynamicDB") DataSource dynamicDataSource) throws Exception {
  53. SqlSessionFactoryBean bean = new SqlSessionFactoryBean();
  54. bean.setMapperLocations(
  55. new PathMatchingResourcePatternResolver().getResources("classpath*:mapper/*Mapper.xml"));
  56. bean.setDataSource(dynamicDataSource);
  57. return bean.getObject();
  58. }
  59.  
  60. /**
  61. * 创建sqlTemplate
  62. * @param sqlSessionFactory
  63. * @return
  64. */
  65. @Bean
  66. public SqlSessionTemplate sqlTemplate(@Qualifier("sessionFactory") SqlSessionFactory sqlSessionFactory) {
  67. return new SqlSessionTemplate(sqlSessionFactory);
  68. }
  69.  
  70. /**
  71. * 事务配置
  72. *
  73. * @param dynamicDataSource
  74. * @return
  75. */
  76. @Bean(name = "dataSourceTx")
  77. public DataSourceTransactionManager dataSourceTransactionManager(@Qualifier("dynamicDB") DataSource dynamicDataSource) {
  78. DataSourceTransactionManager dataSourceTransactionManager = new DataSourceTransactionManager();
  79. dataSourceTransactionManager.setDataSource(dynamicDataSource);
  80. return dataSourceTransactionManager;
  81. }
  82. }

-     数据源路由的配置     -

路由在主从分离是非常重要的 , 基本是读写切换的核心。Spring 提供了 AbstractRoutingDataSource 根据用户定义的规则选择当前的数据源 , 作用就是在执行查询之前 , 设置使用的数据源 , 实现动态路由的数据源,在每次数据库查询操作前执行它的抽象方法 determineCurrentLookupKey() 决定使用哪个数据源。

为了能有一个全局的数据源管理器,此时我们需要引入 DataSourceContextHolder 这个数据库上下文管理器,可以理解为全局的变量 , 随时可取(见下面详细介绍) , 它的主要作用就是保存当前的数据源:

  1. public class DataSourceRouter extends AbstractRoutingDataSource {
  2.  
  3. /**
  4. * 最终的determineCurrentLookupKey返回的是从DataSourceContextHolder中拿到的,因此在动态切换数据源的时候注解
  5. * 应该给DataSourceContextHolder设值
  6. *
  7. * @return
  8. */
  9. @Override
  10. protected Object determineCurrentLookupKey() {
  11. return DataSourceContextHolder.get();
  12.  
  13. }
  14. }

-     数据源上下文环境     -

数据源上下文保存器 , 便于程序中可以随时取到当前的数据源 , 它主要利用 ThreadLocal 封装 , 因为 ThreadLocal 是线程隔离的 , 天然具有线程安全的优势。这里暴露了 set 和 get、clear 方法 , set 方法用于赋值当前的数据源名 , get 方法用于获取当前的数据源名称 , clear 方法用于清除 ThreadLocal 中的内容 , 因为 ThreadLocal 的 key 是 weakReference 是有内存泄漏风险的 , 通过 remove 方法防止内存泄漏:

  1. /**
  2. * 利用ThreadLocal封装的保存数据源上线的上下文context
  3. */
  4. public class DataSourceContextHolder {
  5.  
  6. private static final ThreadLocal<String> context = new ThreadLocal<>();
  7.  
  8. /**
  9. * 赋值
  10. *
  11. * @param datasourceType
  12. */
  13. public static void set(String datasourceType) {
  14. context.set(datasourceType);
  15. }
  16.  
  17. /**
  18. * 获取值
  19. * @return
  20. */
  21. public static String get() {
  22. return context.get();
  23. }
  24.  
  25. public static void clear() {
  26. context.remove();
  27. }
  28. }

-     切换注解和 Aop 配置     -

首先我们来定义一个@DataSourceSwitcher 注解 , 拥有两个属性 ① 当前的数据源 ② 是否清除当前的数据源,并且只能放在方法上 , (不可以放在类上 , 也没必要放在类上 , 因为我们在进行数据源切换的时候肯定是方法操作) , 该注解的主要作用就是进行数据源的切换 , 在 dao 层进行操作数据库的时候 , 可以在方法上注明表示的是当前使用哪个数据源:

@DataSourceSwitcher 注解的定义:

  1. @Retention(RetentionPolicy.RUNTIME)
  2. @Target(ElementType.METHOD)
  3. @Documented
  4. public @interface DataSourceSwitcher {
  5. /**
  6. * 默认数据源
  7. * @return
  8. */
  9. DataSourceEnum value() default DataSourceEnum.MASTER;
  10. /**
  11. * 清除
  12. * @return
  13. */
  14. boolean clear() default true;
  15.  
  16. }

DataSourceAop 配置:

为了赋予@DataSourceSwitcher 注解能够切换数据源的能力,我们需要使用 AOP,然后使用@Aroud 注解找到方法上有@DataSourceSwitcher.class 的方法,然后取注解上配置的数据源的值,设置到 DataSourceContextHolder 中,就实现了将当前方法上配置的数据源注入到全局作用域当中:

  1. @Slf4j
  2. @Aspect
  3. @Order(value = 1)
  4. @Component
  5. public class DataSourceContextAop {
  6.  
  7. @Around("@annotation(com.wyq.mysqlreadwriteseparate.annotation.DataSourceSwitcher)")
  8. public Object setDynamicDataSource(ProceedingJoinPoint pjp) throws Throwable {
  9. boolean clear = false;
  10. try {
  11. Method method = this.getMethod(pjp);
  12. DataSourceSwitcher dataSourceSwitcher = method.getAnnotation(DataSourceSwitcher.class);
  13. clear = dataSourceSwitcher.clear();
  14. DataSourceContextHolder.set(dataSourceSwitcher.value().getDataSourceName());
  15. log.info("数据源切换至:{}", dataSourceSwitcher.value().getDataSourceName());
  16. return pjp.proceed();
  17. } finally {
  18. if (clear) {
  19. DataSourceContextHolder.clear();
  20. }
  21.  
  22. }
  23. }
  24.  
  25. private Method getMethod(JoinPoint pjp) {
  26. MethodSignature signature = (MethodSignature) pjp.getSignature();
  27. return signature.getMethod();
  28. }
  29.  
  30. }

-     用法以及测试     -

在配置好了读写分离之后,就可以在代码中使用了 , 一般而言我们使用在 service 层或者 dao 层,在需要查询的方法上添加@DataSourceSwitcher(DataSourceEnum.SLAVE) , 它表示该方法下所有的操作都走的是读库;在需要 update 或者 insert 的时候使用@DataSourceSwitcher(DataSourceEnum.MASTER)表示接下来将会走写库。

其实还有一种更为自动的写法 , 可以根据方法的前缀来配置 AOP 自动切换数据源,比如 update、insert、fresh 等前缀的方法名一律自动设置为写库 , Select、get、query 等前缀的方法名一律配置为读库,这是一种更为自动的配置写法。缺点就是方法名需要按照 aop 配置的严格来定义 , 否则就会失效:

  1. @Service
  2. public class OrderService {
  3.  
  4. @Resource
  5. private OrderMapper orderMapper;
  6.  
  7. /**
  8. * 读操作
  9. *
  10. * @param orderId
  11. * @return
  12. */
  13. @DataSourceSwitcher(DataSourceEnum.SLAVE)
  14. public List<Order> getOrder(String orderId) {
  15. return orderMapper.listOrders(orderId);
  16.  
  17. }
  18.  
  19. /**
  20. * 写操作
  21. *
  22. * @param orderId
  23. * @return
  24. */
  25. @DataSourceSwitcher(DataSourceEnum.MASTER)
  26. public List<Order> insertOrder(Long orderId) {
  27. Order order = new Order();
  28. order.setOrderId(orderId);
  29. return orderMapper.saveOrder(order);
  30. }
  31. }

-     总结     -

 

 

基于 SpringBoot 实现 MySQL 读写分离的问题

上面是基本流程简图,本文介绍了如何实现数据库读写分离 , 注意读写分离的核心点就是数据路由 , 需要继承 AbstractRoutingDataSource , 复写它的 determineCurrentLookupKey 方法 , 同时需要注意 全局的上下文管理器 DataSourceContextHolder , 它是保存数据源上下文的主要类 , 也是路由方法中寻找的数据源取值 , 相当于数据源的中转站。 再结合 jdbc-Template 的底层去创建和管理数据源、事务等,我们的数据库读写分离就完美实现了。

到此这篇关于基于 SpringBoot 实现 MySQL 读写分离的问题的文章就介绍到这了,更多相关SpringBoot 实现 MySQL 读写分离内容请搜索服务器之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持服务器之家!