理解跨系统之间金额的业务调用的资金平衡结算程序和过程

    接上篇在javaeye发表的：如何在web系统中实现跨系统调用与事务补偿，我下来将这个业务仔细理了一下，并结合taolei0628所说的业务分析，完成此篇文章，以，理解这种跨系统的业务，并提出一个可参考实现。

    本文已发表于个人博客：http://www.flydmeng.com/index.php/code/understand-over-system-money-change-business-money-balance-programe-and-procedure.html

 

    对于跨系统调用，它和同一个系统调用多个数据库不同，在两个系统调用之间，会出现各种各样的问题，导致会发生数据不一致的问题存在。本文从系统之间调用出发，并结合类金融系统的资金实现样例，来解析这种业务的实现过程。

    我们现在有两个系统，A系统为金额系统，负责金额数据的存放和结算，当进行充值和消费时，将对金额的数据发生变化；B系统为业务系统，负责处理消费业务的 实现，但当进行实现时，需要发送消费数据信息到A系统进行金额数据的存储，待存储完成之后方能进行下一步的业务流程。

    可以由下面的一个流程来理解两个系统之间的交互：

1. B系统发起消费业务，负责业务实现前的验证
2. 验证成功，B系统向A系统申请付款信息
3. A系统验证确定可以付款，产生付款信息，并进行金额结算
4. A系统返回应答信息，B系统继续进行业务操作，完成消费业务实现

    在以上的四个操作中，任何一步都可能发生错误，而且在系统与系统之间的交互过程中，还存在着网络方面的问题。当网络中断时，整个交互过程也不能完成。

    首先可以肯定的是，这并不是一个事务内的事情，A系统和B系统是两个独立的系统，在网络上独立，且系统与系统间数据库是不会互相开放的，所以想在一个事务内考虑问题，是不能成功的。只从从系统外，即如何保证两个系统之间的数据平衡。

    对于这种情况，只能通过流水号对账，双金额的收支平衡来解决此问题。即在A系统中设定一个预付金额和确认金额，B系统设定业务流水号，AB系统定时通过流水号进行帐务结算。对错误的业务信息，进行冲帐，正确的业务信息进行确认。

    简单介绍下实现，在B系统中有一个业务流水号，记录着每一笔交易信息；A系统中有两个金额，一个是预付金额，一个是确认金额，预付金额用于在B系统进行业 务处理前，记录业务交易的金额数据，确认金额用于在B系统业务处理后，记录业务交易的确认数据。一般情况下，预付金额与确认金额一致。此外，A系统同时记 录B系统的业务流水号，以便于定时进行业务对帐。
    业务对帐，表现确认两边的数据是否一致，同时对未写入的确认金额进行确认或取消。当业务一致时，确认金额表现为交易金额数据，当业务不一致时，预付金额表现为需要冲正的金额数据，将在进行对帐时进行处理。
    详细数据结构如下：

A系统：

• bId （B系统业务流水号)
• preMoney(预处理金额）
• confirmMoney(确认金额)

B系统：

• bId(B系统业务流水号)
• aId(金额处理流水号，可选)

现在我们来进行详细的分析，首先分析整个交互过程中可能产生的错误:

1. B系统发起业务处理前程序出错
2. B向A发起预交易处理时网络出错
3. A系统处理预交易业务出错
4. A系统向B系统返回数据时网络出错
5. B系统接收到数据，处理业务逻辑程序出错
6. B系统处理完数据，向A系统发送确认命令网络出错

    以上交互，比原来的流程稍微进行了修正，B系统需要先发送预处理命令到A系统，在进行完业务之后，还会发送确认命令到A系统进行业务确认。

    首先，讨论业务不能完成的情况，其中第1到第5步，都导致业务不能继续进行，因为这中间发生了程序或网络上的错误，导致整个业务逻辑未能完成，此时B系统业务被回退。第6步，为业务commit之后，A系统没有收到确认，导致确认金额没有更新。

    在第1到第5步操作中，1,2,3步出错，对业务没有任何影响，此时A系统没有数据发生，而B系统也不会有数据发生修改。
    在第4步到第5步，A系统均记录了预付金额，而B系统确没有业务发生，即表示此时记录的数据为错误的预付数据，需要在一定时刻将金额返回到帐户上。
    在第6步，A系统记录了预付金额，B系统发生了业务，但并没有记录确认金额，即表示此记录数据为沿未确认金额，需要在一定时刻将确认金额进行记录。

    这两种操作，都需要一个定时的结算业务来进行，这个结算操作由系统定时发生，或由人工进行干预。结算业务在进行处理时，将指定时间内的B系统所有流水号一起打包，统一传递给A系统进行处理。两边数据进行对比，对比过程中将处理由上面产生的两种未处理完业务。
    当B系统和A系统均存在相同的业务流水号时，表示此笔业务为正常业务。此时，将判断A系统的确认金额是否已记录，如果未记录，将记录确认金额。此操作，将解决第4步和第5步产生的问题。
    当A系统存在业务流水号，而B系统没有此流水号时，表示此笔业务为错误业务。此时，将A系统中相对应的记录进行冲正处理，记录相应标识，同时将相应记录的预付金额返回到帐户上。此操作，将解析由第6步产生的问题。
    结算业务并不操作只执行一次，可以进行多次。进行多次不影响最终的数据变化，因此可以将结算业务设计成一个可重复的操作，当一次操作未能正常完成时，可发起同一天操作的第二轮结算业务。

    需要注意的是，在整个操作中，都是由B系统的业务流水号来进行两边数据的对比。且业务流水号，要在业务未进行逻辑运算时，就要产生。所以，业务流水号，不 能由表数据的自动字段来记录，需要预先生成一个流水号。可以考虑由类似oracle序列的手段来进行，在业务逻辑进行前，申请一个流水号，不管此业务完成 与否，此流水号均已被使用，下一个业务时，就需要重新申请了。oracle序列保证每一次请求时，均返回不同的流水号，这就满足了业务系统的要求。