一、背景：

1、为提升余额更新的整体性能和吞吐量，余额更新实现了异步化处理方式；

2、为了提升数据准确性（在事务一致性、服务异常宕机、数据库和中间件异常等情况下）；

二、简单理解：

1、长耗时的情况下

假设一个单据审核需要做余额更新需要10s，发现其中7s就用在了余额更新数据库的过程。

同步更新情况下：点击审核需要等待10s才能结束。（真结束）

异步化更新：点击审核等待3s即结束了。后面7s会异步处理。用户不用长时间等待。

2、短耗时的场景下

同步和异步化都是瞬间结束。

三、现象

为了确保数据在逻辑上决定的更新可靠，要控制一个单据不能在同一时刻发起多次余额更新，则要确保每一次更新必须等待上一次更新业务完全处理完毕，才能进行。因此在长耗时情况下，审核成功后，无法马上进行反审核。短耗时场景下，等待极短，反审核好像是马上可以执行。

四、可能出现的提示

单据：xxx还有余额更新业务暂未处理完毕，请等几分钟…. 详情可查看【xxxx】列表

五、处理方式：

1、正常现象

按系统提示来，等待几分钟后在试，不要急。

原因：系统真的还没处理过来，若同步情况下，可能上一个触发余额的操作（如审核）可能都还没结束。

如果10来分钟后，还是这样要考虑这个单有异常（如：异步部分非程序问题导致更新不了）。

2、异常：消息未消费

1)  路径：【开发服务云】→【余额模型】→【余额日志】→【部分更新中的事务】

2)  检查：列表是否有数据，有数据且存在发布时间为空的数据，则是消息未消费导致。

3)  方案：在【开发服务云】→【余额模型】→【余额日志】→【余额更新发生记录】中点击“通知消费”按钮后，再查询【部分更新中的事务】，没有数据了则正常

3、异常：后台容器资源未跟上

经过以上处理后，若还是一样，则可能是后台容易资源未跟上导致

1）路径：【开发服务云】→【余额模型】→【余额日志】→【异步处理错误日志列表】

2）检查：是否有异常导致数据确实消费不了

3）方案：5.0.006-5.0.008的补丁有已知BUG，可以更新5.0.009补丁解决；可以按需要联系研发人员分析

3、异常：异常导致更新中断

如果【开发服务云】→【余额模型】→【余额日志】→【部分更新中的事务】没有数据，则可能是容器、服务、中间件等系统级别的异常导致更新中断，没有立马回滚更新。

1）路径：【开发服务云】→【余额模型】→【余额日志】→【部分异步更新中的单据】

2）检查：查看列表是否有数据

3)  方案：① 等待自动处理：系统会每15分钟发起一次检查，清理60分钟之前错误数据。

    ②手工确认清理：点击“清理失效事务”按钮，能清理10分钟前的失效事务（前提要确保这个单的审核操作确实是结束了）

4、异常：MQ消息在qing节点消费

1) 路径：【monitor】→【注册中心】→【MQ消费者监控】

2) 检查：MQ消息是否在qing节点消费导致。

    ① 选择微服务，点击【MQ消费者监控】

     ② 查询bal_queue 开头的队列

        没有队列则是正常的，有队列则说明配置或包出现问题了。

3) 方案

若有队列，则说明配置或包出现了问题。依次排查下面几项：

① 平台包版本要求： 5.000-5.0007，存在路由问题，需升级到5.0008以上版本；（要运维确认，很多环境才有私包，系统查询的大概率不对）。

② 包无问题则检查配置：选中qing节点，点击系统属性，查询是否符合下面配置，若不符合，请协调运维检查调整配置。全部节点重启后，在进行新单据测试。

    场景1：

        appSplit=false        代表不分应用部署

        appIds=qing,qing_rpt          请节点路由

        bos.app.special.deployalone.ids = qing        qing节点独立部署

    场景2：

        appSplit=true        代表分应用部署

以上排查后，还有问题，则要联系研发，进一步排查问题。