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

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间的联动，各业务的边界，服务间的交互