分布式对账系统实现思路

目录

• 背景和价值
• 要解决的问题域是什么？
  • • 1. 能通过配置的方式实现源系统和目标系统的业务对象对账，而无需定制开发（效率）
    • 2. 支持灵活的对账规则。
    • 3. 支持T+1和准实时对账。 （时效）
    • 4. 支持高并发
    • 5. 支持异常数据的监控
    • 6.能够自动恢复一部分异常数据
    • 7.容错。对账服挂了，从之前没跑的地方继续执行，重启不会重复对账。
    • 8. 支持双向对账。
• 技术点
• 流程
  • 对账准备
    • 权限配置
    • 对账任务配置
    • 告警配置
  • 对账执行
    • 准实时对账
      • 基于接口对账实现
      • 基于数据库
    • 实时对账
• 业务模型
• 参考资料

背景和价值

微服务架构，存在分布式事务不一致是常态。

要解决的问题域是什么？

1. 能通过配置的方式实现源系统和目标系统的业务对象对账，而无需定制开发（效率）

2. 支持灵活的对账规则。

双向对账

1. 目标系统的单据跟源系统的单据ID关联只有一条的成功状态 & 单据对应的字段值相等
   例： 交易系统的交易订单状态和总金额 跟 支付系统的 支付单金额和状态一致 ，并且一个订单交易订单只有一个成功的支付订单。

3. 支持T+1和准实时对账。 （时效）

支持基于接口，数据库直连查询，ETL,MQ （实时）

4. 支持高并发

5. 支持异常数据的监控

6.能够自动恢复一部分异常数据

7.容错。对账服挂了，从之前没跑的地方继续执行，重启不会重复对账。

8. 支持双向对账。

为什么要双向对账。 存在丢数据情况。比如交易领域和支付领域对账。以支付为源，如果支付单丢失了，拉取源服务的数据丢了，数据，这样对账发现不了问题。所以要以订单为源再做一次对账。

技术点

1. 跨天导致加载的对账数据丢失问题。如创建订单时间是1月1日，支付时间是1月2日凌晨。
   解决：使用更新时间作为查询条件，而不是创建时间。
2. 源系统的数据，在目标系统找不到数据。 比如订单为源，在供应链（下游）那边找不到数据怎么处理？
   解决：这个问题有可能供应链还没处理完，也可能是异常导致。 设定一个等待时间，如果在等待时间内还是没有返回，就标记异常。
   比如以小时为对账单位。 订单0点30分处理完了。 到了1点30跑定时任务取0-1点供应链处理完成的数据没有取到，但是供应链在1-2点处理完了。

流程

对账准备

权限配置

应用配置：以界限上下文为边界配置
角色配置：角色有：团队负责人，开发。不同的角色配置不同的资源权限。
人员配置： 配置人员以及所属角色

对账任务配置

告警配置

对账执行

准实时对账

基于接口对账实现

分页拉取源数据，再调用目标数据接口在内存做对账，完成后落库。

基于数据库

配置sql，分页拉取，在内存对账，完成后落库。

实时对账

消息准时候对账。收到消息后去目标服务查数据，如果查询不到先cache，多久内查询不到，算异常对账。

业务模型

参考资料