架构设计第五讲：数据巡检系统的设计与应用

架构设计第五讲：数据巡检系统的设计与应用

本文是架构设计第五讲：数据巡检系统的设计与应用

1、数据巡检系统

1.1、背景知识

1、为什么做数据巡检系统？

• 为了保障系统上下游数据一致性

2、哪些因素会产生一致性问题？

• ①人为因素：场景遗漏，上游业务变更忘记联动下游业务
• ②系统异常：服务器 FullGC，CPU 100%，服务器扩容、缩容、重启等异常场景

3、订单、财务，哪些数据做了同步？

• 涉及的表
• 关键字段(需保障一致性)
  • 与搜索相关的字段
  • 业务计算相关字段
• 非关键字段(不用保障数据准确性)

4、触发同步的时机有哪些？

货代

• 场景1：创建订单 admin/v1/agent/order/create
• 场景2：复制订单 /admin/v1/agent/order/copy/create
• 场景3：更新订单 admin/v1/agent/order/update
• 场景4：修改订单状态 v1/agent/order/changeState
• 场景5：更新应收应付费用状态 /admin/v1/agent/order/changeFeeState

车队

• 场景1：创建主订单 admin/v1/convoy/order/create
• 场景2：更新主订单 /admin/v1/convoy/order/update
• 场景3：批量更新子订单状态 admin/v1/convoy/order/state/batchUpdate
• 场景4：编辑子订单 /admin/v1/convoy/order/sub/update
• 场景5：添加子订单 admin/v1/convoy/order/sub/add
• 场景6：子订单列表页点击修改后保存的数据 admin/v1/convoy/order/partUpdate

1.2、方案

1、现有业务梳理

• 货代订单联动财务

• 车队订单联动财务

• 

2、存在的问题

• 1、耦合性强。
  • 采用定时任务补偿的方式解决一致性问题。补偿逻辑嵌套在业务系统中，高耦合。
• 2、不够抽象。
  • 对账逻辑散落在各个业务系统，相同功能代码，多次编写。将各个系统的数据获取逻辑、对账逻辑、差错处理逻辑可以做收拢处理；
  • 使用策略模式

3、通用对账逻辑

• 通用逻辑
• 

方案如上图所示：

• 开一个新项目，专门用于处理对账逻辑。

  • 业务注册：将需要处理的对账业务设计成策略，然后注册到Spring中

  • 数据获取：定时任务按更新时间查询近5s到近65s的数据(近5s是防止mq还没来得及消费)，先获取上游业务，拿到ids，然后由ids查询下游业务

  • 对账处理：由于必须先获取上游业务，如果上游业务数据为空，暂不考虑这种场景；–》如果下游业务不存在，说明需要做新增操作 --》如果数据不一致(按订单更新时间)，说明需要联动

    • 哪些数据需要做比对？怎么比对？

      • 场景1： 上游业务存在，下游不存在 create

      • 场景2：上游业务删除了数据，下游没有联动 delete

        • **业务允许硬删除吗？**订单业务在页面上不会硬删除
          • 什么场景下订单数据会硬删除呢？
          • 业务状态置为作废后，下游业务能查到吗？ 目前是可以查到的
          • 该场景暂不考虑

      • 场景3： 上游修改了数据，但下游没联动 update

    • 数据不一致，记录到 falcon_biz_diff表里面，便于统计

  • 差错处理：

    • 怎么去做补偿？

      • 方法1：异步推送存在问题的订单数据，让下游自行处理。

        • 优点：异步处理，
        • todo项：限流处理，超过最大重试次数后 log.error、且配置死信告警。
        • 消费失败后，配置监控告警，研发及时介入处理

      • 方法2：调用下游业务提供的rpc接口，做数据同步处理。

        • 缺点：可能存在性能问题
        • 调用rpc失败后，需研发自行设计重试逻辑

• 达到的效果

  • 1、相同功能代码，不用多次编写；
  • 2、可扩展性强，当需要增加新功能时，非常方便

4、性能问题

• 1、把mapper拷贝到对账系统中，采用多数据源，在系统里面读数据和写数据，业务方无感知
  • 好处是：这样可以减少对业务系统的压力
  • 风险是：业务变了，有些字段需要同步，有些不需要同步，我这边也得随时调整
  • 二期可以这样做
• 2、待优化点
  • 1、上游业务的更新时间、下游业务的更新时间如果数据不一致，保存起来，最好放在json里面
  • 2、任务执行周期：推荐半小时或1小时比对一次
  • 3、暂不考虑mq消费堆积或消费延迟问题：如果下游mq消费比对账任务慢，先不考虑

1.3、方案细节

• 接口设计

  • 1、rpc接口：
    • 货代订单提供rpc接口，由更新时间(起始，终止)批量查询订单详情
    • 车队子订单提供rpc接口，由更新时间(起始，终止)批量查询子订单详情
    • 货代财务订单提供rpc接口，由订单ids 批量查询财务订单详情
    • 车队财务子订单提供rpc接口，由子订单ids 批量查询财务订单详情
  • 2、对账系统
    • 策略类：
      • 货代订单策略：提供 数据获取接口 对账处理接口，差错处理接口
      • 车队订单策略：提供 数据获取接口 对账处理接口，差错处理接口
    • 定时任务
      • 提供对象功能：拿到全部策略，遍历处理 --》执行相应的策略类提供的方法，将差异数据落库处理

• 表结构设计

  • 表1：falcon_biz_increment 暂不用考虑

  • 表2：falcon_biz_diff

    • id 主键id long
    • bizId 业务id long
    • bizType 业务类别 String
    • keyFieldJson 业务关键字段数据 String
    • diffType 差异类别 (create、update、delete) integer
    • batch_id bigint '批次id
    • status tinyint(1) DEFAULT ‘0’ COMMENT ‘状态,0-待确认,1-确认’,
    • tenant_id 租户id
    • CreateAt 创建时间
    • UpdateAt 更新时间

• 数据库设计

  • 新增一个库

    CREATE TABLE IF NOT EXISTS `falcon_biz_diff`
    (
        `id`          bigint 			unsigned auto_increment comment '主键id' primary key,
        `biz_id`       bigint      not null COMMENT '业务id',
        `biz_type`     varchar(20) not null COMMENT '类型',
        `key_field_json` longtext  	not null comment '业务关键字段数据',
        `diff_type`    tinyint  		null comment '差异类别 (create、update、delete)',
        `batch_id`     bigint      null comment '批次id',
        `status` 				tinyint(1) DEFAULT '0' COMMENT '状态,0-待确认,1-确认',
      	`tenant_id`    bigint      not null COMMENT '租户id',
        `create_time` datetime default CURRENT_TIMESTAMP not null comment '创建时间',
        `update_time`   datetime default CURRENT_TIMESTAMP not null on update CURRENT_TIMESTAMP comment '更新时间'
    ) DEFAULT CHARACTER SET = utf8mb4 COMMENT = '数据表';
    

数据库实例

• rm-wz936ji5413x9l86j 真线

• rm-wz9d545c689v19pss 测试环境

• 库名：falcon-coordination 待开通权限

• 表名：falcon_biz_diff

• • 待确认：使用单独的库还是共用其他库，如果是共用，共用哪个库？

项目

• falcon-coordinate 对账服务
• git项目权限 todo 待开通权限

项目结构

• 直接看代码

1.5、参考资料

• maven脚手架，快速创建一个新应用

2、上线后的效果

todo

3、数据巡检系统二期规划

巡检服务：

• 检测慢sql mysql.存起来，然后推送给钉钉
• 检测daily环境和线上环境表结果的不一致，记录起来
• 检测redis慢查询，大key，记录起来

Action1：对账系统存在的问题

• 问题1：数据读取逻辑，是通过rpc还是通过直连db，多数据源

  • 最终方案：
    • 使用rpc来拉取数据订单和财务数据
  • 原因：
    • 货代订单：order_info 单表同步到 货代财务：finance_order、finance_fare_info两张表
    • 车队订单：order_info、sub_order_info、sub_order_doors_info、sub_order_carrier_info 四张表同步给 车队财务：finance_sub_order_info、finance_fare_info，finance_carrier_info三张表，字段映射极为复杂， 如果选择直连db、通过写sql的方式来执行查询逻辑，太过于复杂

• 问题2：字段比对逻辑

  • 方案：
    • 需要统计出具体哪几个字段发生了变化并落库，因此使用注解 + 反射来做比对逻辑
  • 需要对比的字段范围
    • 对关键数据，才进行diff操作，减少工作量
    • 关键数据指：财务服务 在列表页作为搜索条件的数据、以及参与业务计算的数据，非关键数据可以rpc反查订单得到

• 问题3：定时任务执行周期

  • 执行周期暂定5分钟

• 问题4：车队财务反查逻辑漏洞

  • 存在的问题：
    • 财务按更新时间调用rpc反查订单时，车队订单只是将更新时间范围内的子订单返回给财务
  • 需要改造为：
    • 将order_info、sub_order_info、sub_order_doors_info、sub_order_carrier_info这四张表在更新时间范围内的数据（交集）返回给财务

Action2：进公司做什么价值大？

• 服务A、B、C间的联动，各业务的边界，服务间的交互