阿里面试：秒杀的分布式事务， 是如何设计的？

尼恩说在前面

在40岁老架构师 尼恩的读者交流群(50+)中，最近有小伙伴拿到了一线互联网企业如阿里、滴滴、极兔、有赞、希音、百度、网易、美团的面试资格，遇到很多很多 分布式事务 的 重要的面试题：

秒杀的分布式事务， 是如何设计的？
抢购场景， 如何实现 分布式事务？
分布式事务了解吗？你们是如何解决分布式事务问题的？

Seata 如何实现 RC ？保证事务的隔离性？

Seata是如何解决分布式事务问题的？ Seata 的使用场景有哪些？

Seata 如何实现 事务的隔离性？

如何实现 强弱一致性 结合的分布式事务？

现在Java面试分布式事务几乎是标配。而分布式系统、分布式事务本身比较复杂，大家学起来也非常头疼。

其中，一道问过无数次的面试题就是：

 面试题：分布式事务了解吗？你们是如何解决分布式事务问题的？  （标准答案：见末尾） 

友情提示：看完此文，在分布式事务这块，基本可以做到吊打面试官了。

最近有小伙伴在面试阿里，又遇到了相关的面试题。小伙伴懵了，因为没有遇到过，所以支支吾吾的说了几句，面试官不满意，面试挂了。

所以，尼恩给大家做一下系统化、体系化的梳理，使得大家内力猛增，可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”，然后实现”offer直提”。

当然，这道面试题，以及参考答案，也会收入咱们的 《尼恩Java面试宝典PDF》V170版本，供后面的小伙伴参考，提升大家的 3高 架构、设计、开发水平。

《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请到文末公号【技术自由圈】获取

1：一图解读分布式事务

首先奉上一张全网最为牛逼的图，给大家做个总览：

上面这个图比较复杂，后面会结合 《尼恩Java面试宝典》配套视频，进行视频的录制。
具体的内容，请参见 尼恩 的最新 文章：
‘分布式事务’ 圣经：从入门到精通，架构师尼恩最新、最全详解 (50+图文4万字全面总结 )

1：Seata 和Rocketmq 事务消息实现，实现 强弱结合型事务

秒杀/抢购 等场景，都是属于 强弱结合型 的数据一致性场景。

首先看看 RocketMQ 的事务消息， 能够保证本地操作 + 消息发送的原子性。

具体来说， 主要是保证了本地方法执行和消息发送在一个分布式事务中，要不全部成功，要不全部失败。

见下图：

RocketMQ 通过发送 half 消息来实现，下面详细说明一下：

1. 消息发送方 向 Broker 发送一条 half 消息；
2. half 消息发送成功后，消息发送方 执行本地事务；
3. 如果 消息发送方 执行本地事务成功，则向 Broker 发送 commit 请求，否则发送 rollback 请求；
4. 如果 Broker 收到的是 rollback 请求，则删除保存的 half 消息；
5. 如果 Broker 收到的是 commit 请求，则把 half 消息投递到 真实 队列， 等待消费服务来拉取，然后删除保存的 half 消息；
6. 如果 Broker 没有收到 rollback/commit 请求，则会发送请求到 Producer 查询本地事务状态，然后根据 Producer 返回的本地状态做 commit/rollback 相关处理。

Seata + Rocketmq 事务消息 结合

Seata + Rocketmq 事务消息 结合的目标：

• 一 是保证 分布式事务 + 消息 发送的原子性。
• 二 是 再通过mq的重试机制，去保证订阅者的最终一致性，

Seata 的改进主要在 prepare 阶段。

Seata 提供了一个 SeataMQProducer 类，把 RocketMQ 中 TransactionListener 的方法加入到全局事务。

见下面代码：

SeataMQProducer(final String namespace, final String producerGroup, RPCHook rpcHook) {
 super(namespace, producerGroup, rpcHook);
 this.transactionListener = new TransactionListener() {
  @Override
  public LocalTransactionState executeLocalTransaction(Message msg, Object arg) {
   return LocalTransactionState.UNKNOW;
  }

  @Override
  public LocalTransactionState checkLocalTransaction(MessageExt msg) {
   String xid = msg.getProperty(PROPERTY_SEATA_XID);
   if (StringUtils.isBlank(xid)) {
    LOGGER.error("msg has no xid, msgTransactionId: {}, msg will be rollback", msg.getTransactionId());
    return LocalTransactionState.ROLLBACK_MESSAGE;
   }
   GlobalStatus globalStatus = DefaultResourceManager.get().getGlobalStatus(SeataMQProducerFactory.ROCKET_BRANCH_TYPE, xid);
   if (COMMIT_STATUSES.contains(globalStatus)) {
    return LocalTransactionState.COMMIT_MESSAGE;
   } else if (ROLLBACK_STATUSES.contains(globalStatus) || GlobalStatus.isOnePhaseTimeout(globalStatus)) {
    return LocalTransactionState.ROLLBACK_MESSAGE;
   } else if (GlobalStatus.Finished.equals(globalStatus)) {
    LOGGER.error("global transaction finished, msg will be rollback, xid: {}", xid);
    return LocalTransactionState.ROLLBACK_MESSAGE;
   }
   return LocalTransactionState.UNKNOW;
  }
 };

在 prepare 阶段，SeataMQProducer 向 RocketMQ Broker 发送 half 消息，执行本地事务，如果执行成功，则强行把 LocalTransactionState 改回 UNKNOW，等待 TC 发送指令，决定是 commit 或 rollback。

如果执行失败，返回 ROLLBACK_MESSAGE，TC 下发指令，回滚全局事务。

Seata + Rocketmq 事务消息 结合的使用场景

如果 MQ Broker 没有收到 commit/rollback 消息，则会回查 Producer 本地事务状态，也就是上面代码中的 checkLocalTransaction。

checkLocalTransaction 检查 全局事务状态，使用 XID 去查询 全局事务，去决定 half 消息 是 抛弃还是 投递 。

集成 RocketMQ 之后，Seata 的分布式事务调用流程， 下面以 订单服务、库存服务两个服务为例：

Apache Seata 引入 RocketMQ 后，支持的分布式事务场景更加丰富，使得 Seata 可以用于 强一致性 + 弱一致性 结合的场景。

10. 面试题标准答案: 如何解决分布式事务问题的？

现在Java面试，分布式系统、分布式事务几乎是标配。而分布式系统、分布式事务本身比较复杂，大家学起来也非常头疼。

 面试题：分布式事务了解吗？你们是如何解决分布式事务问题的？ 

Seata AT/TCC 和 MQ异步确保型 事务 是在生产中最常用。

• 强一致性模型， Seata AT/TCC 强一致方案 模式用于强一致主要用于核心模块，例如交易/订单等。

• 弱一致性模型。 MQ异步确保型 事务 弱一致方案一般用于边缘模块例如库存，通过MQ 原子消息和发布订阅，保证最终一致性，也可以业务解耦。

面试中如果你真的被问到，可以分场景回答：

（1）强一致性场景

对于那些特别严格的场景，用的是Seata AT模式来保证强一致性；

准备好例子：你找一个严格要求数据绝对不能错的场景（如电商交易交易中的库存和订单、优惠券），可以回答使用成熟的如中间件Seata AT模式。

 阿里开源了分布式事务框架seata经历过阿里生产环境大量考验的框架。  seata支持Dubbo，Spring Cloud。 

是Seata AT/TCC模式，保障强一致性，支持跨多个库修改数据；

• 订单库：增加订单

• 商品库：扣减库存

• 优惠券库：预扣优惠券

（2）弱一致性场景

基于可靠消息的最终一致性，各个子事务可以较长时间内异步，但数据绝对不能丢的场景。可以使用异步确保型事务事。

可以使用基于MQ的异步确保型事务，比如电商平台的通知支付结果：

• 积分服务：增加积分

• 会计服务：生成会计记录

（3）强弱结合一致性场景

两阶段 提交，如 Seata AT/TCC模式，保障强一致性，支持跨多个库修改数据；

• 订单库：增加订单
• 商品库：扣减库存
• 优惠券库：预扣优惠券

异步确保型事务，保障弱一致性，支持跨多个服务和系统修改数据，在下面的场景中相关的弱一致性操作为：

• 积分服务：增加积分
• 通知服务：发生通知

弱一致性部分：如果不是严格对数据一致性要求、或者由不同系统执行子事务的场景，如电商发送成功支付成功消息，只需要保障弱一致性即可。

Seata 新功能: 和Rocketmq 事务消息实现，实现 强弱结合型事务 , 具体参见下面的文章：

最新 Seata 集成了RocketMQ事务消息，Seata 越来越 牛X 了！ yyds ！

各大模式的总体对比：

属性	2PC	TCC	Saga	异步确保型事务	尽最大努力通知
事务一致性	强	弱	弱	弱	弱
复杂性	中	高	中	低	低
业务侵入性	小	大	小	中	中
使用局限性	大	大	中	小	中
性能	低	中	高	高	高
维护成本	低	高	中	低	中

说在最后：有问题找老架构取经

以上关于分布式事务的方案和场景，如果大家能对答如流，如数家珍，基本上 面试官会被你 震惊到、吸引到。

最终，让面试官爱到 “不能自已、口水直流”。offer， 也就来了。

在面试之前，建议大家系统化的刷一波 5000页《尼恩Java面试宝典PDF》，里边有大量的大厂真题、面试难题、架构难题。很多小伙伴刷完后， 吊打面试官， 大厂横着走。

在刷题过程中，如果有啥问题，大家可以来 找 40岁老架构师尼恩交流。

另外，如果没有面试机会，可以找尼恩来改简历、做帮扶。

遇到职业难题，找老架构取经， 可以省去太多的折腾，省去太多的弯路。

尼恩指导了大量的小伙伴上岸，前段时间，刚指导中厂大龄34岁，被裁8月收一大厂offer， 年薪65W，转架构后逆天改命!。

狠狠卷，实现 “offer自由” 很容易的， 前段时间一个武汉的跟着尼恩卷了2年的小伙伴， 在极度严寒/痛苦被裁的环境下， offer拿到手软， 实现真正的 “offer自由” 。

尼恩技术圣经系列PDF

• 《NIO圣经：一次穿透NIO、Selector、Epoll底层原理》
• 《Docker圣经：大白话说Docker底层原理，6W字实现Docker自由》
• 《K8S学习圣经：大白话说K8S底层原理，14W字实现K8S自由》
• 《SpringCloud Alibaba 学习圣经，10万字实现SpringCloud 自由》
• 《大数据HBase学习圣经：一本书实现HBase学习自由》
• 《大数据Flink学习圣经：一本书实现大数据Flink自由》
• 《响应式圣经：10W字，实现Spring响应式编程自由》
• 《Go学习圣经：Go语言实现高并发CRUD业务开发》

……完整版尼恩技术圣经PDF集群，请找尼恩领取

《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》PDF，请到下面公号【技术自由圈】取↓↓↓