不同隔离级别下数据库事务并发冲突相关技术问题咨询

高隔离级别下写冲突事务失败，数据库为何不自动重试？应用层重试是否属于最佳实践？ #

• 数据库层默认不做自动重试的核心原因是无法感知事务边界内的非数据库操作副作用：绝大多数业务事务不是纯SQL的集合，事务执行过程中可能夹杂发送消息、调用第三方接口、更新本地缓存、写入文件等不可逆操作，数据库完全无法判断这些操作是否支持回滚、是否允许重复执行，盲目重试会直接导致业务逻辑错乱，比如重复给用户发券、重复扣款、重复推送通知。
• 数据库作为通用底层存储，无法适配所有业务的重试策略：不同场景对重试的容忍度差异极大——面向C端的接口要求毫秒级响应，重试1次失败就需要快速返回；后台离线批量任务可以容忍几十次的重试；资金类核心交易场景甚至不允许自动重试，必须人工介入校验，这类业务决策不可能由数据库统一实现。目前仅少数数据库提供了可选的自动重试开关，默认均为关闭状态，本质还是把重试决策权交给上层应用。
• 应用层在事务最外层做重试是行业通用的合理实践，但需要满足几个前提：重试必须完整重跑整个事务的所有逻辑（从BEGIN到COMMIT的全流程），不能仅重试失败的单条SQL；要配置合理的退避策略和重试次数上限，避免高冲突下的无效重试打满数据库连接；涉及外部副作用的操作必须保证幂等，避免重试带来的重复执行问题。

读已提交（READ_COMMITTED）/读未提交（READ_UNCOMMITTED，即你提到的DIRTY READ）级别下，并发修改同一份数据为何不会触发事务失败？ #

• 首先纠正一个常见认知偏差：隔离级别从不是仅控制读行为，写冲突的处理规则本身就是隔离级别定义的核心组成部分。你提到的“应当禁止并发写冲突”是Serializable（串行化）级别的要求，而非所有隔离级别的强制约束——ANSI SQL标准对不同隔离级别允许的异常有明确定义，RC和RU级别本身就允许不可重复读、幻读等一致性异常，设计目标就是牺牲部分一致性保证换取更高的并发吞吐。
• 从实现逻辑看，RC/RU级别的写冲突处理是语句级而非事务级的：两个并发事务修改同一行数据时，未拿到行锁的事务会阻塞等待锁释放，等持有锁的事务提交/回滚后，等待的事务会直接读取该行最新提交的版本，继续执行当前修改语句，不会终止整个事务。这种逻辑和RC级别的一致性承诺完全匹配：RC级别本来就允许同一事务内两次读取同一行得到不同结果，自然不需要因为读到其他事务提交的新值就回滚整个事务。RU级别的实现更宽松，部分场景下甚至不会等待行锁，直接读取其他事务未提交的行版本，更不会触发事务失败。
• 这种设计的适用场景非常明确：就是绝大多数读多写少、对短暂一致性偏差容忍度高的业务场景，比如内容展示、商品列表查询等，RC级别下的写并发性能通常比RR/Serializable级别高数倍，足以满足普通业务的需求。

不同来源创建的数据源隔离级别行为是否一致？多数据源架构是否存在潜在问题，是否需要全局统一数据源？ #

• 你的核心判断部分正确：隔离级别的行为最终由数据库服务端和当前连接的配置共同决定，和连接是Spring托管创建还是手动传入配置创建没有直接关系——只要两个数据源连接的是同一个数据库实例、同一个逻辑库，连接上设置的隔离级别参数一致，那么并发事务的冲突处理逻辑和使用同一数据源的场景没有区别。
• 但这种两个独立维护的数据源架构存在很多和隔离级别无关的潜在风险：
  • 配置不一致风险：Spring托管的数据源通常会统一配置连接池参数（最大连接数、超时时间、连接探活规则、自动提交开关、时区、字符集、JDBC驱动版本等），手动创建的数据源如果和Spring侧配置不对齐，很容易出现连接泄漏、连接数打满、同SQL执行结果不一致等偶发问题，排查成本极高。如果两边JDBC驱动版本不同，甚至可能出现同一隔离级别参数传递到底层的逻辑不一致，导致实际隔离行为不符合预期。
  • 事务无法互通：Spring的事务管理器仅能管理自身托管数据源的连接，如果你有业务逻辑同时调用两个模块的写操作，Spring无法把两个数据源的操作纳入同一个本地事务，很容易出现一边操作提交成功、另一边操作失败回滚的一致性问题，本质上属于跨数据源的分布式事务场景，没有额外组件支撑的话根本无法保证原子性。
• 是否需要全局统一单数据源要根据业务场景判断：如果两个模块本身就是操作同一个数据库，没有分库、多租户隔离这类特殊需求，强烈建议统一使用Spring托管的单一数据源，可以规避绝大多数连接、事务相关的问题；如果两个模块本来就操作不同的物理数据库，不需要强行统一数据源，但需要对齐两边的连接配置、驱动版本，跨数据源的写操作要根据业务一致性要求选择合适的分布式事务方案，同时对每个数据源做独立的监控。

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