如何设置Hibernate来读/写不同的数据源?

时间:2010-12-08 09:53:18

标签: java mysql hibernate spring architecture

使用Spring和Hibernate,我想写一个MySQL主数据库,并从基于云的Java webapp中的一个或多个复制的从属数据库中读取。

我找不到对应用程序代码透明的解决方案。我真的不想更改我的DAO以管理不同的SessionFactories,因为这看起来非常混乱,并且将代码与特定的服务器架构结合在一起。

有没有办法告诉Hibernate自动将CREATE / UPDATE查询路由到一个数据源,SELECT到另一个数据源?我不想根据对象类型进行任何分片或任何事情 - 只需将不同类型的查询路由到不同的数据源。

5 个答案:

答案 0 :(得分:16)

可在此处找到一个示例:https://github.com/afedulov/routing-data-source

enter image description here

Spring提供了DataSource的变体,称为AbstractRoutingDatasource。它可以用来代替标准的DataSource实现,并启用一种机制来确定在运行时为每个操作使用哪个具体的DataSource。您需要做的就是扩展它并提供抽象determineCurrentLookupKey方法的实现。这是实现自定义逻辑以确定具体DataSource的地方。返回的对象充当查找键。它通常是String或en Enum,在Spring配置中用作限定符(详细信息如下)。

package website.fedulov.routing.RoutingDataSource

import org.springframework.jdbc.datasource.lookup.AbstractRoutingDataSource;

public class RoutingDataSource extends AbstractRoutingDataSource {
    @Override
    protected Object determineCurrentLookupKey() {
        return DbContextHolder.getDbType();
    }
}

您可能想知道DbContextHolder对象是什么,以及它如何知道要返回哪个DataSource标识符?请记住,只要TransactionsManager请求连接,就会调用determineCurrentLookupKey方法。重要的是要记住每个事务都与一个单独的线程“关联”。更准确地说,TransactionsManager将Connection绑定到当前线程。因此,为了将不同的事务分派给不同的目标DataSource,我们必须确保每个线程都能可靠地识别要使用的DataSource。这使得利用ThreadLocal变量将特定DataSource绑定到Thread并因此绑定到Transaction是很自然的。这就是它的完成方式:

public enum DbType {
   MASTER,
   REPLICA1,
}

public class DbContextHolder {

   private static final ThreadLocal<DbType> contextHolder = new ThreadLocal<DbType>();

   public static void setDbType(DbType dbType) {
       if(dbType == null){
           throw new NullPointerException();
       }
      contextHolder.set(dbType);
   }

   public static DbType getDbType() {
      return (DbType) contextHolder.get();
   }

   public static void clearDbType() {
      contextHolder.remove();
   }
}

如您所见,您还可以使用枚举作为键,Spring将根据名称正确解析它。关联的DataSource配置和键可能如下所示:

  ....
<bean id="dataSource" class="website.fedulov.routing.RoutingDataSource">
 <property name="targetDataSources">
   <map key-type="com.sabienzia.routing.DbType">
     <entry key="MASTER" value-ref="dataSourceMaster"/>
     <entry key="REPLICA1" value-ref="dataSourceReplica"/>
   </map>
 </property>
 <property name="defaultTargetDataSource" ref="dataSourceMaster"/>
</bean>

<bean id="dataSourceMaster" class="org.apache.commons.dbcp.BasicDataSource">
  <property name="driverClassName" value="com.mysql.jdbc.Driver"/>
  <property name="url" value="${db.master.url}"/>
  <property name="username" value="${db.username}"/>
  <property name="password" value="${db.password}"/>
</bean>
<bean id="dataSourceReplica" class="org.apache.commons.dbcp.BasicDataSource">
  <property name="driverClassName" value="com.mysql.jdbc.Driver"/>
  <property name="url" value="${db.replica.url}"/>
  <property name="username" value="${db.username}"/>
  <property name="password" value="${db.password}"/>
</bean>

此时你可能会发现自己在做这样的事情:

@Service
public class BookService {

  private final BookRepository bookRepository;
  private final Mapper               mapper;

  @Inject
  public BookService(BookRepository bookRepository, Mapper mapper) {
    this.bookRepository = bookRepository;
    this.mapper = mapper;
  }

  @Transactional(readOnly = true)
  public Page<BookDTO> getBooks(Pageable p) {
    DbContextHolder.setDbType(DbType.REPLICA1);   // <----- set ThreadLocal DataSource lookup key
                                                  // all connection from here will go to REPLICA1
    Page<Book> booksPage = callActionRepo.findAll(p);
    List<BookDTO> pContent = CollectionMapper.map(mapper, callActionsPage.getContent(), BookDTO.class);
    DbContextHolder.clearDbType();               // <----- clear ThreadLocal setting
    return new PageImpl<BookDTO>(pContent, p, callActionsPage.getTotalElements());
  }

  ...//other methods

现在我们可以控制将使用哪个DataSource并转发请求。看起来不错!

......或者是吗?首先,那些对魔法DbContextHolder的静态方法调用确实很突出。他们看起来不属于业务逻辑。他们没有。他们不仅没有传达目的,而且看起来很脆弱且容易出错(如何忘记清理dbType)。如果在setDbType和cleanDbType之间抛出异常怎么办?我们不能忽视它。我们需要绝对确定我们重置dbType,否则返回到ThreadPool的Thread可能处于“已损坏”状态,尝试在下一次调用中写入副本。所以我们需要这个:

  @Transactional(readOnly = true)
  public Page<BookDTO> getBooks(Pageable p) {
    try{
      DbContextHolder.setDbType(DbType.REPLICA1);   // <----- set ThreadLocal DataSource lookup key
                                                    // all connection from here will go to REPLICA1
      Page<Book> booksPage = callActionRepo.findAll(p);
      List<BookDTO> pContent = CollectionMapper.map(mapper, callActionsPage.getContent(), BookDTO.class);
       DbContextHolder.clearDbType();               // <----- clear ThreadLocal setting
    } catch (Exception e){
      throw new RuntimeException(e);
    } finally {
       DbContextHolder.clearDbType();               // <----- make sure ThreadLocal setting is cleared         
    }
    return new PageImpl<BookDTO>(pContent, p, callActionsPage.getTotalElements());
  }

Yikes >_<!这绝对不像我想在每个只读方法中放入的东西。我们可以做得更好吗?当然!这种“在方法开始时做某事,然后在最后做某事”的模式应响铃。救援方面!

不幸的是,这篇文章已经花了太长时间来涵盖自定义方面的主题。您可以使用此link跟进使用方面的详细信息。

答案 1 :(得分:4)

我认为决定SELECTs应该转到一个DB(一个slave)并且CREATE / UPDATES应该转到另一个(master)是一个非常好的决定。原因是:

  • 复制不是即时的,所以你可以在主DB中创建一些东西,并且作为同一操作的一部分,从slave中选择它并注意数据还没有到达slave。
  • 如果其中一个从站关闭,则不应阻止在主站中写入数据,因为只要从站备份,其状态将与主站同步。但在您的情况下,您的写入操作依赖于主服务器和从服务器。
  • 如果你实际使用的是2 dbs,那么如何定义事务性?

我建议使用主数据库来处理所有WRITE流程,以及它们可能需要的所有指令(无论它们是SELECT,UPDATE还是INSERTS)。然后,处理只读流的应用程序可以从从DB读取。

我还建议使用单独的DAO,每个DAO都有自己的方法,这样您就可以清楚地区分只读流和写/更新流。

答案 2 :(得分:3)

您可以创建2个会话工厂并且包含2个工厂的BaseDao(如果您使用它们,则使用2个hibernateTemplates)并在工厂使用get方法,而在另一个工厂使用saveOrUpdate方法

答案 3 :(得分:1)

尝试这种方式:https://github.com/kwon37xi/replication-datasource

它可以很好地实现,并且无需任何额外的注释或代码即可轻松实现。它只需要@Transactional(readOnly=true|false)

我一直在使用Hibernate(JPA),Spring JDBC Template,iBatis这个解决方案。

答案 4 :(得分:0)

您可以使用DDAL来实现写入主数据库并在DefaultDDRDataSource中读取slave数据库而无需修改Daos,而且DDAL为多个从属数据库提供了负载平衡。它不依赖于弹簧或冬眠。有一个演示项目来展示如何使用它:https://github.com/hellojavaer/ddal-demos和demo1就是你所描述的场景。