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

Posted 2023-03-30 程序员 jet_qi

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了架构设计第五讲：数据巡检系统的设计与应用相关的知识，希望对你有一定的参考价值。

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

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

文章目录

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

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

美团 MySQL 数据库巡检系统的设计与应用

说明：
作者：王琦
来源：美团技术团队
最新互联网大厂面试真题、Java程序员面试策略（面试前的准备、面试中的技巧）请访问GitHub

我们生活中随处可见各种巡检系统，比如电力巡检、消防检查等，正是这些巡检工作，我们才能在稳定的环境下进行工作、生活。巡检对于数据库或者其他 IT 系统来说也同样至关重要，特别是在降低风险、提高服务稳定性方面起到了非常关键作用。

一、背景

为了保障数据库的稳定运行，以下核心功能组件必不可少：

技术图片

其中，数据库巡检作为运维保障体系最重要的环节之一，能够帮助我们发现数据库存在的隐患，提前治理，做到防患于未然。对于大规模集群而言，灵活健壮的自动化巡检能力，至关重要。

任何系统都会经历一个原始的阶段，最早的巡检是由中控机 + 定时巡检脚本 + 前端展示构成的。但是，随着时间的推移，老巡检方案逐渐暴露出了一些问题：

巡检定时任务执行依赖中控机，存在单点问题；
巡检结果分散在不同的库表，无法进行统计；
巡检脚本没有统一开发标准，不能保证执行的成功率；
每个巡检项都需要单独写接口取数据，并修改前端用于巡检结果展示，比较繁琐；
巡检发现的隐患需要 DBA 主动打开前端查看，再进行处理，影响整体隐患的治理速度；
……

所以我们需要一个灵活、稳定的巡检系统来帮助我们解决这些痛点，保障数据库的稳定。

二、设计原则

巡检系统的设计原则，我们从以下三个方面进行考虑：

稳定：巡检作为保证数据库稳定的工具，它自身的稳定性也必须有所保证；
高效：以用户为中心，尽量化繁为简，降低用户的使用成本，让新同学也能迅速上手治理和管理隐患；提高新巡检部署效率，随着架构、版本、基础模块等运维环境不断变化，新的巡检需求层出不穷，更快的部署等于更早的保障；
可运营 ：用数据做基础，对巡检隐患进行运营，包括推进隐患治理，查看治理效率、趋势、薄弱点等。

三、系统架构

美团 MySQL 数据库巡检系统架构图设计如下所示。接下来，我们按照架构图从下到上的顺序来对巡检系统主要模块进行简单的介绍。

技术图片

1. 执行层

巡检执行环境 ：由多台巡检执行机组成，巡检任务脚本会同时部署在所有执行机上。执行机会定时从巡检 Git 仓库拉取最新的脚本，脚本使用 Python Virtualenv + Git 进行管理，方便扩充新的执行机。
任务调度 ：巡检任务使用了美团基础架构部研发的分布式定时任务系统 Crane 进行调度，解决传统定时任务单点问题。Crane 会随机指派某一台执行机执行任务，假如这台执行机出现故障，会指派其他执行机重新执行任务。一般一个巡检任务对应着一个巡检项，巡检任务会针对特定的巡检目标根据一定的规则来判断是否存在隐患。
巡检目标 ：除了对生产数据库进行巡检以外，还会对高可用组件、中间件等数据库周边产品进行巡检，尽可能覆盖所有会引发数据库故障的风险点。

2. 存储层

巡检数据库 ：主要用来保存巡检相关数据。为了规范和简化流程，我们将巡检发现的隐患保存到数据库中，提供了通用的入库函数，能够实现以下功能：

自动补齐隐患负责人、隐患发现时间等信息；
入库操作幂等；
支持半结构化的巡检结果入库，不同巡检的隐患结果包括不同的属性，比如巡检 A 的隐患有“中间件类型”，巡检 B 有“主库 CPU 核数”，以上不同结构的数据均可解析入库；
针对表粒度的隐患项，如果分库分表的表出现隐患，会自动合并成一个逻辑表隐患入库。

巡检脚本 Git 仓库 ：用来管理巡检脚本。为了方便 DBA 添加巡检，在系统建设过程中，我们增加了多个公共函数，用来降低开发新巡检的成本，也方便将老的巡检脚本迁移到新的体系中。

3. 应用层

集成到数据库运维平台 ：作为隐患明细展示、配置巡检展示、管理白名单等功能的入口。为了提高隐患治理效率。我们做了以下设计。

隐患明细展示页面会标注每个隐患出现的天数，便于追踪隐患出现原因。
配置新的巡检展示时必须要同时制定隐患解决方案，确保隐患治理有章可循，避免错误的治理方式导致“错上加错”。

隐患运营后台 ：这个模块主要目的是推进隐患的治理。

运营报表，帮助管理者从全局角度掌握隐患治理进展，报表包括隐患趋势、存量分布、增量分布、平均治理周期等核心内容，进而由上到下推动隐患治理；报表数据同样是通过 Crane 定时任务计算获得。
= 隐患治理催办功能，用来督促 DBA 处理隐患。催办内容中会带有隐患具体内容、出现时长、处理方案等。催办形式包括大象消息、告警，具体选用哪种形式可根据巡检关键程度做相应配置。

外部数据服务 ：主要是将巡检隐患数据提供给美团内部其他平台或项目使用，让巡检数据发挥更大的价值。

对接先知平台，美团 SRE 团队开发的主要面向研发人员（下称 RD）用户的风险发现和运营平台，平台接收各服务方上报的隐患数据，以 RD 视角从组织架构维度展示各服务的风险点，并跟进 RD 处理进度。巡检系统会把需要 RD 参与治理的隐患，比如大表、无唯一键表等，借助先知平台统一推送给 RD 进行治理。
运维周报，主要面向业务线 RD 负责人和业务线 DBA，以静态报告形式展示业务线数据库运行情况以及存在的问题，巡检隐患是报告内容之一。