外贸业务数据架构升级：基于TiDB的弹性底座实践

外贸业务的数据天然带着一波又一波的脉冲。黑色星期五、海外圣诞季、平台大促、月末对账流量和数据处理量会在几天之内冲到平时的数倍。外贸赋能中心原先的数据底座是 MySQL 分库分表架构功能上够用但每次大促前都要评估扩容、拆分、迁移成本高风险也不小。这次架构迭代我们选择引入 TiDB 来建设数据弹性底座目标是把“能不能扛住”变成“要不要扩、扩多少”。TiDB 是一个兼容 MySQL 协议的分布式关系型数据库。对业务侧来说大部分基于 MyBatis / JDBC 的应用改动很小对平台侧来说加 TiKV 节点就能扩容PD 会自动调度数据对报表和分析侧来说TiFlash 列存节点可以直接分流查询。正因为这三个特性它很适合作为外贸业务这种“在线交易 实时报表 波峰波谷明显”场景的新底座。这篇文章会把一次典型的数据架构迭代完整拆开先看外贸业务的数据特征和旧架构痛点然后是技术选型与比较再到目标架构设计、MySQL 平滑迁移、大促扩容和数据弹性实践最后列出踩坑清单与合规提醒。如果你正在被分库分表拆分难、跨节点查询慢、报表和在线业务互相干扰这几件事困扰这套思路可以直接参考。1. TiDB 核心能力速览能力项说明数据库类型开源分布式关系型数据库支持 HTAP 混合负载协议兼容兼容 MySQL 协议业务接入成本低核心组件TiDB Server、PD、TiKV、TiFlash扩展方式在线水平扩缩容数据按 Region 自动均衡高可用能力Raft 多副本故障节点自动恢复事务能力分布式事务支持悲观事务与乐观事务分析能力TiFlash 列存副本 MPP 引擎实时分析查询迁移工具Dumpling、TiDB Lightning、DM、sync-diff-inspector典型部署TiUP 部署物理机/虚拟机、TiDB Operator 部署 K8s、TiDB Cloud 托管适用场景高并发 OLTP、交易与分析混合负载、波峰波谷明显的业务平台需要强调的是TiDB 不是把 MySQL “换个皮肤”它引入了分布式事务、Region 调度、TiFlash 列存等新机制。这些机制解决的是传统单机数据库在容量扩展、在线变更和混合负载上的短板但也要求团队重新建立一套运维和 SQL 编写规范。2. 外贸业务的数据特征与旧架构痛点2.1 外贸业务数据有三个鲜明特征第一波峰波谷非常明显。外贸订单和营销活动高度绑定黑色星期五、圣诞季、大促、免税季等节点会在短期内带来大量注册、下单、支付和物流状态更新请求。不只是 QPS 上升更重要的是瞬时写入量放大和报表需求集中数据系统必须有能力在短时间内“扩上去”。第二数据域多、关联复杂。订单、询盘、商品、供应商、客户、结算、报关、物流模块之间天然存在强关联。一个订单从创建到完成会同时涉及库存、汇率、币种、海关编码、物流单号多张表。数据量一旦上来跨模块联查就会成为瓶颈。第三分析需求不满足于离线。外贸运营团队每天要看实时销售看板、对账结果、海外仓库存、汇率损失等指标这些分析以前依赖离线数仓 T1 产出。业务希望把部分分析查询推进到实时范围因此在线交易库与报表库之间的数据时延需要被压缩。2.2 旧架构的四个痛点第一分库分表把查询复杂度转移到了业务层。订单表按订单号分片后按客户查订单、按商品维度聚合、按多币种汇总都需要先路由到多个分片再在应用层做合并排序。如果分片键设计不合理全表扫描式的跨分片查询几乎不可用业务研发被迫维护大量“分片路由 合并结果”的代码。第二跨分片事务和一致性很难做。一个创建订单的流程往往要更新库存、扣减预占、写入流水在多片 MySQL 上实现事务要么引入分布式事务中间件要么编写补偿逻辑。补偿逻辑一旦没覆盖到位就会出现对账不平、库存超卖问题修复成本非常高。第三报表和分析查询与在线交易抢资源。运营看板、财务对账、风控统计经常需要全表扫描或大批量聚合这些 SQL 很容易把 MySQL 实例的 IO 和 CPU 打满直接影响线上订单写入。团队只能通过分时段跑批、限制查询并发来缓解无法从根本上隔离负载。第四扩容和 DDL 成本太高。MySQL 分库分表的扩容不是简单加机器而是要重新设计分片路由并把存量数据迁移过去。给一张几千万行的订单表加索引或调整字段类型在线 DDL 会带来明显的锁写和 IO 压力因此大促前几乎不敢动表结构。3. 为什么选 TiDB 作为数据弹性底座3.1 MySQL 协议兼容改造成本可控TiDB 的顶层对外服务是 MySQL 协议绝大部分 Java/Spring 项目里的 JDBC、MyBatis、Druid 连接池可以直接复用。对于外贸赋能中心来说存量 ERP、CRM、订单系统的改造重点主要落在表结构命名规范、部分 SQL 书写习惯和连接参数上而不是重新实现数据访问层。这里要强调一个边界TiDB 高度兼容 MySQL但并不是 100% 完全等价。存储过程、部分 MySQL 特有 DDL、部分区分大小写和排序规则的行为存在差异。迁移前需要做一轮完整的兼容性试运行把业务 SQL 日志捞出来在测试集群上回放验证。3.2 自动分片加分布式事务替代分库分表中间件TiDB 会把数据按主键切分成 Region每个 Region 默认在 96MB 左右由 PD 负责调度。业务方根本不需要知道数据被拆成了多少片也不再需要维护分库分表中间件或路由规则。分布式事务由 TiKV 通过 Raft 和 PD 的 TSO 时间戳协同实现。业务代码里一个事务可以跨多个数据分片执行使用体验接近单机事务。对外贸订单流程这种“一次操作多张表、多个业务域”的场景这比补偿事务方案要简单得多。3.3 HTAP交易与分析不再是两套系统TiDB 支持在 TiKV 的基础上挂载 TiFlash 列存副本。TiFlash 通过 Raft Learner 实时从 TiKV 同步数据分析查询可以下推到 TiFlash 执行。这样运营看板、对账查询可以直接跑在 TiDB 上不需要再等到半夜同步到 Hive 或 ClickHouse。当然这不是说 TiDB 可以完全替代数仓。复杂的多表关联、超大批量 ETL、数据挖掘仍应进入专门的大数据平台。TiDB 的价值在于把“实时查询”和“在线交易”融合在同一个数据库里减少数据链路层级和口径不一致问题。3.4 在线扩缩容真正解决“弹性”TiDB Server 是无状态计算节点可以随时增减。TiKV、PD、TiFlash 节点调整后PD 会自动执行 Region 迁移把数据从高负载节点移到新节点整个过程不需要业务停写。扩容从“重新迁移数据”变成“加一台机器执行 scale-out”大促前的容量准备可以被标准化。缩容相对要谨慎因为它会触发数据迁移但相比分库分表的重构TiDB 的在线缩容仍然是可接受的。3.5 与其他方案的取舍如果继续留在 MySQL 分库分表架构业务团队需要长期维护路由层、合并层、分布式事务补偿层扩容成本会一次比一次高。引入 TiDB 并不是否定 MySQL而是把“分片”这个复杂度从业务边界剥离到数据库内核。相比另一类分布式数据库产品TiDB 的优势在于 MySQL 生态兼容、HTAP 能力、工具链完整度更高相比“全部离线化”的大数据方案TiDB 更适合在线业务与实时查询并存的场景。对“外贸业务 在线交易 实时报表”这个组合TiDB 的匹配度较高。4. 新数据架构设计4.1 集群拓扑与核心组件在部署上生产环境建议使用 TiUP 管理集群。一个典型的最小高可用拓扑包含 3 个 PD 节点、2 个以上 TiDB Server 节点、3 个 TiKV 节点以及按需部署的 TiFlash 节点。global: user: tidb ssh_port: 22 deploy_dir: /data/tidb-deploy data_dir: /data/tidb-data pd_servers: - host: 10.0.20.11 - host: 10.0.20.12 - host: 10.0.20.13 tidb_servers: - host: 10.0.20.21 - host: 10.0.20.22 tikv_servers: - host: 10.0.20.31 - host: 10.0.20.32 - host: 10.0.20.33 tiflash_servers: - host: 10.0.20.41 - host: 10.0.20.42部署命令如下版本号需要替换为当时选择的目标 LTS 版本tiup cluster deploy tidb-prod v8.1.0 ./topology.yaml --user root -p tiup cluster start tidb-prod tiup cluster display tidb-prod4.2 业务读写链路设计业务的写请求和事务请求统一进入 TiDB ServerSQL 经过解析和优化后下推到 TiKV。对于强一致读默认从 Leader 读取对延迟敏感但允许一定滞后读的场景可以开启 Follower Read让部分只读流量从副本读取分担 Leader 压力。报表和分析 SQL 可以引导到 TiFlash。实现方式是给相应业务表创建 TiFlash 副本查询时由优化器选择是否走列存节点。更严格的场景可以在 SQL 中使用 read_from_storage hint 强制指定。这样在线订单写入和分析查询在存储层实现了分流。4.3 与外贸业务系统的集成方式外贸赋能中心下面的订单系统、CRM、商品中心、结算系统、物流平台统一通过 MySQL 协议接入 TiDB。由于连接协议不变各系统数据源只需要切换连接串、调整连接池参数并在测试环境验证 SQL 兼容性。这里比较建议在 Java 服务层保留统一的数据访问层。数据源切换、读写分离、多租户隔离都可以在 DAL 层完成配置避免每个业务系统单独维护数据库路由逻辑。缓存层 Redis 继续保留热点商品、汇率、订单状态等优先走缓存降低数据库直连压力。4.4 部署形态选择TiUP 适合部署在物理机或虚拟机上适合已经有统一运维平台的团队。如果公司基础架构以 Kubernetes 为主可以使用 TiDB Operator把集群生命周期管理交给 K8s。如果希望减少自建运维成本也可以评估 TiDB Cloud 托管形态。对外贸业务来说机房位置和网络链路需要重点考虑。海外客户访问与国内业务写入之间的延迟、跨境数据传输合规都需要提前规划不能只从数据库软件层面解决。5. MySQL 到 TiDB 的平滑迁移5.1 迁移前评估与准备迁移前需要先梳理清楚三类信息实例容量、表结构、业务 SQL 敏感点。容量方面统计每个业务的数据库实例大小、单表行数、每日增量。TiDB 通过 Region 自动分片单表数据量不再直接决定路由复杂度但存储空间、TiKV 副本数和 TiFlash 副本数会直接影响集群规划。表结构方面需要重点检查主键策略。MySQL 自增主键在 TiDB 中会形成单点写入热点尽量改造为 AUTO_RANDOM 主键或使用业务上可分散的分布键。无主键表建议补充主键否则会影响 TiDB 的数据分片和索引效率。SQL 兼容性方面把业务日志中的慢查询、写操作抓取出来放到测试集群执行形成一份“不兼容 SQL 清单”逐条改造。常见的坑包括存储过程、特殊排序规则、部分 MySQL 5.7 方言语法。5.2 全量数据导出与导入全量数据迁移通常使用 Dumpling 导出 MySQL 数据再用 TiDB Lightning 导入 TiDB。Dumpling 相比 mysqldump导出速度更快也能更好地处理大表。dumpling -h 127.0.0.1 -P 3306 -u root -p ****** -t 4 -F 256MiB -o /data/dump-out导入端使用 TiDB Lightning配置片段如下[lightning] level info file tidb-lightning.log [mydumper]>name: mysql-to-tidb task-mode: all target-database: host: 127.0.0.1 port: 4000 user: root mysql-instances: - source-id: mysql-primary black-white-list: bw-01: do-dbs: [trade, crm]上面的 YAML 只是结构示意实际字段需要参考目标 DM 版本文档。增量同步稳定后业务可以在应用层做一段时间的双写验证把一部分只读流量切到 TiDB对比两边数据。5.4 数据校验与一致性验证数据校验使用 sync-diff-inspector对比 MySQL 和 TiDB 的指定表数据。校验时可以设置 chunk-size避免一次性拉取太大造成内存压力。sync-diff-inspector --config config.toml校验通过后可以分批把业务模块切换到 TiDB。建议先切订单查询、客户查询等只读场景再切写入口。每切换一个模块观察一段时间确认无数据问题后再切换下一个。5.5 灰度切换与回退方案整个切换过程要预留回退方案。TiDB 作为目标端接收双写和读流量期间MySQL 源库仍然保留binlog 持续保留到切换稳定后。如果出现严重问题可以通过切换 DNS 或数据源配置回到 MySQL再通过 DM 反查增量数据避免切换成单线风险。回退不代表不用做数据校验。实际经验是切换稳定运行两周以上监控指标没有异常才考虑关闭 MySQL 源库的写入口。6. 数据弹性实践扩容、热点与 DDL6.1 容量评估思路在大促前或者业务增长预测前先做容量评估观察几个核心指标TiKV 存储使用率、PD 的 Region 数量、集群 QPS 峰值、慢查询数量、TiFlash 副本同步延迟。容量评估要结合业务增量做估算。纯存储增长看磁盘读写压力增长要看 TiDB Server 和 TiKV 的 CPU分析报表增长要看 TiFlash 节点。瓶颈在哪个组件就优先扩容哪个组件不需要整集群整体扩容。6.2 在线扩容 TiKV 节点当 TiKV 的存储或 CPU 成为瓶颈时增加一台 TiKV 节点即可。流程是准备 scale-out.yaml执行 tiup cluster scale-out。tikv_servers: - host: 10.0.20.34 data_dir: /data/tidb-datatiup cluster scale-out tidb-prod ./scale-out.yaml tiup cluster show tidb-prod --watch扩容后 PD 会把部分 Region 调度到新节点业务无需停写。这里要注意观察 Region 调度是否在限定时间内完成尤其是大集群下调度可能因为磁盘 IO 或网络带宽而变慢。6.3 消除写入热点TiDB 最常见的写入热点来源是自增主键。订单表如果继续使用 AUTO_INCREMENT所有写请求都会落到同一个 Region 的 Leader 上写入性能会明显低于预期。迁移时最好把大表主键改成 AUTO_RANDOM。CREATE TABLE t_order ( id BIGINT AUTO_RANDOM(5) PRIMARY KEY, order_no VARCHAR(64) NOT NULL, account_id BIGINT NOT NULL, currency VARCHAR(10), amount DECIMAL(18, 2), order_status TINYINT, created_at DATETIME ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;除了主键还要注意“订单号唯一索引”和“状态筛选”这类查询是否因为索引选择问题变成热点。可以借助 TiDB Dashboard 的热力分布图定位是哪个表、哪个范围出现写入集中。6.4 在线 DDL 与业务变更迁移到 TiDB 后给大表加索引可以直接在线执行不阻塞读写。比如给订单表加一个客户和时间维度的联合索引ALTER TABLE t_order ADD INDEX idx_account_created (account_id, created_at);修改字段默认值、调整字段类型也可以在线执行。不过 DDL 在后台会消耗 TiKV 和 TiDB Server 资源尤其是重建大表数据时尽量不要与业务高峰叠加。DDL 期间通过监控观察写入延迟和磁盘 IO避免全局性能抖动。7. 性能治理与监控运维7.1 慢查询定位TiDB Dashboard 自带慢查询面板可以按 SQL 文本、执行时间、扫描行数排序定位耗时的 SQL。也可以直接查询系统表SELECT * FROM information_schema.slow_query LIMIT 10;重点是区分两类慢查询一类是确实缺少索引导致的 TableFullScan需要加索引或改写 SQL另一类是分布式执行计划下出现了较大的数据扫描需要调整过滤条件、降低回表次数必要时通过 SQL Binding 固定执行计划。7.2 热点诊断写入热点和读热点都可以通过 TiDB Dashboard 的热力图观察。写入热点通常表现为单个或少量 Region 的写入流量明显高于其他 Region。处理思路包括将自增主键改为 AUTO_RANDOM 或业务分布键。对经常按固定范围扫描的数据做分区切分。对热点读数据增加缓存层减少数据库直接读压力。对热点表评估是否拆分到更细的业务维度表。7.3 TiFlash 加速分析分析表创建 TiFlash 副本后统计类查询可以下推到列存执行。例如订单分析表先创建副本ALTER TABLE t_order_