分析简化分布式支付系统的存在的数据丢失问题

    由于公司自己的支付系统比较复杂，我这边删减掉了一大部分功能，主要针对回调通知这块业务来作分布式事物的说明，这块业务也是全部支付业务里面最重要的业务，对数据一致性要求最高的一块业务。下面咱们来看简化后的第三方支付系统的系统架构图。

说明：

  3rd-access能够理解成一个支付网管,全部支付请求和支付结果回调都经过它进行分发。

途中每个小各自表明一个独立的系统，整个架构采用微服务的形式。

整个请求的流程在图中已经画的很明显，在此不作特殊的说明。咱们要作的是来分析，每一步的流程，或者服务的宕机形成的数据丢失问题。

1：发起支付，若是这步由于3rd-access或者网络缘由，不能进行，那么全部用户都不能进行付费，虽然支付系统挂了，可是数据目前来讲仍是一致的，只是都是失败而已。

2：建立支付订单，若是这步由于订单服务宕机或者网络缘由引发用户不能下单，那么同上。

3：选择支付方式，若是这步由于支付插件宕机形成取不到对应的支付方式，可是如今订单库已经有订单了，只是订单的状态目前仍是“支付中”，并无支付成功，在程序上其实默认仍是默认失败的，因此只是整个支付失败而已，并不会形成支付数据的丢失。

4：支付回调，这步咱们不可控暂时先忽略。下面的分析，都默认支付结果都正常回调

5：更新状态，当好比支付宝已经付款成功(钱已经扣了)，支付宝也成功将订单的支付结果回调到咱们的支付网关了(3rd-access)。若是在更新订单的时候，由于订单系统宕机了，那么原本应该更新支付订单的状态为"支付成功"的，如今由于服务挂了，订单表该笔订单仍是“支付处理中”的状态，那么至关于用户的钱白扣了，因此step5会形成支付数据的丢失，致使数据不一致的问题。

6：通知商户支付结果，假设第5步是更新成功的，数据的订单状态为"支付成功"。可是在通知商户的时候，由于商户的服务挂了或者网络有问题，那么该通知就不能成功通知到商户（用户），致使扣取了用户的钱，可是没有下发对应的权益。因此step6也会形成支付数据的丢失,致使数据不一致的问题。

7：通知"积分","营帐","充值"系统，这个跟通知商户类型，只是这个是经过接口异步通知的，另外一个是经过http的方式进行通知的。这部分也会形成明明订单是成功的，订单状态已是“支付成功”，可是对应的积分没加，对应对帐系统也没加，致使后期订单库与其余系统数据对不上，形成脏数据的问题。

数据的一致性，服务的高可用是支付系统的核心，由于分分钟都是钱啊。

下面标红的地方就是可能发生数据丢失的地方，咱们再来看一边。

这些服务都是分布式独立部署的，有的甚至是多节点部署，很显然利用传统的本地事物是处理不了的。

那么如何设计分布式事物的方案，解决数据不一致的问题呢？不要急下面的文章会为你们解答。

/** *   ————————若是以为本博文还行，别忘了推荐一下哦，谢谢！ *   做者：写程序的奥特曼 *   欢迎转载，请保留此段声明。 *   出处：https://my.oschina.net/u/2286631/blog/1504582 */