sring 多数据源

gavinlau

浏览: 295774 次
性别:
来自: 上海

最近访客更多访客>>

icedcoco

stanley_llin

yonghong

bichonghai_1111

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

博客分类：

spring研究

多线程数据结构 Bean Hibernate 配置管理

Spring2.0.1以后的版本已经支持配置多数据源，并且可以在运行的时候动态加载不同的数据源。通过继承AbstractRoutingDataSource就可以实现多数据源的动态转换。目前做的项目就是需要访问12个数据源，每个数据源的表结构都是相同的，所以要求数据源的变动对于编码人员来说是透明，也就是说同样SQL语句在不同的环境下操作的数据库是不一样的。具体的配置如下：
一、首先需要写一个静态的键值对照类：

代码

package cn.com.xinli.ccp.dynamicds;
public class DataSourceMap {
public static final String Admin="Admin";
public static final String Yxh = "Yxh";
}

这个类主要在使用的时候当作获得数据源的标志使用。
二、建立一个获得和设置上下文的类：

代码

package cn.com.xinli.ccp.dynamicds;
public class CustomerContextHolder {
private static final ThreadLocal contextHolder =
new ThreadLocal();
public static void setCustomerType(String customerType) {
contextHolder.set(customerType);
}
public static String getCustomerType() {
return (String) contextHolder.get();
}
public static void clearCustomerType() {
contextHolder.remove();
}
}

这个主要负责设置上下文环境和获得上下文环境。
三、建立动态数据源类，这个类必须继承AbstractRoutingDataSource：

代码

package cn.com.xinli.ccp.dynamicds;
import org.springframework.jdbc.datasource.lookup.AbstractRoutingDataSource;
public class DynamicDataSource extends AbstractRoutingDataSource {
protected Object determineCurrentLookupKey() {
// TODO Auto-generated method stub
return CustomerContextHolder.getCustomerType();
}
}

这个类实现了determineCurrentLookupKey方法，该方法返回一个Object，一般是返回字符串，也可以是枚举类型。该方法中直接使用了CustomerContextHolder.getCustomerType()方法获得上下文环境并直接返回。
四、编写spring的配置文件配置数据源

代码

<bean id="parentDataSource"
class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="driverClassName">
<value>COM.ibm.db2.jdbc.net.DB2Driver</value>
</property>
<property name="url">
<value>jdbc:db2:127.0.0.1:TEST</value>
</property>
</bean>
<bean id="adminDataSource" parent="parentDataSource">
<property name="username" value="admin"/>
<property name="password" value="master997mb"/>
</bean>
<bean id="yxhDataSource" parent="parentDataSource">
<property name="username" value="yxh"/>
<property name="password" value="yxh"/>
</bean>

在这个配置中可以看到首先有个parentDataSource，这个主要配置一些数据源的公用信息，项目中都是链接DB2数据库；adminDataSource和yxhDataSource是根据不同需要配置的个性化信息，但都必须加parent属性，值为parentDataSource。这样就配置好了2个数据源信息。当然如果链接的多数据源是不同类型的两个数据库，那么parentDataSource就可以不要了，直接配置两个不同的数据源链接就可以了。
五、编写spring配置文件配置多数据源映射关系

代码

<bean id="dataSource" class="cn.com.xinli.ccp.dynamicds.DynamicDataSource">
<property name="targetDataSources">
<map key-type="java.lang.String">
<entry key="Yxh" value-ref="yxhDataSource"/>
</map>
</property>
<property name="defaultTargetDataSource" ref="adminDataSource"/>
</bean>

在这个配置中第一个property属性配置目标数据源，<map key-type="java.lang.String">中的key-type必须要和静态键值对照类DataSourceMap中的值的类型相同；<entry key="Yxh" value-ref="yxhDataSource"/>中key的值必须要和静态键值对照类中的值相同，如果有多个值，可以配置多个<entry>标签。第二个property属性配置默认的数据源。
六、配置hibernate。
Hibernate的配置和普通的hibernate、spring结合的配置一样

代码

<bean id="sessionFactory"
class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
<property name="dataSource">
<ref local="dataSource" />
</property>
<property name="mappingResources">
<list>
<value>
cn/com/xinli/ccp/entity/User.hbm.xml
</value>
<value>
cn/com/xinli/ccp/entity/Test.hbm.xml
</value>
</list>
</property>
<property name="hibernateProperties">
<props>
<prop key="hibernate.dialect">
org.hibernate.dialect.DB2Dialect
</prop>
<prop key="hibernate.show_sql">true</prop>
<prop key="hibernate.use_outer_join">true</prop>
<prop key="hibernate.jdbc.batch_size">50</prop>
<prop key="hibernate.jdbc.fetch_size">5</prop>
<prop key="hibernate.connection.pool_size">2</prop>
<prop key="hibernate.connection.autocommit">false</prop>
<prop key="hibernate.cache.use_query_cache">false</prop>
<prop key="hibernate.max_fetch_depth">1</prop>
<prop key="hibernate.bytecode.use_reflection_optimizer">true</prop>
</props>
</property>
</bean>
<bean id="mydao" class="cn.com.xinli.ccp.dao.HibernateBaseDao">
<property name="sessionFactory">
<ref local="sessionFactory" />
</property>
</bean>

关于dao的代码这里就省略了。
七、配置结束，可以使用了。

代码

public class DaoTest extends TestCase {
public void testSave() throws Exception{
CustomerContextHolder.setCustomerType(DataSourceMap.Admin);//设置数据源
//hibernate创建实体
Test test = new Test();
test.setTest("22222222");
mydao.save(test);//使用dao保存实体
CustomerContextHolder.setCustomerType(DataSourceMap.Yxh);//设置为另一个数据源
mydao.save(test);//使用dao保存实体到另一个库中
}
}

在项目中对于编码人员对多数据源的切换可以做成透明的，操作同样的dao，就可以访问不同的数据库了。

==================================================================

在很多大型应用中都会对数据进行切分，并且采用多个数据库实例进行管理，这样可以有效提高系统的水平伸缩性。而这样的方案就会不同于常见的单一数据实例的方案，这就要程序在运行时根据当时的请求及系统状态来动态的决定将数据存储在哪个数据库实例中，以及从哪个数据库提取数据。

Figure 1 数据分割及多数据库架构

通常这种多数据源的逻辑会渗透到业务逻辑中，同时也会给我们使用的数据访问API诸如Hibernate和iBatis等带来不便（需要指定多个SessionFactory或SqlMapClient实例来对应多个DataSource）。

Figure 2 多数据源的选择逻辑渗透至客户端

解决方案

Figure 3 采用Proxy模式来封装数据源选择逻辑

通过采用Proxy模式我们在方案中实现一个虚拟的数据源，并且用它来封装数据源选择逻辑，这样就可以有效地将数据源选择逻辑从Client中分离出来。

Client提供选择所需的上下文（因为这是Client所知道的），由虚拟的DataSource根据Client提供的上下文来实现数据源的选择。

Spring2.x的版本中提供了实现这种方式的基本框架，虚拟的DataSource仅需继承AbstractRoutingDataSource实现determineCurrentLookupKey()在其中封装数据源的选择逻辑。

实例：

publicclass DynamicDataSource extends AbstractRoutingDataSource {

static Logger log = Logger.getLogger("DynamicDataSource");

@Override

protected Object determineCurrentLookupKey() {

String userId=(String)DbContextHolder.getContext();

Integer dataSourceId=getDataSourceIdByUserId(userId);

return dataSourceId;

}

实例中通过UserId来决定数据存放在哪个数据库中。

配置文件示例：

</map>

</property>

</bean>

</bean>

</bean>

蔡超
HP 软件架构师
软件架构顾问
SCEA
IBM Certified Solution Designer for OOA&D vUML2
Chaocai2001@yahoo.com.cn

=====================================================================

在实际的项目中，我们很少就使用一个数据库，出于灾难恢复或者负载均衡之类目的考虑，生产环境中通常都会存在多台数据库服务器，相应的，在应用程序对这些数据库进行数据访问的时候，我们通常就会碰到一个比较常见的问题，即如何管理数据访问过程中牵扯的多个数据源。

下面我们不妨从两个角度来阐述一下在应用程序中如何对多个数据源进行管理…

4.4.2.1. “主权独立 ”的多数据源

所谓“主权独立 ”是指系统中的每一个数据源都对外独立承担暴露数据库资源的职能：

具体的应用场景可能是：

每一个数据库所存储的数据性质不同，比如数据库A存储重要的交易信息，数据库B存储次要的系统管理信息等等，如果要访问交易信息，那么通常可以明确指定使用对应数据库A的dataSourceA进行数据访问；如果要访问系统管理信息，则明确指定使用对应数据库B 的dataSourceB，其他依次类推。
每一个数据库分别承担不同的数据访问请求形式，比如数据库A只允许更新操作不允许查询，数据库B只允许查询不允许更新等，这个时候，也是可以明确指定使用哪一个dataSource进行数据访问；

当然，类似的场景并非只有这些，但总的意图是相似的，那就是每一个dataSource的职能对于使用它们的客户端来说足够明确，完全是各自独立使用。笔者经历的FX项目中就使用了这样的多数据源管理方式。在FX中，设置的MAIN数据库主要存储顾客或者银行与FX Broker之间的交易信息，设置的INFO数据库主要存储汇率以及系统履历之类的信息^{[32 ]} 。通常情况下，针对交易以及汇率之间的信息存储在逻辑上是可以分开进行的，所以现在，应用程序对应的spring配置内容基本如下：

<bean id="mainDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
 <property name="url" value="${main.jdbcUrl}"/>
 <property name="driverClassName" value="${main.driver}"/>
 <property name="username" value="${main.username}"/>
 <property name="password" value="${main.passwork}"/>
 <!-- other property settings -->
</bean>

<bean id="infoDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
 <property name="url" value="${info.jdbcUrl}"/>
 <property name="driverClassName" value="${info.driver}"/>
 <property name="username" value="${info.username}"/>
 <property name="password" value="${info.password}"/>
 <!-- other property settings -->
</bean>

<bean id="mainJdbcTemplate" class="org.springframework.jdbc.core.JdbcTemplate">
 <property name="dataSource" ref="mainDataSource"/>
</bean>

<bean id="infoJdbcTemplate" class="org.springframework.jdbc.core.JdbcTemplate">
 <property name="dataSource" ref="infoDataSource"/>
</bean>

<bean id="dataAccessResourceSupport" abstract="true">
 <property name="mainJdbcTemplate" ref=""/>
 <property name="infoJdbcTemplate" ref=""/>
</bean>

<bean id="someDaoWithMainDS" class="...">
 <property name="mainJdbcTemplate" ref="mainJdbcTemplate"/>
 <!-- other property settings -->
</bean>

<bean id="someDaoWithInfoDS" class="...">
 <property name="infoJdbcTemplate" ref="infoJdbcTemplate"/>
 <!-- other property settings -->
</bean>

<bean id="someDaoWithBothDS" class="..." parent="dataAccessResourceSupport">
 <!-- other property settings -->
</bean>

项目中这种情况下的多数据源管理是最简单的，也是比较容易管理的方式，所以，在你考虑下面将要谈到的这种更加动态，更加复杂的多数据源管理方式之前，请先对你的数据访问场景做一个评估，看一下当前这种方式是否已经足够满足项目的数据访问需要，实在不行的话，再考虑后继方案，也就是在运行期间来决定到底使用多个数据源中的哪一个。

4.4.2.2. “合纵连横 ”的多数据源

社区中经常提到的“多数据源互换 ”即属于这种场景，之所以用“合纵连横 ”来形容这些数据源是因为，对于使用它们的数据访问类来说，这些数据源已经丧失了“独立自主 ”的地位，所有与数据访问类进行的交互需要通过“盟主 ”进行，该盟主本质上也是一个DataSource，但它的职责更加倾向于对“联盟 ”内的多个DataSource的职能进行协调和管理，最终数据访问所需要的资源由“盟主 ”来决定要哪一个DataSource贡献出来。

使用这种多数据源管理方式的具体场景可能有：

系统中设置多台“地位相当 ”的数据库以实现多机热备，从而保证数据库的高可用性(HA，High Availability)，这个时候，如果某一台数据库挂掉的话，可以迅速切换到另一台数据库，而对于数据访问类来说，这样的切换对其是透明的；
系统中存在的多台服务器也是“地位相当 ” 的，不过，同一时间他们都处于活动(Active)状态，处于负载均衡等因素考虑，数据访问请求需要在这几台数据库服务器之间进行合理分配，这个时候，通过统一的一个DataSource来屏蔽这种请求分配的需求，从而屏蔽数据访问类与具体DataSource的耦合；
系统中存在的多台数据库服务器现在地位可能相当也可能不相当，但数据访问类在系统启动时间无法明确到底应该使用哪一个数据源进行数据访问，而必须在系统运行期间通过某种条件来判定到底应该使用哪一个数据源，这个时候，我们也得使用这种“合纵连横 ”的方式向数据访问类暴露一个统一的DataSource，由该DataSource来解除数据访问类与具体数据源之间的过紧耦合；

更多场景需要读者根据具体的应用来判定，不过，并非所有的应用要做这样的处理，如果能够保持简单，那尽量保持简单，毕竟，我们提倡K.I.S.S.(Keep It Simple,Stupid)嘛！要实现这种“合纵连和 ” 的多数据源管理方式，总的指导原则就是实现一个自定义的DataSource，让该DataSource来管理系统中存在的多个与具体数据库挂钩的数据源，数据访问类只跟这个自定义的DataSource打交道即可。在spring2.0.1发布之前，各个项目中可能存在多种针对这种情况下的多数据源管理方式，不过，spring2.0.1发布之后，引入了AbstractRoutingDataSource，使用该类可以实现普遍意义上的多数据源管理功能。

假设我们有三台数据库用来实现负载均衡，所有的数据访问请求最终需要平均的分配到这三台数据库服务器之上，那么，我们可以通过继承AbstractRoutingDataSource来快速实现一个满足这样场景的原型(Prototype):

public class PrototypeLoadBalanceDataSource extends AbstractRoutingDataSource  {

 private Lock            lock = new ReentrantLock();
 private int          counter = 0;
 private int dataSourceNumber = 3;

 @Override
 protected Object determineCurrentLookupKey() {
  lock.lock();
  try
  {
   counter++;
   int lookupKey = counter % getDataSourceNumber();
   return new Integer(lookupKey);
  }
  finally
  {
   lock.unlock();
  }
 }
 // ...
}

我们在介绍AbstractRoutingDataSource的时候说过，要继承该类，通常只需要给出determineCurrentLookupKey()方法的逻辑即可。下面是针对PrototypeLoadBalanceDataSource的配置：

<bean id="dataSourc1" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
 <property name="url" value=".."/>
 <property name="driverClassName" value=".."/>
 <property name="username" value=".."/>
 <property name="password" value=".."/>
 <!-- other property settings -->
</bean>

<bean id="dataSource2" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
 <property name="url" value=".."/>
 <property name="driverClassName" value=".."/>
 <property name="username" value=".."/>
 <property name="password" value=".."/>
 <!-- other property settings -->
</bean>

<bean id="dataSource3" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
 <property name="url" value=".."/>
 <property name="driverClassName" value=".."/>
 <property name="username" value=".."/>
 <property name="password" value=".."/>
 <!-- other property settings -->
</bean>

<util:map id="dataSources">
 <entry key="0" value-ref="dataSource1"/>
 <entry key="1" value-ref="dataSource2"/>
 <entry key="2" value-ref="dataSource3"/>
</util:map>

<bean id="dataSourceLookup" class="org.springframework.jdbc.datasource.lookup.MapDataSourceLookup">
 <constructor-arg>
  <ref bean="dataSources"/>
 </constructor-arg>
</bean>

<bean id="dataSource" class="..PrototypeLoadBalanceDataSource">
 <property name="defaultTargetDataSource" ref="dataSourc1"/>
 <property name="targetDataSources" ref="dataSources"/>
 <property name="dataSourceLookup" ref=""/>
</bean>

<bean id="jdbcTemplate" class="org.springframework.jdbc.core.JdbcTemplate">
 <property name="dataSource" ref="dataSource"/>
</bean>

<bean id="someDao" class="...">
 <property name=""jdbcTemplate"" ref=""jdbcTemplate""/>
 <!-- other property settings -->
</bean>

因为我们不想使用AbstractRoutingDataSource的默认键值(Key)查找行为(根据指定的键值(Key)通过JNDI进行查找)，所以，我们为PrototypeLoadBalanceDataSource重新设置了DataSourceLookup，转而使用 MapDataSourceLookup。

Tip

在PrototypeLoadBalanceDataSource中，我们直接将查找的键值(Key)写死到了代码中，实际上，更多时候，我们会将键值 (Key)绑定到当前线程上，而determineCurrentLookupKey()方法内直接从当前线程取得绑定的Key返回即可。而这种情况下对Key的更改也变得更加灵活多变，比如，我可以在数据访问类内直接将我要访问的数据源对应的查找Key绑定到当前线程，我也可以在系统的某个位置设置拦截器(Interceptor)，当拦截到相应事件的时候，根据逻辑设置绑定到当前线程的查找键值(Key)等等。读者可以先思考如果让你来实现这么一个AbstractRoutingDataSource，你应该如何处理。不过，如果你已经迫不及待，那可以直接转向 spring的事务管理一章的扩展篇，我将在那里为你展示详细的实现过程。

有了AbstractRoutingDataSource之后，实现这种“合纵连横 ”的多数据源管理，将不再像最初看起来那么复杂而神秘。

4.4.2.3. 结束语

因为以上两种多数据源的管理方式在实际的使用过程中可能还有一些变数，所以，最后笔者还是觉得应该提及两点：

不管是“独立主权 ”的多数据源管理方式还是“合纵连横 ”的多数据源管理方式，单独使用任何一种都是有其特定的应用场景的，不过，这并不意味着二者是相互竞争甚至割裂的，实际上，如果必要，我们完全可以组合两种多数据源管理方式。
如果我们将“合纵连横 ”的多数据源作为一个整体放入“独立主权 ”的多数据源场景中的话，我们可以得到如下的一幅画卷：

Figure 4.11. “合纵连横 ”争取“主权独立 ”

如果我们将“独立主权 ”的多个数据源先分别注入上一层对象，然后将上一层对象和数据源作为一个整体再并入“合纵连横 ”的多数据源场景的话，那么，我们又可以得出另一幅图景：

Figure 4.12. 从“主权独立 ”并入“合纵连横 ”

当然，如果愿意，你还可以根据情况采取进一步的组合措施，不过，在进行之前，还是需要你首先全面评估一下整体情况，看是否真的需要这么做，毕竟，复杂度的过多引入有些时候并非必要的。
在“主权独立 ”的多数据源场景中，我们是将独立的数据源注入给了JdbcTemplate，但这只是为了演示的目的，实际上，对于IBatis以及Hibernate来说，这样的场景也是类似的；不过，在“合纵连横 ”的多数据源场景中，将JdbcTemplate的使用类推IBatis，即SqlMapClientTemplate，是可以的，但以同样的方式类推到Hibernate则有需要注意的地方。我们可以将“合纵连横 ” 的多个数据源注入给Hibernate的SessionFactory(实际上是通过Spring的LocalSessionFactoryBean)，然后HibernateTemplate直接引用这个SessionFactory即可，但当你开启了Hibernate的二级缓存的时候(与SessionFactory挂钩)，这样的多个数据源直接注入SessionFactory并且可以动态查找替换的方式可能造成问题。如果二级缓存中有与当前使用的DataSource挂钩的内容，而这个时候切换到了下一个DataSource，那么二级缓存里的内容需要你根据情况进行合理的处理，或者清空，或者通过某种方式来同步，否则在并发的情况下，难免出现问题，当然啦，如果你可以忽略这样的数据冲突，那可能也有不处理的理由。如果你不需要开启Hibernate的二级缓存，或者可以和略二级缓存数据的不一致性，那么，采用“合纵连横 ”的多数据源直接注入使用的SessionFactory的方式实现多个数据源的管理是可以的；否则的话，可以将“独立主权 ”的多数据源管理方式并入“合纵连横 ” 的多数据源管理方式，以SessionFactory一级替代DataSource一级，这也就是第二种组合场景所描绘的那样。这个时候，你可以像Spring提供AbstractRoutingDataSource那样，提供一个 AbstractRoutingSessionFactory，也可以自己实现一个SessionFactory来屏蔽多个具体的 SessionFactory，总之方法和原则跟多个数据源的处理方式是类似的，至于你要采用设计模式还是AOP，那就看你的啦！

分享到：

Document对象内容集合 | php3.5 安装

2009-12-02 13:14
浏览 2028
评论(0)
查看更多

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论