码迷，mamicode.com
首页 > 编程语言 > 详细

Spring实现动态数据源，支持动态加入、删除和设置权重及读写分离

时间：2017-08-16 19:13:15      阅读：302      评论：0      收藏：0      [点我收藏+]

标签：中心   resolved   public   cut   null   exti   思路   val   slist   

当项目慢慢变大，訪问量也慢慢变大的时候。就难免的要使用多个数据源和设置读写分离了。

在开题之前先说明下，由于项目多是使用Spring，因此下面说到某些操作可能会依赖于Spring。

在我经历过的项目中，见过比較多的读写分离处理方式，主要分为两步：

1、对于开发者，要求serivce类的方法名必须遵守规范，读操作以query、get等开头，写操作以update、delete开头。

2、配置一个拦截器，根据方法名推断是读操作还是写操作，设置对应的数据源。

以上做法能实现最简单的读写分离。但对应的也会有非常多不方便的地方，印象最深的应该是下面几点：

1、数据源的管理不太方便。基本上仅仅有2个数据源了，一个读一个写。这个能够在spring中声明多个bean来解决该问题。但bean的id和数据源的功能也就绑定了。

2、由于读写分离往往是在项目慢慢变大后增加的。不是一開始就有。上面说到的第二点方法名可能会各式各样。find、insert、save、exe等等，这些都要一一改动。且要保证以后读的方法名中不能有写操作。也能够拦截的底层一点如JdbcTemplate。但这样会导致交叉设置数据源。

3、数据源无法动态改动，仅仅能在项目启动时载入。

以上问题我想开发者多多少少都会遇到。这也是本文要讨论的问题。

动态数据源结构

在我看来一个好的动态数据源，应该跟单数据源一样让使用者感觉不到他是动态的。至少dao层的开发人员应该感觉不到。

先来看张图：

技术分享

看了上图应该就明确我的思路了，对使用者来说仅仅有一个数据源DynamicDataSource，以下我们来谈谈怎样实现它。

基于spring实现动态数据源

事实上spring早就想到了这一点，也已经为我们准备好了扩展类AbstractRoutingDataSource，我们仅仅须要一个简单的实现就可以。网上关于这个类文章非常多，但都比較粗浅没有讲到点子上，仅仅是实现了多个数据源而已。

这里我们相同来实现AbstractRoutingDataSource。它仅仅要求实现一个方法：

  1. /**
  2.  * Determine the current lookup key. This will typically be
  3.  * implemented to check a thread-bound transaction context.
  4.  * <p>Allows for arbitrary keys. The returned key needs
  5.  * to match the stored lookup key type, as resolved by the
  6.  * {@link #resolveSpecifiedLookupKey} method.
  7.  */
  8. protected abstract Object determineCurrentLookupKey();

你能够简单的理解它：spring把全部的数据源都存放在了一个map中，这种方法返回一个key告诉spring用这个key从map中去取。

它还有个targetDataSources和defaultTargetDataSource属性，网上的一堆做法是继承这个类，然后在声明bean的时候注入dataSource：

  1. <bean id="dynamicdatasource" class="......">
  2.     <property name="targetDataSources">
  3.         <map>
  4.              <entry key="dataSource1" value-ref="dataSource1" /> 
  5.              <entry key="dataSource2" value-ref="dataSource2" /> 
  6.              <entry key="dataSource3" value-ref="dataSource3" /> 
  7.         </map>
  8.     </property>
  9.     <property name="defaultTargetDataSource" ref="dataSource1" />
  10. </bean>

这样尽管简单。可是弊端也是显而易见的。除了使用了多个数据源之外没有我们想要的不论什么操作。可是假设不配置targetDataSources。spring在启动的时候就会抛出异常而无法执行。

事实上我们全然能够在spring启动的时候，我们自己来解析数据源。然后把解析出并实例化的dataSource设置到targetDataSources。以下是解析的核心代码。数据源配置文件的格式能够看这里：数据源配置例子

  1. /**
  2.  * 初始化数据源
  3.  *
  4.  * @param dataSourceList
  5.  */
  6. public void initDataSources(List<Map<String, String>> dataSourceList) {
  7.     LOG.info("開始初始化动态数据源");
  8.     readDataSourceKeyList = new ArrayList<String>();
  9.     writeDataSourceKeyList = new ArrayList<String>();
  10.     Map<Object, Object> targetDataSource = new HashMap<Object, Object>();
  11.     Object defaultTargetDataSource = null;
  12.     for (Map<String, String> map : dataSourceList) {
  13.         String dataSourceId = DynamicDataSourceUtils.getAndRemoveValue(map, ATTR_ID,
  14.             UUIDUtils.getUUID8());
  15.         String dataSourceClass = DynamicDataSourceUtils
  16.             .getAndRemoveValue(map, ATTR_CLASS, null);
  17.         String isDefaultDataSource = DynamicDataSourceUtils.getAndRemoveValue(map,
  18.             ATTR_DEFAULT, "false");
  19.         String weight = DynamicDataSourceUtils.getAndRemoveValue(map, DS_WEIGHT, "1");
  20.         String mode = DynamicDataSourceUtils.getAndRemoveValue(map, DS_MODE, "rw");
  21.         DataSource dataSource = (DataSource) ClassUtils.newInstance(dataSourceClass);
  22.         DynamicDataSourceUtils.setDsProperties(map, dataSource);
  23.         targetDataSource.put(dataSourceId, dataSource);
  24.         if (Boolean.valueOf(isDefaultDataSource)) {
  25.             defaultTargetDataSource = dataSource;
  26.         }
  27.         DynamicDataSourceUtils.addWeightDataSource(readDataSourceKeyList,
  28.             writeDataSourceKeyList, dataSourceId, Integer.valueOf(weight), mode);
  29.         LOG.info("dataSourceId={},dataSourceClass={},isDefaultDataSource={},weight={},mode={}",
  30.             new Object[] { dataSourceId, dataSourceClass, isDefaultDataSource, weight, mode });
  31.     }
  32.     this.setTargetDataSources(targetDataSource);
  33.     if (defaultTargetDataSource == null) {
  34.         defaultTargetDataSource = (CollectionUtils.isEmpty(writeDataSourceKeyList) ? targetDataSource
  35.             .get(readDataSourceKeyList.iterator().next()) : targetDataSource
  36.             .get(writeDataSourceKeyList.iterator().next()));
  37.     }
  38.     this.setDefaultTargetDataSource(defaultTargetDataSource);
  39.     super.afterPropertiesSet();
  40.     LOG.info("初始化动态数据源完毕");
  41. }

在解析出来之后，我们调用父类的this.setTargetDataSources(targetDataSource);和this.setDefaultTargetDataSource(defaultTargetDataSource);方法将它们存入进去。而dataSource的key则依据读写和权重的不同，分别保存到readDataSourceKeyList和writeDataSourceKeyList。

那么什么时候来执行这个解析的方法呢？有些同学可能一下就想到了spring声明bean时的init-method属性，可是这里不行。

由于init-method是在bean初始化完毕之后调用的，当spring在初始化DynamicDataSource时发现这两个属性是空的异常就抛出来了。根本就没有机会去执行init-method。

所以我们要在bean的初始化过程中来解析并存入我们的数据源。要实现这个操作，我们能够实现spring的InitializingBean接口。因为AbstractRoutingDataSource已经实现了该接口，我们仅仅须要重写该方法即可。也就是说DynamicDataSource要实现下面两个方法：

  1. @Override
  2. protected Object determineCurrentLookupKey() {
  3.     ...
  4. }
  5. @Override
  6. public void afterPropertiesSet() {
  7.     this.initDataSources();
  8. }

在afterPropertiesSet方法中实现我们解析数据源的操作。可是这样还不够，由于spring容器并不知道你做了这些，所以最后的一行super.afterPropertiesSet();千万别忘了，用来通知spring容器。

到这里数据源的解析已经完毕了，我们又怎么样来取数据源呢？

这个我们能够利用ThreadLocal来实现。

编写DynamicDataSourceHolder类，核心代码：

  1. private static final ThreadLocal<DataSourceContext> DATASOURCE_LOCAL = new ThreadLocal<DataSourceContext>();
  2. /**
  3.  * 设置数据源读写模式
  4.  *
  5.  * @param isWrite
  6.  */
  7. public static void setIsWrite(boolean isWrite) {
  8.     DataSourceContext dsContext = DATASOURCE_LOCAL.get();
  9.     //已经持有且可写，直接返回
  10.     if (dsContext != null && dsContext.getIsWrite()) {
  11.         return;
  12.     }
  13.     if (dsContext == null || isWrite) {
  14.         dsContext = new DataSourceContext();
  15.         dsContext.setIsWrite(isWrite);
  16.         DATASOURCE_LOCAL.set(dsContext);
  17.     }
  18. }
  19. /**
  20.  * 获取dsKey
  21.  *
  22.  * @return
  23.  */
  24. public static DataSourceContext getDsContent() {
  25.     return DATASOURCE_LOCAL.get();
  26. }

仅仅有简单的设置读写模式和获取dataSource的key。

动态数据源”读已之所写”问题

在设置读写模式时须要注意。假设当前线程已经拥有数据源了且是可写的。则直接返回使用当前的数据源。

这是一个简单的操作却会影响到整个项目。为什么要这样做呢？要是我方法中写操作后有读操作不是也用写数据源了？没错。

这涉及到一个多数据源主从同步时的读已之所写问题，这里简单的来解说一下。

数据库主从同步时，事务一般分两种：

1、硬事务，当往数据库保存数据时，程序读到全部数据库的数据都是一致的，但对应的性能会变低，假设数据库操作时间较长，有可能会引起线程堵塞。

2、软事务，当往数据库保存数据时，程序读到的数据不一定是一致的，但终于是一致的。

举个样例。当你往主库(写库)存入数据时。数据可能无法实时同步到从库(读库)，这中间可能会有那么几秒钟的误差，假设这时候刚好读到这批数据。数据就是不一致的。

当数据库都要分主从和读写分离了，肯定是有性能压力了。所以大多数都会选择另外一种(仅仅是大部分不是绝对，银行等机构可能会第一种)。

这时候数据就会有一个实时展示的问题了。以当前较流行的微信朋友圈为例，我自己发表了一条朋友圈动态，肯定是希望可以立即看到，假设隔个三五秒才干显示我会怀疑是不是公布失败了？用户体验感也会直线下降。但对别人来说，就算时时关注着我也不会知道我这个时候公布了动态，迟个三五秒显示并无大碍，对整个系统也没有影响。

讲到这里相信应该已经明确了吧，简单说就是自己写的数据要可以立即读到。这就是原因了。

指定了读写模式。接下来就是获取数据源了。代码：

  1. @Override
  2. protected Object determineCurrentLookupKey() {
  3.     DataSourceContext dsContent = DynamicDataSourceHolder.getDsContent();
  4.     //已设置过数据源。直接返回
  5.     if (StringUtils.isNotBlank(dsContent.getDsKey())) {
  6.         return dsContent.getDsKey();
  7.     }
  8.     if (dsContent.getIsWrite()) {
  9.         String dsKey = writeDataSourceKeyList.get(RandomUtils.nextInt(writeDataSourceKeyList
  10.             .size()));
  11.         dsContent.setDsKey(dsKey);
  12.     } else {
  13.         String dsKey = readDataSourceKeyList.get(RandomUtils.nextInt(readDataSourceKeyList
  14.             .size()));
  15.         dsContent.setDsKey(dsKey);
  16.     }
  17.     if (LOG.isDebugEnabled()) {
  18.         LOG.debug("当前操作使用数据源:{}", dsContent.getDsKey());
  19.     }
  20.     return dsContent.getDsKey();
  21. }

这里相同注意假设已经设置过数据源了，直接返回，这样就能保证当前线程用的始终是同一个数据源(读改写时会变化一次)。

假设未设置过数据源则依据读写模式，随机的从key列表中取一个使用。为什么要随机呢？这就牵扯到详细的权重实现了。

动态数据源权重实现

这里的权重实现十分简单。也是当前非常多组件的权重实现方式。

如果一个读dataSource的权重是5，则对应的往readDataSourceKeyList中存入5个key，写dataSource也一样。读写则两边都存。

这样依据权重的不同key列表中存入的数量也就不尽同样。取时生成一个小于列表大小的随机数随机取一个即可了。

使用拦截器设置读写模式

各个组件的功能都实现了，仅仅差东风了，什么时候来设置读写模式呢？

这个简单，使用一个拦截器就能搞定。由于是基于Spring JdbcTemplate，所以仅仅要拦截对应的方法就可以。JdbcTemplate的方法命名还是十分规范的，开发者修改的可能性也差点儿为零，这里我们拦截接口：

  1. /**
  2.  * 动态数据源拦截器
  3.  *
  4.  * Created by liyd on 2015-11-2.
  5.  */
  6. @Aspect
  7. @Component
  8. public class DynamicDsInterceptor {
  9.     @Pointcut("execution(* org.springframework.jdbc.core.JdbcOperations.*(..))")
  10.     public void executeMethod() {
  11.     }
  12.     @Around("executeMethod()")
  13.     public Object methodAspect(ProceedingJoinPoint pjp) throws Throwable {
  14.         String methodName = pjp.getSignature().getName();
  15.         if (StringUtils.startsWith(methodName, "query")) {
  16.             DynamicDataSourceHolder.setIsWrite(false);
  17.         } else {
  18.             DynamicDataSourceHolder.setIsWrite(true);
  19.         }
  20.         return pjp.proceed();
  21.     }
  22. }

动态改动数据源

到这里我们的动态数据源就实现的差点儿相同了。有的同学可能会问，那我怎么动态的去改动它呢？

事实上看到上面的initDataSources方法答案就已经有了，它的參数是 List<Map<String, String>> dataSourceList，仅仅须要将数据源的參数封装成map的list传入调用该方法就能实现动态改动了，这也是我为什么把super.afterPropertiesSet();这一行放到这里面而不是重写方法本身的原因。下面是一个简单的候演示样例：

  1. List<Map<String, String>> dsList = new ArrayList<Map<String, String>>();
  2. Map<String, String> map = new HashMap<String, String>();
  3. map.put("id", "dataSource4");
  4. map.put("class", "org.apache.commons.dbcp.BasicDataSource");
  5. map.put("default", "true");
  6. map.put("weight", "10");
  7. map.put("mode", "rw");
  8. map.put("driverClassName", "com.mysql.jdbc.Driver");
  9. map.put("url",
  10.     "jdbc:mysql://localhost:3306/db1?
    useUnicode=true&amp;characterEncoding=utf-8");
  11. map.put("username", "root");
  12. map.put("password", "");
  13. dsList.add(map);
  14. dynamicDataSource.initDataSources(dsList);

在实际的场景中，依据项目使用技术的不同，你能够使用监听器、socket、配置中心等来实现该数据源动态改动的功能，仅仅要保存调用initDataSources方法时传入的数据源信息是正确的就能够了。

动态数据源的实现就到这里了，我希望很多其它的是提供了一种思维，能够依据这个思维做些改变将它应用到详细的场景中。而不只限于JdbcTemplate和Spring，不过做了一个抛砖引玉而已。

全部的源代码都能够在上方供下载的dexcoder-assistant工具包中找到，欢迎各位讨论，留下自己的意见和想法。

Spring实现动态数据源，支持动态加入、删除和设置权重及读写分离

标签：中心   resolved   public   cut   null   exti   思路   val   slist   

原文地址：http://www.cnblogs.com/jhcelue/p/7374937.html
踩
(0)
赞
(0)
   
举报
评论 一句话评论（0）
登录后才能评论！
分享档案
更多>
2021年07月29日 (22)
2021年07月28日 (40)
2021年07月27日 (32)
2021年07月26日 (79)
2021年07月23日 (29)
2021年07月22日 (30)
2021年07月21日 (42)
2021年07月20日 (16)
2021年07月19日 (90)
2021年07月16日 (35)
周排行
mamicode.com排行更多图片
更多
友情链接
兰亭集智   国之画   百度统计   站长统计   阿里云   chrome插件   新版天听网
关于我们 - 联系我们 - 留言反馈
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码！