下单场景下的分布式
Posted gengshidong
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了下单场景下的分布式相关的知识,希望对你有一定的参考价值。
现在用户对商品下单,我们的系统有三个步骤要做:
1.减商品的库存。
2.如果用户有红包,扣掉用户的可用红包。
3.创建一个订单。
情况1:交易系统中扣库存成功,扣红包成功,但是此时由于某种原因(如超时)导致创建订单失败。
问:如何解决数据一致性(C)问题?
答:1.一次创建失败,为提高系统的可用性,我们应该进行操作的重试(如:3次)。2
2.如果还是失败,那可能就是系统问题了,此时我们可以进行补偿,把扣掉的库存加回去,把扣掉的红包加回去。操作失败的时候一定要持久化我们的操作数据。
3.分布式事物原理是什么?所谓的分布式事物可以看成是一个长事物,本地事物就是短事物,这里就是将一个长事物化作三个短事物。
问:上面回答中的重试应该在哪一环节重试?如何保证幂等性?
答:1.在数据访问层重试行吗?没问题。因为订单号在创建订单之前就已经生成了。所以在数据访问层重试不会造成重复下单的问题。
2.在交易系统的业务逻辑层重试行吗?不行。如果所有流程都没问题,订单已经入库,在交易业务逻辑层调用返回超时。此时,返给上游的结果失败。但实际的业务已经完成。现在如果进行重试,业务逻辑层会重新创建一个订单号,假设重试成功,那么系统中就会有两个订单。造成了重复下单。如何解决呢? 用户进入系统前服务器返给用户一个标识token,后端将该唯一标识和订单号绑定放到本地缓存中,重试的时候如果缓存中有订单号,那么我们取出这个订单号进行重试。重试成功将值删掉。如果还是失败,将失败的信息持久化一下,便于后续的检查以及补偿。
3.网关层重试也会有相同的问题。
问:如果调用扣红包很多次都没成功,怎么办?
答:服务熔断保护系统避免雪崩。单个的服务不可用,不要影响到其它可用服务。
以上是关于下单场景下的分布式的主要内容,如果未能解决你的问题,请参考以下文章