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