一、立项原因
业务数据普遍是"一写多读"：主库写入后要同步到搜索、缓存、开放接口等多个下游。同步靠消息和代码逻辑驱动，一旦丢消息、写失败或时序错乱，数据就静默不一致，而且往往由业务方或用户先发现，排查要翻日志、人工比对，定位慢、责任难界定。平台要把一致性保障从"人工抽查、事后救火"变成"配置化自动校验、分钟级发现"，让每一条不一致都可追溯、可告警、可复盘。
二、行业场景与业务背景
内容与交易类互联网业务对数据实时一致性要求高，但跨存储同步天然存在延迟和失败。平台面向研发与运维，提供"数据源管理 → 监测场景配置 → 异常结果 → 告警"的闭环：按业务字段配置源与目标的校验规则和容忍时长，超时仍不一致即自动记录源/目标数据快照，并按配置推送钉钉、短信，把问题定位从小时级压缩到分钟级。
1. 数据源管理（DataSourceConfig）
统一登记和管理多类型数据源：MySQL、SQLServer、ES、Redis、MongoDB、第三方接口、Binlog/Kafka 消息流，支持动态接入与凭证配置。
2. 监测场景配置（CheckEventInfo + TargetDataInfo + KeyFieldInfo）
平台核心配置模块，一个监测场景包含三要素：
检测事件（源）：指定源库表、业务唯一字段、被检测字段、最大容忍时间与最大不一致次数
检测目标：指定目标数据源、目标字段、触发条件、校验规则（Aviator 表达式，如 s.xxx == t.xxx）、差异恢复接口
关键字段映射：配置源与目标业务唯一字段的等值/映射关系
3. 实时采集与校验引擎（service 模块）
监听 Binlog/Kafka 变更消息，源数据变更后按容忍时长进入 Redis 延迟队列；xxl-job 定时扫描队列，并发拉取目标端数据、执行规则比对，不一致则重试、超时则判定异常。
4. 异常结果管理（CheckExceptionResult）
异常自动落库，留存源数据与目标数据的完整快照，前端可查询、跟踪不一致明细与恢复状态。
5. 告警通知（AlarmJob + MsgSendApi）
定时聚合 3 分钟内的异常，按场景配置推送给责任人，支持钉钉、短信两种通道，附异常结果查询地址。
6. 管理后台前端（Vue3 + Element Plus）
数据源配置、监测场景配置、异常结果查询三大页面，配套 JSON 编辑器配置触发条件和校验规则。
技术栈
后端 Spring Boot 3 + MyBatis-Plus + Redis（Lua 脚本延迟队列）+ Kafka + XXL-Job + Aviator 规则引擎；前端 Vue3 + TypeScript + Vite + Element Plus + Pinia。
架构
Maven 多模块分层：manager（配置管理后台）/ job（定时校验与告警）/ service（核心引擎）/ dao、dto（数据层），事件驱动 + 延迟窗口比对的准实时架构，避免全量对账。
亮点与难点
多数据源动态路由：7 类数据源（MySQL/SQLServer/ES/Redis/Mongo/RPC/接口）通过注册器工厂 + Invoker 模式动态注册与取数，扩展新源只需插拔实现
分布式延迟队列：Redis ZSet + Lua 实现容忍时长窗口，源变更后延迟校验，天然兼容同步延迟
规则可配置：Aviator 表达式让校验逻辑零代码配置
工程细节：线程池并发比对、按更新时间丢弃乱序旧数据、失败自动重试与降级
评论