使用@Transactional(readOnly=true)时延迟增加

Question

我正在使用一个后端服务（Spring Boot 2.2.13.RELEASE + Hikari + JOOQ），该服务使用配置有写入器（主）节点和读取器（只读副本）节点的 AWS Aurora PostgreSQL 数据库集群。读取器节点刚刚闲置/热等待在故障转移时提升为主节点。

最近，我们决定开始专门从 Reader Node 为我们的一些 GET 端点提供查询服务。为了实现这一点，我们使用了 RoutingDataSource 的“风格”，以便每当使用 @Transactional(readOnly=true) 注释服务时，都会针对读取器数据源执行查询。

直到这里一切都很顺利。然而，在应用此解决方案后，我注意到与主数据源相比，延迟增加了 3 倍。

深入研究后，我发现每个事务都会对数据库进行几次额外的往返以设置会话特征：

将会话特征设置为只读 实际查询/查询 设置会话特性 读写

为了改进这一点，我尝试使用 pg-jdbc 42.2.10 中引入的 readOnlyMode 设置。此设置允许控制连接设置为只读 (readOnly=true) 时的行为。

https://jdbc.postgresql.org/documentation/head/connect.html

在我的第一次尝试中，我使用了 readOnly=true 和 readOnlyMode=always。尽管我弯下腰查看 SET SESSION CHARACTERISTICS 语句，但延迟仍然没有变化。最后我尝试使用 readOnly=false 和 readOnlyMode=ignore。最后一个选项导致延迟减少，但仍然比以前更糟糕。

其他人有过这种设置的经验吗？最佳配置是什么？ 我不需要将事务标记为只读（除了告诉路由数据源使用只读副本），因此我想弄清楚是否可以执行其他操作，以便延迟在Writer 和 Reader 节点。

注意：目前读取器节点仅服务所有流量的 1%（+- 20req/s）。

Answer 1

我的应用程序中有非常类似的场景，在将 @Transactional(read-only=true) 添加到少数查询后，延迟增加了，并且我们看到连接池耗尽的问题。我认为这可能是由于额外的同步 JDBC 调用造成的。

您是否弄清楚延迟增加的根本原因是什么？或者除了回滚@transcation注释之外你如何修复它？