此前我曾写过一个简单的多数据源事务管理器，其实现机制相当简单，开启事务时从多个数据源获取连接并设置事务的相关属性，然后执行业务逻辑，在执行业务逻辑过程中对 DAO 层使用 AOP 变更 TransactionSynchronizationManager (Spring Framework 5.3.14 API) 中当前线程绑定的数据源并执行 SQL 操作，最后根据是否产生了异常进行对应的提交或者回滚操作。不足之处在于其不能保证多数据源的数据一致性，比如数据源 A 提交事务后因为某些原因导致数据源 B 没能进行事务提交，那么就出现了数据不一致的情况。后面我看到 Spring Data 中的 ChainedTransactionManager，即链式事务管理器，发现实现方式几乎一致，其文档中提到：

PlatformTransactionManager implementation that orchestrates transaction creation, commits and rollbacks to a list of delegates. Using this implementation assumes that errors causing a transaction rollback will usually happen before the transaction completion or during the commit of the most inner PlatformTransactionManager.

The configured instances will start transactions in the order given and commit/rollback in reverse order, which means the PlatformTransactionManager most likely to break the transaction should be the last in the list configured. A PlatformTransactionManager throwing an exception during commit will automatically cause the remaining transaction managers to roll back instead of committing.

As consequence, a transaction can get into a state, where the first PlatformTransactionManager has committed its transaction and a subsequent PlatformTransactionManager failed to commit its transaction (e.g. caused by an I/O error or the transactional resource failed to commit for other reasons). In that case, commit(TransactionStatus) throws a HeuristicCompletionException to indicate a partially committed transaction. Rollback isn’t affected as the natural consequence of a missing commit is a rollback of a transactional resource. ChainedTransactionManager should be only used if the application can tolerate or recover from inconsistent state caused by partially committed transactions. In any other case, the use of ChainedTransactionManager is not recommended.

Instead of using ChainedTransactionManager for attaching callbacks to transaction commit (pre commit/post commit), either register a TransactionSynchronization to explicitly follow transaction cleanup with simplified semantics in case of exceptions.

源码参见：ChainedTransactionManager.java at 2.6.0。正如文档中所提到的，链式事务管理器应该仅仅被用于应用可以容忍事务部分提交造成的不一致状态的场景下。自 Spring Data 2.5 开始，该类已经被标记为废弃了，因为该实现并不能保证多数据源的一致提交或回滚，可能出现部分提交或者部分回滚的情况。相关 issue 可以参考文末链接。完善的分布式事务还是建议使用 TCC/SAGA 等方案进行实现。

Reference

Deprecate ChainedTransactionManager DATACMNS-1817 · Issue #2232 · spring-projects/spring-data-commons · GitHub
Deprecate ChainedTransactionManager by mp911de · Pull Request #2286 · spring-projects/spring-data-commons · GitHub
Reactive transaction manager · Issue #2323 · spring-projects/spring-data-commons · GitHub
What Is Seata

最近有一组应用后端的 MySQL 实例 QPS 达到了 3w 左右，CPU 使用率在 60% 左右，今天有空简单看了下，其中 SELECT 1 语句竟然占用了接近一半的查询，查了下对应应用的连接池配置，发现 DBCP 连接池配置中的 testOnBorrow 属性使用的默认配置，即 true，其解释如下：

The indication of whether objects will be validated before being borrowed from the pool. If the object fails to validate, it will be dropped from the pool, and we will attempt to borrow another.

即每次从池中拿到连接之前都对连接进行验证，猜测是该属性导致接近一半的 QPS 用于 SELECT 1 探测连接可用性。查询相关文档后将连接探测调整为空闲时进行，而不是每次从池中获取连接后都验证。

2022-01-13

调整完配置上线后通过监控数据观察到 QPS 几乎下降了一半，CPU 使用率也比之前降低了 20% 左右，效果还是比较明显的。

Reference

DBCP – BasicDataSource Configuration
Tomcat JDBC Connection Pool: testOnBorrow vs testWhileIdle - Stack Overflow
DruidDataSource配置 · alibaba/druid Wiki · GitHub
常见问题 · alibaba/druid Wiki · GitHub

OperatingSystemMXBean 中的 getFreePhysicalMemorySize() 方法返回的值为不含缓存的可用物理内存，该指标不能很好的反应 Linux 中实际可用的物理内存，因为 Linux 尽量使用内存的特性，该指标返回的数据几乎总是接近总物理内存，我们根据 /proc/meminfo 中返回的数据采集出类似 free 命令中 used 列的值以便更好的监测可用物理内存。

同事反馈有一组应用的定时任务不执行了，简单看了下，该应用未定义过基于 TaskScheduler 或 ScheduledExecutorService 实现的 Bean，此时 Spring 会在 ScheduledTaskRegistrar.scheduleTasks() 中创建一个单线程的任务调度器：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

/**
 * Schedule all registered tasks against the underlying {@linkplain
 * #setTaskScheduler(TaskScheduler) task scheduler}.
 */
protected void scheduleTasks() {
  if (this.taskScheduler == null) {
    this.localExecutor = Executors.newSingleThreadScheduledExecutor();
    this.taskScheduler = new ConcurrentTaskScheduler(this.localExecutor);
  }
  if (this.triggerTasks != null) {
    for (TriggerTask task : this.triggerTasks) {
      addScheduledTask(scheduleTriggerTask(task));
    }
  }
  if (this.cronTasks != null) {
    for (CronTask task : this.cronTasks) {
      addScheduledTask(scheduleCronTask(task));
    }
  }
  if (this.fixedRateTasks != null) {
    for (IntervalTask task : this.fixedRateTasks) {
      addScheduledTask(scheduleFixedRateTask(task));
    }
  }
  if (this.fixedDelayTasks != null) {
    for (IntervalTask task : this.fixedDelayTasks) {
      addScheduledTask(scheduleFixedDelayTask(task));
    }
  }
}

前段时间有线上实例被负载均衡判定不可用，随即被摘除，同时我们收到该实例的 JVM GC 耗时较长的告警及负载较高的告警。从操作系统级别的监控可以看到磁盘读取速度几乎达到该规格的上限，近 120MB/s，IOPS 为 2200 左右，使用 ssh 登录该实例需要等待很久，且进入实例后几乎无法输入命令，2 核的机器负载达到了 20 左右。持续了七八分钟会恢复正常，恢复正常后我首先查看了 GC 日志，确认是否存在大量 FullGC，但是从日志中并未发现长时间的 Full GC，普通的 GC 的 real 耗时都很久，部分 GC 日志如下：