第一，为什么要先减库存，不是付款成功才减？ 第二，你不是先减掉了吗，怎么会加回时多出一个？这个逻辑我看不懂。 说来说去，为什么库存不够就不能下单？你们采购都死光了么？就算一时半会补不了货，不还能工厂直发吗？我要是老板，非把你们这些一根筋的程序员打个半死不可。
经典的异步乱序难题。你这个还好解决一些。 我这里假定「苹果+1 」、「苹果-1 」是两个事件，如果你用得不是事件驱动而是常规 REST 接口，那么可以把事件看作接口的入参对象，把事件消费过程看作接口的方法体。 首先，开了异步，并且还有严重级别的一致性问题，那么相关操作都要当作业务数据去存储。对于你的案例，就是「苹果+1 」、「苹果-1 」这些事件的消费记录，要当作业务数据存到数据库中。 「苹果-1 」事件无依赖，它的消费过程不用动。 「苹果+1 」事件必须晚于「苹果-1 」事件被消费，故它在消费时，要先去查找一下对应的「苹果-1 」事件是否有消费记录。如果没有，则停止当前消费过程，并追加延迟消费逻辑。延迟消费逻辑，可以简单的记消费失败并让发布事件那一方短暂延迟后重新发布事件（对于 REST 接口来说，就是接口抛异常，调用方捕获到异常之后，sleep ，然后重新调接口），也可以记消费成功但同时发布新的「苹果+1 延迟」事件（这个如果是 REST 接口，就有点难弄了，你需要额外加延迟调度框架，绝对不能在 REST 接口中 sleep ）。 如果条件允许的话，还是用 Kafka 做事件驱动的基础设施，它能保证顺序消费。
@lsk569937453 #4 @realpg #17 #22 @tabris17 #18 不管是分布式事务，还是等消息处理成功才正式生成订单，这是 CP without A 的分布式原则选择，强一致但是低可用。下订单的场景明显不能采用这种原则。
