" 你是否经历过，测试过程中因配置不一致或缺失，导致卡点2小时 "
1. 痛点直击
1.1 测试卡点（QA视角）
14：00 我在执行某条测试case时，下了一个订单，根据规则，期望订单的主体是A，但实际订单的主体是B，结果与预期不符；
14：30 我向订单QA反馈："这个订单的主体A吧，为什么是主体B呢"，经过排查后，订单QA发现订单主体赋值依赖业财接口；
15：00 我联系到业财QA，沟通+排查之后，最终发现问题根源：该业务线的线下配置缺失；
15：30 业财QA将线上的配置手动加到线下后，我重新下单，结果符合预期，问题终于解决，花费2小时+。
问题
业务测试卡点
QA人员频繁被打断
手动配置耗时长
1.2 配置风险（PM视角）
OA系统审批模板，主要由审批表单和审批流程组成，每当新增或改动，需要在线上环境和测试环境中分别配置两次。
对于复杂的模板，可能包含几百个表单和流程，两个环境的配置一致性，只能依靠肉眼检查。如果出现漏配，甚至是一个大小写字母或符号的错误，就会引发系统异常。一旦在测试阶段未能发现，极有可能成为隐藏的线上问题。
问题
- 日常工作效率低
- 潜在的质量问题
1.3 安全性（RD视角）
业务方要求某些数据在线下和线上保持一致，因此我们通过每日运行脚本，将线上数据全量同步到线下。然而，由于每天需要同步的数据量庞大（上千万条），影响到了其他业务方数据库。
问题
- 数据库安全问题
1.4 问题总结
以上场景暴露的问题，都是由于线上和线下两个数据库，数据不一致导致。通过总结和思考，确定了目标------搭建通用的数据同步能力，将线上数据同步至线下，提升工作效率，解决潜在质量问题。
2. 方案探索
2.1 方案一：定时同步
方案
记录线上库主键值，定时同步存量数据
示例：第一次同步10<id<=20的数据，第二次同步20<id<=30的数据
问题
- 适用性不够高：对表定义有要求，若主键不规则，如不规则字符串，则无法准确同步
- 准确率不够高：线下数据易变，数据容易冲突，导致同步失败
- 存在风险：过程中需要操作线上库
- 同步类型有限：只能同步插入，不能同步更新和删除
因为上述问题，该方案只能满足部分场景的使用，我们开始调研，是否存在自动且准确率更高的方式。
解决
调研后决定使用公司架构部提供的binlog mq，通过消费mq，同步每条数据的变更，达到 自动 实时 同步的目的，即方案二
2.2 方案二：自动同步
方案
通过线上库binlog mq驱动，实时同步增量数据 
（1）解析mq，获取到必要信息，如更新前数据、更新后数据、操作的库表、操作类型等
json
// mq内容示例
{
"before": null,
"after": {
"id": 0,
"name": "bbb",
"score": 88
},
"source": {
"db": "cdc",
"table": "t1"
},
"op": "c"
}（2）维护线下数据库连接，获取线下数据库表信息
sql
//获取主键
SELECT cu.Column_Name FROM INFORMATION_SCHEMA.`KEY_COLUMN_USAGE` cu WHERE CONSTRAINT_NAME = 'PRIMARY' AND cu.Table_Name = {tableName} AND CONSTRAINT_SCHEMA={dbName}
//获取自增键
SELECT COLUMN_NAME FROM information_schema.columns WHERE TABLE_SCHEMA= {dbName} AND TABLE_NAME = {tableName} AND extra = 'auto_increment';
// 获取唯一索引
show index from {tableName} where Non_unique=0 and Key_name != 'PRIMARY';
//获取表字段信息
show COLUMNS from {tableName};（3）前置判断数据是否可以同步
insert：唯一键、主键数据不存在时，才可同步
update：需要更新的数据存在时，才可同步
delete：需要删除的数据存在时，才可同步
（4）拼装sql
对每一个字段精细化处理
如：自增键处理、json类型字段处理、字符和非字符类型字段区分、转义符处理等
（5）执行sql，完成
方案对比
| 方案一 | 方案二 | |
|---|---|---|
| 适用性 | 低 | 高，不再依赖主键定义规则 |
| 准确率 | 低 | 高，动态拼装sql，对每个字段可精细化处理 |
| 同步风险 | 存在风险，操作线上库 | 无风险，和线上库无交互 |
| 同步类型 | insert |
insert、delete、update |
| 触发时机 | 定时任务 | 线上数据发生变化 |
| 同步数据 | 存量数据 | 增量数据 |
数据库拓展
应用过程中，收集到部分业务使用的TiDB同样有数据同步需求。
通过阅读 TiDB官方文档，确定TiDB数据同步方式：消费TiCDC提供的kafka mq进行同步，复用binlog mq处理的功能。
最终方案效果：MySQL 和 TiDB 双库"自动""实时"同步 。 
问题
在推广过程中，发现仍然存在需要手动同步的需求。 比如：售后只想在线上规则A发生变化时，人为触发同步规则A。
解决
在方案一的基础上进行了优化，即方案三
2.3 方案三：手动同步
方案
方案一的升级版，指定需要同步的数据，手动执行
示例：指定同步条件，如 id IN (100,101,102)
升级内容
-
不再依赖主键大小，人为指定数据范围
-
采用
replace into，强一致同步，解决数据冲突问题
3. 方案落地
最终，在实际应用中选择了方案二和方案三的组合，满足不同场景下的使用。两种方案均适配TiDB和MySQL两种数据库，无需开发，一键配置即可使用
| 自动同步（方案二） | 手动同步（方案三） | |
|---|---|---|
| 适用场景 | 大数据量增量同步 | 小数据量存量同步 |
| 风险 | 零线上交互，无风险 | 和线上库有交互，使用方法有要求 |
| 效率 | 实时 | 按需即时 |
| 典型应用场景 | 打款账户配置实时同步线下 | OA审批模板同步 |
3.1 自动同步
功能介绍
-
简单配置即可使用
-
支持动态注册
rocket mq和kafka mq消费者 -
提供过滤操作类型、自增键强一致、数据强一致等个性化功能
后台页面
3.2 手动同步
功能介绍
- 支持指定某条数据同步：如指定
id=1 - 支持指定范围数据同步：如指定
id<10
后台页面
4.实战应用
日均同步约 50W-150W 数据，失败率 <0.00000001
| 自动同步 | 手动同步 | |
|---|---|---|
| 接入数量 | 9个库，88张表 | 14个库，74张表 |
| 接入业务 | 订单、支付、业财、基础服务、商户、天路等 | 订单、支付、业财、OA、售后、促销等 |
4.1 项目应用
在5个公司级项目中成功应用
| 同步数据量 | 人工配置耗时 | 选择方案 | 工具同步耗时 | 提升效率 | |
|---|---|---|---|---|---|
| 项目A | 14张表数据迁移 | 8h=480min | 手动同步 | 10min | ↑98% |
| 项目B | 新增20+配置 | 2h=120min | 自动同步 | 0 | ↑100% |
| 项目C | 新增70+配置 | 6h=480min | 自动同步 | 0 | ↑100% |
| 项目D | 新增20+配置 | 2h=120min | 自动同步 | 0 | ↑100% |
| 项目E | 50+个模板同步 | 25h=1500min | 手动同步 | 30min | ↑98% |
4.2 日常配置自动同步
一个配置问题节省 1-2h
支付QA反馈：降低了支付周均20%被打断耗时
4.3 OA审批模板同步
通过一键同步，节省50%的产品工作量，节省100%的测试工作量
无需两个环境配置2次+测试2次，收到PM、RD正向反馈：效率提升100%！
4.4 商品数据自动同步
配置自动同步后，通过实时同步增量数据，解决了因刷数导致数据库资源占用过高，影响其他业务方数据库的安全性问题
" 数据同步不是复制粘贴，而是业务流程的隐形引擎 "
作者： 蔺文文 转转测试开发工程师
欢迎大家留言、交流、相互学习
转转研发中心及业界小伙伴们的技术学习交流平台，定期分享一线的实战经验及业界前沿的技术话题。
关注公众号「转转技术」（综合性）、「大转转FE」（专注于FE）、「转转QA」（专注于QA），更多干货实践，欢迎交流分享~