。

长事务会长时间持有数据库锁和连接#xff0c;降低系统吞吐量#xff0c;甚至可能导致死锁或超时。

Spring

应用中合理的划分事务边界对于数据一致性、提高并发性能以及避免资源长时间占用即避免长事务至关重要。

长事务会长时间持有数据库锁和连接降低系统吞吐量甚至可能导致死锁或超时。

Spring

方法专注于完成一个明确、单一的业务逻辑单元。

如果一个方法做了太多不相关的事情它自然会变得更长其事务边界也会随之扩大。

实践:

Service

方法。

然后可以在一个更高层次的可能是非事务性的方法中编排调用这些小方法。

Transactional

DELETE且需要保证原子性要么全部成功要么全部回滚的操作才需要事务。

纯粹的读操作通常不需要事务除非需要特定隔离级别来保证读取一致性。

实践:

Transactional

JPA提供优化提示还能清晰地表明该方法的意图并且在某些数据库或配置下可能不允许写操作增加了一层安全性。

将非事务性逻辑移出事务边界

事务应该尽可能短只包裹必要的数据库操作。

任何不直接依赖于事务原子性的、耗时的操作都应该移到事务之外。

实践:

前置处理:

API、更新缓存如果能容忍短暂不一致、记录非关键日志、复杂计算等可以在

Transactional

orderRepository;Autowiredprivate

NotificationService

(非事务性)validateRequest(request);UserInfo

userInfo

createOrderInTransaction(request,

userInfo);//

(非事务性)notificationService.sendOrderConfirmation(createdOrder);

发送通知triggerLogisticsAsync(createdOrder.getId());

异步触发物流}Transactional

createOrderInTransaction(OrderRequest

request,

(调用另一个事务性方法通常会加入当前事务)inventoryService.decreaseStock(request.getProductId(),

order;}//

语句高效正确使用索引。

避免在事务内部执行大量数据的查询或处理如果可以先查询少量

ID然后在事务外处理。

使用批量操作Batching来减少数据库交互次数虽然批处理本身可能在一个事务内完成但它比逐条操作快得多。

利用异步处理

对于不需要立即完成、可以容忍延迟且不影响主事务一致性的操作将其异步化。

实践:

将耗时的后置处理如发送通知、更新统计、调用非关键外部服务标记为

Async

RabbitMQ由独立的消费者来处理。

这能让主事务快速提交和释放资源。

示例

(使用

{Thread.currentThread().interrupt();}}

}理解事务传播行为

如果当前存在事务则加入该事务否则创建一个新事务。

这是最常用的。

REQUIRES_NEW:

总是创建一个新事务。

如果当前存在事务则将当前事务挂起。

这可以用来将一个大的业务逻辑分解为几个独立的物理事务但要小心使用可能破坏整体原子性或在嵌套调用时增加复杂性。

SUPPORTS:

如果当前存在事务则加入该事务否则以非事务方式执行。

NOT_SUPPORTED:

以非事务方式执行。

如果当前存在事务则将当前事务挂起。

适合调用那些明确不需要事务或可能很慢的操作。

MANDATORY:

通过合理选择传播行为可以更精细地控制哪些代码段包含在哪个事务中。

例如可以将慢速的外部调用封装在

NOT_SUPPORTED

网络延迟是不可预测的外部系统故障可能导致事务长时间挂起。

等待用户输入更是绝对禁止。

实践:

将所有需要等待外部响应的操作移出核心事务。

如果必须基于外部调用的结果进行数据库操作考虑使用事务补偿机制如

TCC

编织配置更复杂。

最好的方法通常是良好地设计服务层避免复杂的自调用事务场景。

监控事务执行时间

应用中的事务边界确保事务既能保证数据一致性又能保持简短高效从而提升整体系统性能和稳定性。