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

Question

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

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

有没有办法告诉Hibernate自动将CREATE/UPDATE查询路由到一个数据源,SELECT到另一个数据源？我不想做任何基于对象类型的分片或任何事情 - 只是将不同类型的查询路由到不同的数据源.

Answer 1

可以在这里找到一个例子:https://github.com/afedulov/routing-data-source.

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标识符？请记住,determineCurrentLookupKey只要TransactionsManager请求连接,就会调用该方法.重要的是要记住每个事务都与一个单独的线程"关联".更准确地说,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());
  }

哎呀 >_< !这绝对不像我想在每个只读方法中放入的东西.我们可以做得更好吗？当然!这种"在方法开始时做某事,然后在最后做某事"的模式应敲响钟声.救援方面!

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

Answer 2

我不认为决定将SELECT分配给一个DB（一个从属），将CREATE / UPDATES分配给另一个DB（主）是一个很好的决定。原因如下：

• 复制不是瞬时的，因此您可以在主数据库中创建某些内容，并作为同一操作的一部分，从从数据库中选择它，然后注意数据尚未到达从数据库。
• 如果从属服务器之一发生故障，则不应阻止您在主服务器中写入数据，因为一旦从属服务器备份，其状态就会与主服务器同步。但就您而言，您的写操作取决于主服务器和从属服务器。
• 如果您实际上使用的是2个dbs，那么您将如何定义事务性？

我建议将主数据库用于所有WRITE流，以及它们可能需要的所有指令（无论是SELECT，UPDATE还是INSERTS）。然后，处理只读流的应用程序可以从从数据库读取。

我还建议您使用单独的DAO，每个DAO都有自己的方法，这样您就可以在只读流和写入/更新流之间有明显的区别。

Answer 3

您可以创建 2 个会话工厂，并使用 BaseDao 包装 2 个工厂（或者 2 个 hibernateTemplates，如果您使用它们），并使用 on 工厂的 get 方法和另一个工厂的 saveOrUpdate 方法