业务异常数据修复

业务异常数据修复的策略

1.背景

在业务系统实际投入使用的过程中，常常会因为逻辑bug或者第三方接口异常导致一些处理流程中断。这类情况往往会导致完整流程上下游数据状态不一致。如果对应的流程节点没有重试机制或者自动回滚保护，那么就需要人工介入进行数据修复。

2.策略方向

2.1策略一：回滚式

将长流程中，中断节点之前的步骤影响，全部回滚恢复，使对应数据恢复到从未发生过这次长流程处理的状态。

2.2策略二：补偿式

在长流程中，从中断节点之后的所有步骤，全部补偿执行完，使对应数据流转到正常执行完这次长流程处理的状态。

2.3策略选择说明

在以上两种策略中作选择的时候，要依据影响最小的原则选择。就是指相对更方便操作，对外部影响也要可控的方向去处理。比如：

• 如果相关流程只涉及自己系统的数据，那么就看哪一种方式工作量最小，就选对应的策略；
• 如果中断前的流程，涉及消息生产，http调用外部api。而中断后的流程，只涉及自己系统的数据变动。那么我们优先选择补偿式策略。因为推出去的消息，需要花费比较大的气力去摸排对消费端的数据影响。并不是说不能做，而是相对比较麻烦。

3.方式

方式一：手动完全处理（推荐）

脱离系统自动流程，通过提工单等方式，将目标流程的所有步骤依次将步骤执行。遇到数据库写操作，就提请sql工单；遇到http调用步骤，就提请curl工单。
适用于目标数据明确或者计算简单的场景，比如一些status字段值的修改。

方式二：手动不完全处理（不推荐）

脱离系统自动流程，通过提工单等方式，将目标流程的关键步骤执行。遇到数据库写操作，就提请sql工单；遇到http调用步骤，就提请curl工单；遇到消息生产，就需要重推消息（消息消费端可能是外部服务，这个数据和逻辑处理影响比较难以评估，一般还是建议走重推消息）
适用于对业务系统很熟悉的人员选择使用。在充分评估数据影响（包括外部服务）的情况下，保证可以只处理部分步骤，即可实现补偿/回滚效果的情况下，可以只执行部分关键步骤即可。比如：

• 有父层级节点A，其下有子节点a1，a2，a3。需要废弃这些节点，如果可以保证将A的status变更为“canceled”之后，子节点在任何业务流程中，都会因为A的状态影响导致不可用。那么我们只需要更新A的status即可。

方式三：主流程加临时代码处理

如果接口是幂等可重入的，评估一下异常中断的节点，如果可以，也许零改动，直接重新调用一下中断的接口即可。
但是有时候接口不具有幂等性，那么我们可能需要在主流程手动添加一些临时代码，通过id之类的信息识别一下目标数据对应的请求。对于该请求，

• 异常中断前的操作步骤，即已经执行过的步骤，不要再重复执行，直接绕开；
• 有一些具有状态的过程变量，对应的写操作已经成功执行过了，临时代码需要绕开。可以通过查询上次执行存入的记录来填值，支撑后续流程正常执行；
• 未执行的步骤，继续执行。

完成上述代码逻辑之后，上线新版本代码，然后再手动触发一下异常中断的接口。这个方式往往匹配补偿式策略使用。

方式四：编写单独的修复数据接口

这个方式可以理解为方式一、方式二的编码版本。面对数据量比较大、影响数据表比较多的情况，如果都以一个个提工单的方式去处理，可能人都得麻了。我们可以将大量的数据查询、关联、更新等需要人工处理的操作交付给代码去完成，而我们只需要传入一串id值即可。当然这个接口中，也可以根据情况，直接从主流程的业务代码里copy一些关键步骤的代码，减少新代码开发量。

方式五：线下处理（不推荐）

有一些极端情况，不论是补偿式，还是回滚式，修复数据的工作量都是极其可怕的。评估异常数据影响程度，考虑修复投入人力性价比，如果有一些绕开系统，线下记录和处理异常数据的手段，那么我们也可以选择容许这批异常数据存在于系统中。在独立的一个“小本本”里，把这些数据的详细情况记录清楚，走特殊处理流程处理即可。比如：

• 财务手动调账

4.说明

以上只是陈列一些基本的修复数据的思路和方法。在实践中，还需根据具体的业务场景，自己的系统特征，来选择合适自己的方式和策略，进行异常数据修复。