分布式事务主要解决分布式一致性的问题（数据的分布式操作导致仅依靠本地事务无法保证原子性）。

分布式事务场景

下单扣库存

在电商系统中，下单是用户最常见操作。在下单接口中必定会涉及生成订单 id, 扣减库存等操作，对于微服务架构系统，订单 id 与库存服务一般都是独立的服务，此时就需要分布式事务来保证整个下单接口的成功。

支付

转账是最经典那的分布式事务场景，假设用户 A 使用银行 app 发起一笔跨行转账给用户 B，银行系统首先扣掉用户 A 的钱，然后增加用户 B 账户中的余额。此时就会出现 2 种异常情况：1. 用户 A 的账户扣款成功，用户 B 账户余额增加失败 2. 用户 A 账户扣款失败，用户 B 账户余额增加成功。对于银行系统来说，以上 2 种情况都是不允许发生，此时就需要分布式事务来保证转账操作的成功。

1. 背景

我们在日常的工作中，有时候会碰到一些高并发的场景，比如，电商业务场景下的秒杀活动，春节活动中的抢红包，银行转账，出行抢票等，这些场景有一个共同特点就是在短时间内存在极高的峰值 qps。虽然在系统设计中，我们会通过异步限流、削峰填谷等方式进行优化，但整体的系统流量还是会在平时的数倍以上。因此，为了避免高并发带来的问题（如库存超卖，代金券超发等），这些系统通常都会用到锁的机制。

对于单进程的并发场景，可以使用编程语言及相应的类库提供的锁，如 Java 中的 synchronized 语法以及 ReentrantLock 类，Golang 中的 sync 包等，避免并发问题。在实际的业务场景中，一般均为多实例部署，因此不在此处做过多的篇幅介绍。