领域拆分：如何合理地拆分系统？
一般来说，强一致性的系统都会牵扯到“锁争抢”等技术点，有较大的性能瓶颈，而电商时常做秒杀活动，这对系统的要求更高。业内在对电商系统做改造时，通常会从三个方面入手：系统拆分、库存争抢优化、系统隔离优化。

业务拆分的方法有很多，最简单便捷的方式是：先从上到下做业务流程梳理，将流程归类聚合；然后从不同的领域聚合中找出交互所需主要实体，根据流程中主要实体之间的数据依赖程度决定是否拆分（从下到上看）；把不同的实体和动作拆分成多个模块后，再根据业务流程归类，划分出最终的模块（最终汇总）。这个拆分过程用一句话总结就是：从上往下看流程，从下往上看模块，最后综合考虑流程和模块的产出结果。用这种方式能快速拆出模块范围，拆分出的业务也会十分清晰。

强一致锁：如何解决高并发下的库存争抢问题

由于秒杀场景是库存争抢非常经典的一个应用场景，接下来我会结合秒杀需求，带你看看如何实现高并发下的库存争抢，相信在这一过程中你会对锁有更深入的认识。
锁争抢的错误做法

public class ThreadCounter {
    private static int count = 0;
 
    public static void main(String[] args) throws Exception {
        Runnable task = new Runnable() {
            public void run() {
                for (int i = 0; i < 1000; ++i) {
                    count += 1;
                }
            }
        };
 
        Thread t1 = new Thread(task);
        t1.start();
        
        Thread t2 = new Thread(task);
        t2.start();
 
        t1.join();
        t2.join();
 
        cout << "count = " << count << endl;
    }
}

这段代码,count预期是2000，但是一般都会小于2000。对于这个情况，我们一般都会用到锁或原子操作来保护库存变量：
如果是简单 int 类型数据，可以使用原子操作保证数据准确；
如果是复杂的数据结构或多步操作，可以加锁来保证数据完整性。
不过锁操作是很影响性能的，在讲锁方式之前，我先给你介绍几个相对轻量的方式。

前面我们提到当有大量用户去并行修改一个变量时，只有用锁才能保证修改的正确性，但锁争抢性能很差，那怎么降低锁的粒度、减少锁的争枪呢？

举个例子，当前商品库存有 100 个，我们可以把它放在 10 个 key 中用不同的 Redis 实例保存，每个 key 里面保存 10 个商品库存，当用户下单的时候可以随机找一个 key 进行扣库存操作。如果没库存，就记录好当前 key 再随机找剩下的 9 个 key，直到成功扣除 1 个库存。
除了这种方法以外，我个人更推荐的做法是使用 Redis 的原子操作，因为原子操作的粒度更小，并且是高性能单线程实现，可以做到全局唯一决策。而且很多原子操作的底层实现都是通过硬件实现的，性能很好

redis> decr prod_1475_stock_1
incr、decr 这类操作就是原子的，我们可以根据返回值是否大于 0 来判断是否扣库存成功。但是这里你要注意，如果当前值已经为负数，我们需要考虑一下是否将之前扣除的补偿回来。并且为了减少修改操作，我们可以在扣减之前做一次值检测，整体操作如下：

//读取当前库存，确认是否大于零
//如大于零则继续操作，小于等于拒绝后续
redis> get prod_1475_stock_1
1
 
//开始扣减库存、如返回值大于或等于0那么代表扣减成功，小于0代表当前已经没有库存
//可以看到返回-2，这可以理解成同时两个线程都在操作扣库存，并且都没拿到库存
redis> decr prod_1475_stock_1
-2
 
//扣减失败、补偿多扣的库存
//这里返回0是因为同时两个线程都在做补偿，最终恢复0库存
redis> incr prod_1475_stock
0

这看起来是个不错的保护库存量方案，不过它也有缺点，相信你已经猜到了，这个库存的数值准确性取决于我们的业务是否能够返还恢复之前扣除的值。如果在服务运行过程中，“返还”这个操作被打断，人工修复会很难，因为你不知道当前有多少库存还在路上狂奔，只能等活动结束后所有过程都落地，再来看剩余库存量。
而要想完全保证库存不会丢失，我们习惯性通过事务和回滚来保障。但是外置的库存服务 Redis 不属于数据库的缓存范围，这一切需要通过人工代码去保障，这就要求我们在处理业务的每一处故障时都能处理好库存问题。所以，很多常见秒杀系统的库存在出现故障时是不返还的，并不是不想返还，而是很多意外场景做不到。

令牌库存
具体是使用 Redis 中的 list 保存多张令牌来代表库存，一张令牌就是一个库存，用户抢库存时拿到令牌的用户可以继续支付：

//放入三个库存
redis> lpush prod_1475_stock_queue_1 stock_1
redis> lpush prod_1475_stock_queue_1 stock_2
redis> lpush prod_1475_stock_queue_1 stock_3

//取出一个，超过0.5秒没有返回，那么抢库存失败
redis> brpop prod_1475_stock_queue_1 0.5
在没有库存后，用户只会拿到 nil。当然这个实现方式只是解决抢库存失败后不用再补偿库存的问题，在我们对业务代码异常处理不完善时仍会出现丢库存情况。同时，我们要注意 brpop 可以从 list 队列“右侧”中拿出一个令牌，如果不需要阻塞等待的话，使用 rpop 压测性能会更好一些。
不过，当我们的库存成千上万的时候，可能不太适合使用令牌方式去做，因为我们需要往 list 中推送 1 万个令牌才能正常工作来表示库存。如果有 10 万个库存就需要连续插入 10 万个字符串到 list 当中，入库期间会让 Redis 出现大量卡顿。

多库存秒杀
如果产品侧提出“一个商品可以抢多个库存”这样的要求，也就是一次秒杀多个同种商品（比如一次秒杀两袋大米

这时候你应该发现了，在“一个商品可以抢多个库存”这个场景下，拆分并没有减少锁争抢次数，同时还加大了维护难度。当库存越来越少的时候，抢购越往后性能表现越差，这个设计已经不符合我们设计的初衷

系统隔离：如何应对高并发流量冲击？
我曾经在一家教育培训公司做架构师，在一次续报活动中，我们的系统出现了大规模崩溃。在活动开始有五万左右的学员同时操作，大量请求瞬间冲击我们的服务器，导致服务端有大量请求堆积，最终系统资源耗尽停止响应。我们不得不重启服务，并对接口做了限流，服务才恢复正常。究其原因，我们习惯性地将公用的功能和数据做成了内网服务，这种方式虽然可以提高服务的复用性，但也让我们的服务非常依赖内网服务。当外网受到流量冲击时，内网也会受到放大流量的冲击，过高的流量很容易导致内网服务崩溃，进而最终导致整个网站无法响应。事故后我们经过详细复盘，最终一致认为这次系统大规模崩溃，核心还是在于系统隔离性做得不好，业务极易相互影响。

如果系统隔离性做得好，在受到大流量冲击时，只会影响被冲击的应用服务，即使某个业务因此崩溃，也不会影响到其他业务的正常运转**。这就要求我们的架构要有能力隔离多个应用，并且能够隔离内外网流量，只有如此才能够保证系统的稳定。**
为了提高系统的稳定性，我们决定对系统做隔离改造，具体如下图：

也就是说，每个内、外网服务都会部署在独立的集群内，同时每个项目都拥有自己的网关和数据库。而外网服务和内网必须通过网关才能访问，外网向内网同步数据是用 Kafka 来实现的。
网关隔离和随时熔断
网关隔离和随时熔断在这个改造方案中有两种网关：外网网关和内网网关。每个业务都拥有独立的外网网关（可根据需要调整）来对外网流量做限流。当瞬时流量超过系统承受能力时，网关会让超编的请求排队阻塞一会儿，等服务器 QPS 高峰过后才会放行，这个方式比起直接拒绝客户端请求来说，可以给用户更好的体验。外网调用内网的接口必须通过内网网关。外网请求内网接口时，内网网关会对请求的来源系统和目标接口进行鉴权，注册授权过的外网服务只能访问对其授权过的内网接口，这样可以严格管理系统之间的接口调用.
同时，我们在开发期间要时刻注意，内网网关在流量增大的时候要做熔断，这样可以避免外网服务强依赖内网接口，保证外网服务的独立性，确保内网不受外网流量冲击。并且外网服务要保证内网网关断开后，仍旧能正常独立运转一小时以上。但是你应该也发现了，这样的隔离不能实时调用内网接口，会给研发造成很大的困扰。要知道常见外网业务需要频繁调用内网服务获取基础数据才能正常工作，而且内网、外网同时对同一份数据做决策的话，很容易出现混乱。

减少内网 API 互动
为了防止共享的数据被多个系统同时修改，我们会在活动期间把参与活动的数据和库存做推送，然后自动锁定，这样做可以防止其他业务和后台对数据做修改。若要禁售，则可以通过后台直接调用前台业务接口来操作；活动期间也可以添加新的商品到外网业务中，但只能增不能减。

这样的实现方式既可以保证一段时间内数据决策的唯一性，也可以保证内外网的隔离性.
只有保证数据同步是单向的，才能取消相互锁定操作。我们可以规定所有库存决策由外网业务服务决定，后台对库存操作时必须经过外网业务决策后才能继续操作，这样的方式比锁定数据更加灵活。而外网交易后要向内网同步交易结果，只能通过队列方式推

后台系统推送数据到 Redis 或数据库中，外网服务通过 Kafka 把结果同步到内网，扣减库存需通知外网服务扣减成功后方可同步操作。

外网与内网的区别：
外网是一般是针对用户端，直接对接用户使用，需要做公网解析；
内网一般是公司技术服务节点，不需要公网解析且不对外服务，都是外网服务上做单独解析才能访问内网服务，访问内网会比公网获取数据速度更快，减少了一层解析。

一般大点的公司都会做外网和内网隔离，以保障服务安全和稳定。

分布式事务：多服务的2PC、TCC都是怎么实现的？
目前业界流行微服务，DDD 领域驱动设计也随之流行起来。DDD 是一种拆分微服务的方法，它从业务流程的视角从上往下拆分领域，通过聚合根关联多个领域，将多个流程聚合在一起，形成独立的服务。相比由数据表结构设计出的微服务，DDD 这种方式更加合理，但也加大了分布式事务的实现难度。
在传统的分布式事务实现方式中，我们普遍会将一个完整的事务放在一个独立的项目中统一维护，并在一个数据库中统一处理所有的操作。这样在出现问题时，直接一起回滚，即可保证数据的互斥和统一性。**不过，这种方式的服务复用性和隔离性较差，很多核心业务为了事务的一致性只能聚合在一起。**为了保证一致性，事务在执行期间会互斥锁定大量的数据，导致服务整体性能存在瓶颈。
好在目前业内有很多实现分布式事务的方式，比如 2PC、3PC、TCC 等，但究竟用哪种比较合适呢？这是我们需要重点关注的。
XA 协议
XA 协议是一个很流行的分布式事务协议，可以很好地支撑我们实现分布式事务，比如常见的 2PC、3PC 等。而理解了 XA 协议，对我们深入了解分布式事务的本质很有帮助。
支持 XA 协议的数据库可以在客户端断开的情况下，将执行好的业务结果暂存起来，直到另外一个进程确认才会最终提交或回滚事务，这样就能轻松实现多个数据库的事务一致性。

在 XA 协议里有三个主要的角色：
应用（AP）：应用是具体的业务逻辑代码实现，业务逻辑通过请求事务协调器开启全局事务，在事务协调器注册多个子事务后，业务代码会依次给所有参与事务的子业务下发请求。待所有子业务提交成功后，业务代码根据返回情况告诉事务协调器各个子事务的执行情况，由事务协调器决策子事务是提交还是回滚（有些实现是事务协调器发请求给子服务）。
事务协调器（TM）：用于创建主事务，同时协调各个子事务。事务协调器会根据各个子事务的执行情况，决策这些子事务最终是提交执行结果，还是回滚执行结果。此外，事务协调器很多时候还会自动帮我们提交事务；
资源管理器（RM）：是一种支持事务或 XA 协议的数据资源，比如 MySQL、Redis 等。
另外，XA 还对分布式事务规定了两个阶段：Prepare 阶段和 Commit 阶段。
在 Prepare 阶段，事务协调器会通过 xid（事务唯一标识，由业务或事务协调器生成）协调多个资源管理器执行子事务，所有子事务执行成功后会向事务协调器汇报。这时的子事务执行成功是指事务内 SQL 执行成功，并没有执行事务的最终 commit（提交），所有子事务是提交还是回滚，需要等事务协调器做最终决策。接着分布式事务进入 Commit 阶段：当事务协调器收到所有资源管理器成功执行子事务的消息后，会记录事务执行成功，并对子事务做真正提交。如果 Prepare 阶段有子事务失败，或者事务协调器在一段时间内没有收到所有子事务执行成功的消息，就会通知所有资源管理器对子事务执行回滚的操作。

我们以购物场景为例，在购物的整个事务流程中，需要协调的服务有三个：用户钱包、商品库存和用户购物订单，它们的数据都放在私有的数据库中。

按照业务流程，用户在购买商品时，系统需要执行扣库存、生成购物订单和扣除用户账户余额的操作 。其中，“扣库存”和“扣除用户账户余额”是为了保证数据的准确和一致性，所以扣减过程中，要在事务操作期间锁定互斥的其他线程操作保证一致性，然后通过 2PC 方式，对三个服务实现事务协调。
2PC 事务不仅容易理解，实现起来也简单。不过它最大的缺点是在 Prepare 阶段，很多操作的数据需要先做行锁定，才能保证数据的一致性。并且应用和每个子事务的过程需要阻塞，等整个事务全部完成才能释放资源，这就导致资源锁定时间比较长，并发也不高，常有大量事务排队。除此之外，在一些特殊情况下，2PC 会丢数据，比如在 Commit 阶段，如果事务协调器的提交操作被打断了，XA 事务就会遗留在 MySQL 中。而且你应该已经发现了，2PC 的整体设计是没有超时机制的，如果长时间不提交遗留在 MySQL 中的 XA 子事务，就会导致数据库长期被锁表。

3PC 简述。与 2PC 相比，3PC 主要多了事务超时、多次重复尝试，以及提交 check 的功能。但因为确认步骤过多，很多业务的互斥排队时间会很长，所以 3PC 的事务失败率要比 2PC 高很多。为了减少 3PC 因资源锁定等待超时导致的重复工作，3PC 做了预操作，整体流程分成三个阶段：CanCommit 阶段：为了减少因等待锁定数据导致的超时情况，提高事务成功率，事务协调器会发送消息确认资源管理器的资源锁定情况，以及所有子事务的数据库锁定数据的情况。PreCommit 阶段：执行 2PC 的 Prepare 阶段；DoCommit 阶段：执行 2PC 的 Commit 阶段。总体来说，3PC 步骤过多，过程比较复杂，整体执行也更加缓慢，所以在分布式生产环境中很少用到它，这里我就不再过多展开了。

TCC 是 Try-Confirm-Cancel 的缩写，从流程上来看，它比 2PC 多了一个阶段，也就是将 Prepare 阶段又拆分成了两个阶段：Try 阶段和 Confirm 阶段。TCC 可以不使用 XA，只使用普通事务就能实现分布式事务。
首先在 Try 阶段，**业务代码会预留业务所需的全部资源，**比如冻结用户账户 100 元、提前扣除一个商品库存、提前创建一个没有开始交易的订单等，这样可以减少各个子事务锁定的数据量。业务拿到这些资源后，后续两个阶段操作就可以无锁进行了。
在 Confirm 阶段，业务确认所需的资源都拿到后，子事务会并行执行这些业务。执行时可以不做任何锁互斥，也无需检查，直接执行 Try 阶段准备的所有资源就行。请注意，协议要求所有操作都是幂等的，以支持失败重试，因为在一些特殊情况下，比如资源锁争抢超时、网络不稳定等，操作要尝试执行多次才会成功。
最后在 Cancel 阶段：如果子事务在 Try 阶段或 Confirm 阶段多次执行重试后仍旧失败，TM 就会执行 Cancel 阶段的代码，并释放 Try 预留的资源，同时回滚 Confirm 期间的内容。注意，Cancel 阶段的代码也要做幂等，以支持多次执行

最后，我们总结一下 TCC 事务的优点：并发能力高，且无长期资源锁定；当然，它的缺点也很明显：只适合短事务，不适合多阶段的事务；相关事务逻辑要求幂等；存在执行过程被打断时，容易丢失数据的情况。

目前，市面上有很多优秀的中间件，比如 DTM、Seata，它们对分布式事务协调做了很多的优化，比如过程中如果出现打断情况，它们能够自动重试