微服务的一致性

在单体应用中借助数据库的事物我们可以很方便的实现数据的一致性。
但是当单体应用被拆分成不同的服务时候，所有服务是分开部署到不用的机器上，所以无法通过单纯的事物保证数据的一致性。
而且因为跨服务的调用（rpc 或者 restful）可能以为网络的原因导致服务调用失败。
服务调用失败可以分为

1.服务提供方挂了，无法提供服务
2.服务提供方 执行程序时候异常
3.服务提供方成功执行了服务，因为网络原因导致调用方没有收到success

借助于电商系统 生成订单 锁定库存的场景来分析
系统分为 订单服务 和 库存服务。
当用户下单时候
调用订单服务生成订单，订单服务再调用库存服务锁定库存。

正常流程

1 订单生成成功，库存被锁定。
2 订单生成失败，影响不大，用户重新调用生成订单
3 订单生成成功，锁定库存失败，订单回滚，也ok

不一致情况

下单成功，库存服务锁定库存成功，但是因为网络原因，没有返回给订单服务success ，导致订单回滚。
即订单生成失败，库存却被锁定了。对于商家来说就是明明有商品却无法卖出去。

image.png

这种情况，的解决办法：
1 分布式事物，但是比较复杂，影响系统性能。
2 通过补偿操作来达到最终一致性。

这里给大家介绍下补偿操作来实现最终一致性

image.png

商家通过后台查看出库记录，发现有的锁定库存操作关联了无效的订单，就知道是异常订单了。
然后通过撤销动作，来释放库存，来保证库存的正确性。

我这里为了简单，通过了人去触发错误的补偿。

也可以通过程序自动的实现补偿操作。
1.订单报异常时候 将订单id 保存到消息队列中
2 读取异常订单消息 ，释放关联了无效订单的库存

支付情况

因为微信有重试机制，所以支付成功后直接调用账户服务。

image.png

感谢你的阅读。
喜欢的话请点赞。