正文

架构设计第五讲：数据巡检系统的设计与应用(代码片段)

程序员jet_qi  程序员jet_qi  2023-03-30  783

关键词：

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

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

文章目录

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

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

企业架构设计实战应用架构设计(代码片段)

前言企业IT架构包括应用架构、数据架构和技术架构，企业IT架构与业务架构共同构成了企业架构的核心内容。接下来重点介绍IT架构中的应用架构。应用架构是对企业所有应用系统、服务及它们之间交互关系的整体描述，... 查看详情

企业架构设计实战4应用架构设计(代码片段)

大数据技术原理与应用：第五讲nosql数据库

5.1NoSQL概论 5.2NoSQL与关系数据库的比较5.3NoSQL的四大类型5.4NoSQL的三大基石5.5从NoSQL到NewSQL数据库‘5.6文档数据库MongoDB 查看详情

2018-2019-120165301《信息安全系统设计基础》第五周学习总结(代码片段)

2018-2019-120165301《信息安全系统设计基础》第五周学习总结学习目标了解常见的存储技术（RAM、ROM、磁盘、固态硬盘等）理解局部性原理理解缓存思想理解局部性原理和缓存思想在存储层次结构中的应用高速缓存的原理和应用学... 查看详情

设计数据密集型应用(代码片段)

...共12章。这是一本理论结合实践的书。本书为数据系统的设计、实现、评价提供了很好的概念框架。本书着重讨论三个在大多数软件系统中都很重要的问题：可靠性（Reliability）系统在困境（adversity）（硬件故障、软件故障... 查看详情

201652062018-2019-1《信息安全系统设计基础》第五周学习总结(代码片段)

-201652062018-2019-1《信息安全系统设计基础》第五周学习总结-教材学习内容总结-随机访问存储器：随机访问存储器分为两类：静态RAM（SRAM）和动态RAM（DRAM）。静态RAM将每个位储存在一个双稳态的存储器单元里；动态RAM将每个位存... 查看详情

hive的设计与架构(代码片段)

本文包含Hive的设计与架构的详细信息，具体内容如下：Hive架构Hive数据模型元存储Motivation元数据对象Hive架构图中展示了Hive的主要组成部分，以及与Hadoop的交互，如图所述，Hive的主要组件有：UI–提供给用... 查看详情

canal——高可用架构设计与应用(代码片段)

前言本篇只介绍跟高可用相关的配置。TCP模式请参考文章：【Canal——增量同步MySQL数据到ElasticSearch】Kafka模式请参考文章：【Canal——canalserver读取binlog到kafka然后在使用canal-adapter】Canalserver和client端的高可... 查看详情

亿级京东应用架构设计与治理(代码片段)

👇👇关注后回复 “进群” ，拉你进程序员交流群👇👇经过十年的业务快速发展，京东信息系统复杂度越来越高：一般电商系统只需关心“进销存”中的“销”，京东系统需要管理采购（进&... 查看详情

万级tps亿级流水-中台账户系统架构设计(代码片段)

万级TPS亿级流水-中台账户系统架构设计背景业务模型应用层设计数据层设计日切对账背景我们需要给所有前台业务提供统一的账户系统，用来支撑所有前台产品线的用户资产管理，统一提供支持大并发万级TPS、亿级流水、数据... 查看详情

万级tps亿级流水-中台账户系统架构设计(代码片段)

企业架构设计实战大数据架构设计(代码片段)

数据架构概述什么是数据？一个企业的数字化核心是数据，数据化的价值依赖于数据的标准和质量，数据对一个企业来说至关重要，它也是整个信息化建设及企业架构的核心。数据具有多样性，有结构化的、... 查看详情

hadoop之hdfs架构设计(代码片段)

Hadoop之HDFS架构设计简介优点缺点前提和目标硬件故障数据流访问大数据集一致性模型移动计算比移动数据更便宜跨异构硬件和软件平台的可移植性NameNodeandDataNodes文件系统命名空间数据复制副本放置副本选择安全模式文件系统元... 查看详情

企业架构设计实战5大数据架构设计(代码片段)

201723332018-2019-1《程序设计与数据结构》第五周学习总结(代码片段)

201723332018-2019-1《程序设计与数据结构》第五周学习总结教材学习内容总结==《Java软件结构与数据结构》第九章-排序与查找==一、查找①.查找概念：在一个项目中寻找一个元素或者判断一个元素是否存在在这个项目中。②.查找的... 查看详情

数据仓库的架构与设计(代码片段)

...知识。涉及的主要内容有：什么是数据仓库？数据仓库的架构数据仓库多维数据模型的设计 1.什么是数据仓库1.1数据仓库的概念官方定义数据仓库是一个面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合... 查看详情

架构设计手册(代码片段)

架构设计参考手册系统设计的一些原则在设计系统时，应该多思考墨菲定律在系统划分时，也要思考康威定律高并发原则高可用原则业务设计原则总结负载均衡与反向代理Nginx负载均衡算法失败重试健康检查备份上游服务... 查看详情

vivo全球商城：电商交易平台设计(代码片段)

...列文章一、背景vivo官方商城经过了七年的迭代，从单体架构逐步演进到微服务架构，我们的开发团队沉淀了许多宝贵的技术与经验，对电商领域业务也有相当深刻的理解。去年初，团队承接了O2O商城的建设任务，还有即将成立... 查看详情