同一事务内并行执行SQL语句的R2DBC实现疑问

你的观察完全符合实际情况，以下是具体解释和分析：

核心结论 #

• 同一事务内的所有语句必须通过同一个连接执行：这是数据库事务的基本特性，事务的上下文（隔离级别、锁、数据一致性状态等）与单个连接绑定，无法跨连接共享事务。
• 同一连接对象的所有语句会串行执行：这是由R2DBC驱动的设计、数据库通信协议（TCP单连接的请求-响应模式）以及SQL Server的事务处理机制共同决定的。

原因详解 #

1. 数据库事务与连接的绑定关系
   数据库事务是基于单个连接创建的，所有事务内的操作都依赖该连接维护的会话状态。一旦切换连接，就脱离了原事务的上下文，无法保证ACID特性，因此同一事务必须复用同一个连接。

2. 单连接的串行执行限制

   • 驱动层面：R2DBC的MSSQL驱动（以及绝大多数数据库驱动）对单个连接的操作是非线程安全的，内部会维护一个请求队列，串行处理来自不同线程的操作请求。你用并行调度器并发调用同一连接的方法，本质上是在多个线程中竞争同一个非线程安全资源，不仅会导致请求队列溢出，还可能引发数据不一致或驱动异常。
   • 通信协议层面：数据库连接基于TCP协议，同一TCP连接是半双工的，同一时刻只能处理一个请求-响应周期。驱动必须等待服务器返回前一个请求的响应后，才能发送下一个请求，无法在同一连接上并行发送多个请求。
   • SQL Server层面：即使驱动能并行发请求，SQL Server对同一连接内的事务操作也会强制串行执行。事务的一致性要求操作按顺序生效（比如先插入再查询必须能读到插入的数据），并行执行会破坏事务的ACID特性。

你的配置与代码问题分析 #

• 连接池配置：你的MssqlConnectionFactory配置是标准写法，没有问题。
• 测试代码问题：用Schedulers.newParallel并发操作同一连接的方式违反了R2DBC连接的非线程安全要求，这是导致请求队列已满错误的直接原因。R2DBC的正确用法是通过反应式链串行编排同一连接上的操作，而非多线程并发调用。

替代方案 #

如果你的目标是减少高延迟场景下的总耗时，可考虑以下方案：

• 合并SQL语句：将多个独立查询合并为一条语句（比如用UNION ALL批量查询），减少TCP往返次数，提升效率。
• 批量操作：对于写操作，使用R2DBC的批量执行API（如createStatement后多次调用add方法），一次性发送多个操作请求。
• 放弃事务并行：如果操作之间无依赖且原子性要求不高，可使用多个连接并行执行，在应用层处理结果合并；若必须保证原子性，只能接受事务内的串行执行，或考虑分布式事务（但开销极大，不推荐）。

修正后的测试代码示例 #

以下是符合R2DBC规范的串行执行代码：

pool.create()
    .flatMap(conn -> 
        Mono.from(conn.setAutoCommit(false))
            .thenMany(Flux.range(0, 10)
                .flatMap(j -> 
                    Mono.from(conn.createStatement("select " + j).execute())
                        .flatMap(result -> Mono.from(result.map((row, meta) -> row.get(0, Integer.class))))
                )
            )
            .doOnNext(System.out::println)
            .doFinally(signal -> Mono.from(conn.close()).subscribe())
    )
    .blockLast();

内容的提问来源于stack exchange，提问作者glu