TX-LCN 框架 - 技术栈

TX-LCN 框架通俗教学（面试场景版）

一句话概括

TX-LCN 是分布式事务的 "交通警察"，确保多个微服务操作要么全部成功（比如转账扣款和到账），要么全部回滚（比如网购下单失败后库存自动恢复）。

核心原理类比

想象一个 团队合作项目：

项目经理（TxManager）：统筹全局，记录任务进度，决定最终提交或回滚。
组员（微服务）：各自完成任务（比如下单、扣库存），但完成后先举手说 "我完成了"，但不真正提交结果。
统一行动：所有人完成后，项目经理喊 "一起提交！"；如果有人失败，则喊 "全部撤销！"

技术核心三步走

创建事务组（项目经理开会议）

第一个服务（如订单服务）向 TxManager 申请一个事务组 ID（类似项目编号）。

java 复制代码

// 示例代码（Spring Cloud）
@Transactional
@LcnTransaction
public void createOrder() {
    // 1. 创建订单（本地事务未提交）
    orderDao.insert();
    // 2. 调用库存服务（加入同一事务组）
    stockService.reduceStock();
}

加入事务组（组员报到）
- 其他服务（如库存服务）通过事务组 ID 加入，执行操作但本地事务不提交。
java 复制代码
```
@Transactional
@LcnTransaction
public void reduceStock() {
    // 扣减库存（本地事务未提交）
    stockDao.update();
}
```
通知提交/回滚（项目经理发令）
- 所有服务执行成功后，TxManager 通知大家提交事务；任一失败则通知回滚。

举个实际例子

场景：用户下单买手机（订单服务 + 库存服务）

正常流程：
1. 订单服务：生成订单（状态为 "未支付"）。
2. 库存服务：手机库存减 1。
3. TxManager 确认两者成功 → 订单和库存操作正式提交。
异常流程：
1. 订单服务生成订单成功。
2. 库存服务发现库存不足 → 向 TxManager 报错。
3. TxManager 通知回滚 → 订单服务撤销生成的订单。

对比其他方案（面试加分项）

方案	特点	适用场景
TX-LCN	对代码侵入低，类似 "延迟提交"	简单分布式事务，短耗时操作
Seata AT	自动反向生成 SQL 回滚，性能更高	高并发场景
TCC	手动写补偿逻辑（Try-Confirm-Cancel）	强一致性需求，如金融业务
消息队列	最终一致性，异步解耦	允许延迟一致，如物流状态更新

面试常见问题

TX-LCN 如何保证数据一致性？
- 通过代理数据源拦截 SQL，本地事务暂不提交，等待 TxManager 的全局决策。
如果某个服务宕机了怎么办？
- TxManager 会记录事务状态，若超时未响应，自动触发回滚，避免资源长期锁定。
LCN 模式与 TCC 模式的区别？
- LCN：通过锁住资源（如数据库行）实现一致性，类似 "占座"；
- TCC：需要开发者手动编写补偿逻辑（如订单状态改为 "已取消"）。

总结

TX-LCN 像一位高效的协调员，用 "延迟提交+统一指挥" 解决分布式事务难题。记住它的核心是 事务组 和 两阶段提交，结合业务特点选择合适的模式即可！