多系统数据对账逻辑探讨

1. 背景

数据传输过程是不可靠的，为了保证数据可信，可靠需要增加对账，

例如

1. 数据同步，无法避免同步过程中不丢失

1. 双写（如银行之间对账文件），无法避免双方数据一致

此时需要对账来确保，数据一致

2. 对账参与方

至多两方，至少也是两方，如果不满足，无法对账，这里我们分析一下不是亮哥参与方的情况：

1. 如果只有1方，谈不上对账，自己为准即可
2. 如果有三方（A，B，C）,对账和对账结果差异处理难度会很高，如果确实需要三方甚至多方对账，我们可以转变思路，将三方拆成两个两方进行对账，如AB对，AB对齐之后，AC对，4方拆成3个两方对账，即n个系统参与对账拆成n-1对系统对账

3. 对账前提条件

双方必须能够对数据唯一标识达成一致，即每行数据都有唯一标识，而且两方系统的唯一表示也必须一致，这样才能对账，否则完全不是一个维度的数据，无法对账。如订单号，交易流水号等可以作为对账数据唯一标识。

4. 对账结果

对账一般是两方对，无非谁多谁少，A、B两方，差异的处理方式也是谁少补齐谁，谁多删谁，相同条数部分字段值不一致，修复部分字段值即可，以下是场景结果列举：

1. A多，B少
2. B多，A少
3. A，B数量一致，字段值不一致

5. 差异处理

对账出现差异处理，分为自动处理，人工介入处理两种方式，不同场景适应不同方式。

1. 存在基准方（比如以A系统数据为准），即以某方系统为准的对账，可以以此方系统来修复另一方的数据；根据对账范围又可以细分两类
   1. 对账范围（全部数据）
      1. A多B少场景，B补齐少的数据
      2. A少B多场景，B删去多的数据
      3. B部分数据和A不一致，B以A系统值为准修复自身值
   2. 对账范围（昨日数据）
      1. A多B少场景，正常来说B需要插入少的部分，但是由于限制了对账范围，那么存在可能B有这部分数据，只不过不在限制范围内，所以还需要细分两种情况
         1. B确实少这部分数据，插入少的部分数据即可
         2. B有少的这部分数据，但是不在限制范围内，如对账范围为（date = '2024-11-09'）,但是B系统少的这部分数据在date = '2024-10-25'日期下，所以B系统不需要插入少的这部分数据，而是需要将B系统少的这部分数据从date = '2024-10-25'修改为date = '2024-11-09'就行了
      2. A少B多场景，正常来说B需要删除多的部分，但是由于限制了范围，那么存在可能B多的这部分数据属于其他的日期，所以还需要细分两种情况
         1. B确实多这部分数据，删除掉部分数据即可
         2. B多的这部分数据属于其他的日期，如对账范围为（date = '2024-11-09'）,但是B系统多的这部分数据原本应该属于date = '2024-10-25'日期下，由于数据同步过程中漏掉了更新操作，导致B系统这部分数据没更新date值。针对此场景我们需要将B系统多的这部分数据从date = '2024-11-09'修改为date = '2024-10-25'就行了
      3. B部分数据和A不一致，B以A系统值为准修复自身值
2. 不存在基准方，此场景只能人工介入处理，双方各自查看差异数据进行分析核对
   1. 网络问题等不可靠因素导致，增加重试，将系统向尽量可靠方向改进
   2. 程序问题，修改程序重新发布，保证后续不会出现此差异

对于有基准方的场景比如，数据主从同步，数据复制备份等，没有基准方的比如银行之间文件对账。