如何设置休眠以读/写不同的数据源？

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

Spring 提供了 DataSource 的一个变体，称为 .它可以用于代替标准的 DataSource 实现，并使一种机制能够确定在运行时对每个操作使用哪个具体的数据源。您需要做的就是扩展它并提供抽象方法的实现。这是实现自定义逻辑以确定具体数据源的位置。返回的对象用作查找键。它通常是一个字符串或 en Enum，在 Spring 配置中用作限定符（详细信息将在下面）。AbstractRoutingDatasourcedetermineCurrentLookupKey

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 对象是什么，它如何知道要返回哪个数据源标识符？请记住，每当 TransactionsManager 请求连接时，都会调用该方法。重要的是要记住，每个事务都与单独的线程“关联”。更准确地说，TransactionsManager 将 Connection 绑定到当前线程。因此，为了将不同的事务分派给不同的目标数据源，我们必须确保每个线程都能可靠地识别哪个数据源注定要使用它。这使得利用 ThreadLocal 变量将特定数据源绑定到线程，从而绑定到事务变得很自然。这是如何完成的：determineCurrentLookupKey

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将负责根据名称正确解析它。关联的数据源配置和键可能如下所示：

  ....
<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

现在，我们可以控制将使用哪个数据源，并根据需要转发请求。看起来不错！

...还是？首先，那些对神奇的DbContextHolder的静态方法调用确实很突出。它们看起来不属于业务逻辑。而他们没有。它们不仅没有传达目的，而且看起来很脆弱且容易出错（忘记清理dbType怎么样）。如果在 setDbType 和 cleanDbType 之间引发异常怎么办？我们不能忽视它。我们需要绝对确定我们重置了 dbType，否则返回到 ThreadPool 的线程可能处于“中断”状态，尝试在下一次调用中写入副本。所以我们需要这个：

  @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());
  }

哎呀！这绝对不像我想放入每个只读方法中的东西。我们能做得更好吗？答案是肯定的！这种“在方法开始时做某事，然后在最后做某事”的模式应该敲响警钟。救援方面！>_<

不幸的是，这篇文章已经太长了，无法涵盖自定义方面的主题。您可以使用此链接跟进使用方面的详细信息。

我不认为决定SELECT应该去一个数据库（一个从站）和CREATE/UPDATES应该去另一个数据库（主数据库）是一个非常好的决定。原因是：

• 复制不是即时的，因此您可以在主数据库中创建一些内容，并且作为相同操作的一部分，从从数据库中选择它，并注意数据尚未到达从数据库。
• 如果其中一个从站出现故障，则不应阻止您在主站中写入数据，因为一旦从站备份，其状态将与主站同步。但是，在您的情况下，您的写入操作同时依赖于主站和从站。
• 那么，如果您实际上使用的是 2 dbs，您将如何定义事务性？

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

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