聊聊，啥叫分布式事务

哎，先说个比喻吧。

你想象一下你在玩多人联机游戏，大家一起抢怪。

每个人dou得出手，结果要么全成功，要么全失败。

这就跟数据库里跨库操作差不多，必须要“一刀切”。

咱们把这套“一刀切”叫Zuo分布式事务。

说白了就是多个服务、多个库一起打交道，数据要保持一致。

哈哈，这事儿听起来高大上，其实背后全是坑。

先别慌，分布式事务的基本模型

Zui常见的模型有两大类：强一致和Zui终一致。

强一致像是老爸严厉的规矩，一旦出错立马回滚。

Zui终一致geng像是闺蜜的宽容，大多数情况下Neng接受短暂的不一致，Zui后再把数据对齐。

咱们先撸一下两阶段提交。

Coordinator先问大家：“准备好没？”

大家回答“OK”，Coordinator再喊：“正式提交！”

Ru果有人说“不行”，那就全撤销。

听起来简单，但实际运行中会出现阻塞、单点故障等问题。

三阶段提交小补丁

为了缓解2PC的阻塞，3PC多加了一个预检查阶段。

可是多来一次网络往返，性Neng直接降半截。

所以hen少直接用3PC，而是选TCC或者Saga。

TCC——Try‑Confirm‑Cancel 的三部曲

TCC其实就是把业务拆成三个明确的步骤：

Try: 预留资源，不真正扣减；

Confirm: 确认资源正式使用；

Cancel: 释放预留资源。

kan起来hen啰嗦，但好处是每一步douKe以幂等，而且Neng精准控制回滚路径。

TCC 示例代码

@Service
public class OrderTransactionService {
    @Autowired
    private OrderDao orderDao;
    @Autowired
    private RocketMQTemplate rocketMQTemplate;
    /**
     * 创建订单并发送消息
     */
    public void createOrderWithMessage {
        // 构建消息
        Message message = MessageBuilder
                .withPayload, order.getUserId))
                .setHeader)
                .build;
        // 发送事务消息
        TransactionSendResult sendResult = rocketMQTemplate.sendMessageInTransaction(
                "order-topic",
                message,
                order // 本地事务参数
        );
        if  != SendStatus.SEND_OK) {
            throw new RuntimeException;
        }
    }
    /**
     * 事务监听器
     */
    @RocketMQTransactionListener
    class OrderTransactionListener implements RocketMQLocalTransactionListener {
        @Autowired
        private OrderDao orderDao;
        /**
         * 执行本地事务
         */
        @Override
        public RocketMQLocalTransactionState executeLocalTransaction {
            Order order =  arg;
            try {
                // 执行本地事务：创建订单
                orderDao.insert;
                // 本地事务成功，提交Half消息
                return RocketMQLocalTransactionState.COMMIT;
            } catch  {
                // 本地事务失败，回滚Half消息
                return RocketMQLocalTransactionState.ROLLBACK;
            }
        }
        /**
         * 回查本地事务状态
         */
        @Override
        public RocketMQLocalTransactionState checkLocalTransaction {
            String orderId = msg.getHeaders.get;
            // 查询订单是否存在
            Order order = orderDao.selectById;
            if  {
                // 订单存在本地事务Yi提交
                return RocketMQLocalTransactionState.COMMIT;
            } else {
                // 订单不存在本地事务未提交或Yi回滚
                return RocketMQLocalTransactionState.ROLLBACK;
            }
        }
    }
}

Saga——长流程下的状态机艺术

Saga 把一个大事儿拆成一串小事儿，每一步dou有对应的补偿动作。

比如下单 → 扣库存 → 扣余额 → 发货，每一步成功后记录日志，Ru果后面哪步卡住就逆向执行补偿：退库存、退款等等。

Saga 非常适合跨服务链路长、需要容错的业务场景，比如旅游预订、金融审批等。

Saga 小案例：订单支付超时自动撤销

@Service
public class OrderSagaService {
    @Autowired private OrderDao orderDao;
    @Autowired private StockService stockService;
    @Autowired private PaymentGateway paymentGateway;
    public void placeOrder {
        // Step1: 创建订单
        orderDao.insert;
        // Step2: 冻结库存
        stockService.tryReserve, order.getQty);
        // Step3: 调用支付网关
        paymentGateway.tryPay, order.getAmount);
        // 成功则进入 Confirm 阶段，由外部系统回调触发：
        // confirmOrder;
    }
    public void confirmOrder {
        // Confirm：正式扣减库存、确认支付、geng新订单状态为 PAID
    }
    public void cancelOrder {
        // Cancel：释放库存、撤销支付、geng新订单状态为 CANCELED
    }
}

主流框架速览——挑个合适自己的玩具箱

框架/模式	侵入性	性Neng表现	适用场景
Seata AT	低	中等	大多数电商业务 对性Neng要求不是极致的情况
Seata TCC	高	高	金融转账、库存扣减等强一致需求
Seata Saga	中等	高	长流程业务，如旅游预订、供应链协同
XA	低	低	对强一致要求极高且吞吐量不敏感的内部系统
本地消息表	低中等适用于异步化场景，如积分同步、审计日志

性Neng调优小技巧——别让事务成瓶颈呀！ # 合并小事务，批量写入

@Transactional 
public void batchCreateOrders { 
// 批量插入 
orderDao.batchInsert; 
// 同步发送批量 MQ 消息 
rocketMQTemplate.syncSend
.map)) . build)
 , timeout); 
}
 

# 异步非核心操作

把通知、统计这些“软需求”丢给线程池去干吧。

 CompletableFuture.runAsync -> { 
sendNotification; 
updateStats; 
}); 
 

# 超时与容错

设置合理超时时间，比如下单30秒未完成就自动回滚。

graph TB A --> B B --> C 

# 防止死锁，小锁粒度

数据库层面尽量只锁住当前行，不要整表扫。

对象级锁也Ke以考虑 Redis 分布式锁配合 TTL。

常见坑 & FAQ

说实话，这里经常踩坑。下面列几个你可Neng碰到的问题。

1️⃣ 为什么我的分布式事务总是卡住？

大概率是网络抖动导致 Prepare 阶段超时。咱们Ke以把超时时间调大一点，然后在协调者那边加上重试机制。

解决思路：

监控网络 RTT，发现异常及时告警；

使用可靠消息 + 本地表防止“半写”丢失；

Ru果使用 Seata，可开启 async commit 减少阻塞。

🤔 为什么百度不收录？

哈哈，这个其实跟技术关系不大，是 SEO 的事儿。百度爬虫喜欢结构清晰、有语义标签的页面。Ru果你的页面里缺少 `` 信息或者 robots.txt 把它拦住了它就懒得抓取啦。咱们写文章的时候，多加点标题层级 、正文段落 ，别忘了放点关键字，自然会被收录。还有啊，Ru果服务器返回了太慢，也会被百度甩掉。简单来说就是 “内容+结构+速度” 三件套必须齐活儿！你懂的～

怎么改进？

确保页面返回码是 200 而不是 404；

页面加载时间控制在 1~2 秒以内；

使用 `