1双轨运维靠人工
本地网站照常更新，省平台靠人工或临时脚本补报，两套数据容易脱节。
政务
就业人才网对接省「湘就业」数据同步
不改原网站，旁路同步中台按水位增量推送，失败可查、断点续传。
已上线政务小型项目PC 后台
- 客户
- 市级人力资源市场运营方按约定不公开
- 行业
- 政务
- 终端
- PC 后台
- 规模
- 小型项目 · 2020
01项目背景
客户是某市人力资源市场的运营方，企业入驻、岗位发布、招聘会报名等日常业务都跑在一套存量 PHP 招聘网站上。按省人社部门要求，企业、岗位、招聘会数据还要汇入省级「湘就业」平台，此前靠人工或临时脚本补报，两边数据经常脱节。项目要在不动原网站的前提下，把上报做成按时、合规、可追溯的系统流程。
- 客户类型
- 市级人力资源市场运营方
- 同步对象
- 企业、岗位、招聘会 + 基础字典
- 用户角色
- 运营管理员、技术开发
- 上线终端
- PC 管理后台
02业务痛点
2字段口径不一致
站内分类 ID、Unix 时间戳、自由文本地址，与省平台的标准编码和日期格式对不上。
3增量边界不清
没有统一记录「上次同步到哪」，全量重推耗时又易重复，中断后难以续传。
4失败不可见
接口报错只留在控制台，运营不知道哪家企业、哪个岗位没有报上去。
原网站不能动，省平台却要按标准、按时、可追溯地收数据。
03解决方案
我们在原网站旁边建了一套独立的旁路同步中台，只读原业务库，不改动任何前台与审核流程。中台负责增量抽取、字段映射、分批推送和逐条留痕，运营在 PC 后台就能看到每类数据同步到哪、哪条失败、为什么失败。
旁路只读，不动原站
同步服务跨库只读原 MySQL 业务库，企业、岗位、招聘会仍在原网站录入和审核。
按水位增量抽取
企业、岗位、招聘会各设一条同步水位，只取水位之后的变更，按时间升序处理。
映射统一放在 SQL 层
分类、学历、区县通过字典表转为省标编码；时间戳转为 YYYYMMDD，地址去除空格。
业务规则前置过滤
企业认证四种状态映射为省平台的有效 / 无效两态；只推送发布日起三个月内仍有效的岗位。
分批推送，逐条留痕
每 10 条一批、一批一个批次号；每条记录写入返回码与说明，处理一条即推进一次水位。
字典先行，定时 + 手动
行业、学历、地区等字典全量镜像到同步库；各对象可配置独立定时，也保留手动触发入口。
04核心流程
水位增量同步流程
- 1
读取水位
读取该对象上次同步到的时间点
- 2
增量抽取
跨库查询水位之后的新增与变更记录
- 3
映射清洗
转为省标编码、日期格式与审核状态
- 4
分批组包
每 10 条一批，生成唯一批次号
- 5
签名推送
带时间戳签名，经市级交换平台送达省平台
- 6
写入明细
逐条记录返回码与结果说明
- 7
推进水位
逐条更新水位，再取下一批
每处理一条即推进水位：任务中断后从最后成功的位置继续，已成功的数据不会重复推送。
05项目价值
原站零改动
招聘网站前台与审核流程保持原样，业务表只需维护一个变更时间字段供增量抽取。
每条可追溯
每条推送都有批次号、业务 ID、返回码和说明，「推没推、为何失败」在后台直接可查。
断点续传
按对象分设水位、逐条推进，中断后从断点继续，不必全量重推。
参数可调
批大小、定时频率独立配置；测试与正式环境账号分离，省平台调整限流时只改分批参数。
06界面展示
界面图为原型或用示例数据重做的界面，不含真实客户数据、金额与账号。
07技术栈
- 后端
- Java 17Spring BootMyBatis-FlexCool-Admin
- 前端
- Vue 3Element Plus
- 数据与集成
- MySQL 跨库只读Quartz 定时任务Apache HttpClientHMAC-SHA1 签名
- 部署
- 独立部署，与原网站同机房测试 / 正式配置分离
