企业官网建设流程全解析

目录

一、前置准备（迁移前必做）

1. 环境与资源评估

2. 数据口径 & 校验规则

3. 流量与风险预案

二、标准四阶段迁移流程（零停机通用架构）

阶段 1：全量冷数据迁移（存量同步，业务不受影响）

阶段 2：开启增量同步 + 双写（核心：保证数据不丢、不不一致）

阶段 3：灰度切读（逐步把读流量切到目标库，风险最低）

阶段 4：切写流量 + 下线源库（收尾）

三、分场景专项优化（亿级数据高频问题）

1. 分库分表架构迁移（最常见）

2. 大表 / 超亿单表优化

3. 冷热数据分离迁移

4. 跨数据库类型迁移（MySQL→PG/ClickHouse/ES 等）

5. 高并发写入场景

四、主流工具选型（生产落地）

五、核心避坑点（生产事故高发区）

六、极简总结（落地口诀）

核心思路：双写兜底、逐步切流、灰度校验、旧数据渐进迁移、最终下线，全程业务无感知、不中断服务，分阶段落地。

一、前置准备（迁移前必做）

1. 环境与资源评估

• 目标库：算力、内存、磁盘、网络带宽扩容，匹配亿级数据读写压力；源库 / 目标库版本、字符集、排序规则、字段类型完全对齐。
• 带宽：存量全量迁移会产生大量 IO，隔离迁移流量与业务流量，避免抢占资源。
• 元数据对齐：表结构、索引、约束、触发器、分区、存储过程、权限、路由规则提前统一，禁止迁移中改表。

2. 数据口径 & 校验规则

• 定义数据一致性标准：行数、主键、唯一索引、核心字段、增量变更时序。
• 准备校验工具：行级比对、抽样比对、全量对账脚本，提前压测校验性能。
• 梳理业务读写链路：读多 / 写多、热点表、大字段、冷热数据、定时任务、MQ / 缓存联动逻辑。

3. 流量与风险预案

• 限流、熔断、回滚方案、应急切换脚本；全流程压测（模拟亿级存量 + 实时增量）。
• 缓存预热规则：防止切流后缓存击穿。

二、标准四阶段迁移流程（零停机通用架构）

阶段 1：全量冷数据迁移（存量同步，业务不受影响）

目标：把历史存量数据从源库一次性同步到目标库，不影响在线读写。

1. 选择低峰窗口（凌晨业务低谷），使用离线批量同步工具：
   • MySQL：mysqldump/mydumper（并行导出）、DataX、Canal Dump、DTS 全量模式
   • 大数据 / 数仓：Spark/Flink 离线任务、Sqoop
2. 优化迁移参数：
   • 分库分表 / 分区拆分迁移，禁止单表亿级全表扫；按主键 / 时间范围分片并行同步。
   • 限速、分批提交，控制源库 CPU、IO 负载，避免拖垮线上。
3. 同步完成后：第一轮全量数据校验，核对总行数、抽样明细、索引有效性。

关键点：此时业务仍只读写源库，目标库仅做镜像。

阶段 2：开启增量同步 + 双写（核心：保证数据不丢、不不一致）

全量同步完成后，源库已产生新增量数据，必须补追增量，再开启双写。

1. 增量追平用增量同步组件（Canal、Debezium、RocketMQ Binlog、数据库 DTS）监听源库 Binlog，实时同步新增 / 更新 / 删除到目标库，直到双库数据完全追平、延迟趋近于 0。

2. 应用层开启双写（最稳妥方案）改造业务代码 / 中间件，写操作同时写入源库 + 目标库，规则：

   • 写入优先级：源库优先落库，目标库写入失败不阻塞主流程（日志告警、重试队列兜底）。
   • 幂等设计：主键 / 唯一键防重复写入，避免双写产生脏数据。
   • 关闭自动自增冲突：统一 ID 生成器（雪花 ID、号段模式），禁止数据库自增主键双写冲突。

3. 运行观察：持续监控双库延迟、写入成功率、报错日志，稳定运行数小时～数天（根据业务量级）。

备选方案（不改代码）：中间件层双写（Sharding-JDBC、Proxy、数据库触发器），生产不推荐触发器（性能差、死锁风险高）。

阶段 3：灰度切读（逐步把读流量切到目标库，风险最低）

双写稳定、数据一致后，先切读、后切写，灰度放量，出现问题立刻回滚。

1. 灰度策略（由小到大）：
   • 按用户 ID 分片、地域、接口、应用集群比例切流：0% → 10% → 30% → 50% → 100%
   • 热点数据、核心接口最后切换。
2. 监控指标： 响应耗时、错误率、慢 SQL、缓存命中率、双库数据差异、Binlog 延迟。
3. 异常回滚：一旦出现查询异常、数据不一致，一键切回源库读。

读流量全量切到目标库后，再稳定观察一段时间。

阶段 4：切写流量 + 下线源库（收尾）

1. 切写流量逐步关闭应用双写，将写操作完全切换到目标库，源库不再接收新写入。
2. 最后一轮全量校验：确认双库数据 100% 一致，无遗漏、无脏数据。
3. 下线流程：
   • 停止 Binlog 增量同步、同步任务；
   • 源库保留7~30 天（冷备、回滚兜底）；
   • 逐步下线源库连接、权限、监控，最终销毁 / 归档。

三、分场景专项优化（亿级数据高频问题）

1. 分库分表架构迁移（最常见）

• 方案 1：同规则迁移（分片键、分片算法不变），逐分片迁移、逐分片切流。
• 方案 2：重分片 / 扩容（分片规则变更）： 先全量 + 增量同步到新分片集群 → 双写新旧分片 → 灰度切读 → 切写，全程保证路由正确。

2. 大表 / 超亿单表优化

• 按时间范围、主键区间拆成分批任务，避免全表扫描锁表、IO 打满。
• 迁移前临时关闭非必要索引（加速导入），导入完成再重建索引（生产常用）。
• 禁止在线ALTER TABLE，迁移期间表结构冻结。

3. 冷热数据分离迁移

• 冷数据：离线批量迁移（低峰）；
• 热数据：Binlog 增量实时同步 + 双写，优先保障热点行。

4. 跨数据库类型迁移（MySQL→PG/ClickHouse/ES 等）

• 额外做字段类型映射、函数兼容、SQL 语法适配；
• 增量同步做数据转换清洗，前置 ETL 校验；
• 读接口单独适配，灰度验证查询逻辑。

5. 高并发写入场景

• 双写阶段增加异步重试队列，目标库抖动不影响主业务；
• 迁移任务限速，和业务流量错峰；
• 关闭源库慢查询日志、全量日志，降低负载。

四、主流工具选型（生产落地）

五、核心避坑点（生产事故高发区）

1. 不要先切写再切读：一旦目标库故障，直接全线宕机，顺序必须「双写→切读→切写」。
2. 忽略 ID 冲突：自增主键、唯一索引在双写时极易重复，统一分布式 ID 是前提。
3. 索引缺失：迁移后忘记重建索引，导致目标库查询超时。
4. 只抽样不做全量校验：亿级数据抽样无法发现零星丢数、错数。
5. 迁移后立刻删除源库：必须留观察期，保留兜底数据源。
6. 触发器 / 存储过程不同步：隐性逻辑不一致，引发业务异常。

六、极简总结（落地口诀）

先全量迁存量，Binlog 追增量；应用开启双写保一致；灰度逐步切读，稳定再切写；多轮校验，源库留底再下线。整套方案全程服务不中断、业务无感知，是互联网、金融、大数据领域亿级数据迁移的标准落地范式。