企业官网建设流程全解析

大宗商品销采运储系统・六层架构连载（数据持久层）

前面，我们完成了公共中间件层的完整底座搭建：服务发现、动态配置、消息通信、缓存加速、流量防护、调用治理、可观测闭环。

中间件层解决了系统的“稳”与“快”，但支撑整个架构最底层、最核心的命脉，始终是数据。

大宗商品销采运储系统，从采购开单、入库出库、物流发运，到财务对账、结算，每天产生海量单据。所有流转的业务动作，最终都要落盘。

如果中间件是高速公路，数据持久层就是承载一切的地基。地基不稳，上面修得再漂亮，也经不起海量数据和高并发的冲击。

由此，我们进入六层架构的新篇章：数据持久层（事务存储层）。

一句话定调：

中间件层决定系统“跑得多快”，数据持久层决定系统“活得多长”。数据持久层不承载业务逻辑，只承载数据落地、隔离、性能与强一致性。

一、数据持久层在六层架构中的定位

先回顾我们的六层架构：

text

展示层 → 统一网关 → 业务服务层（采购/销售/仓储/运输） → 基础服务层（用户/日志/接口/调度/报表） → 公共中间件层（注册/配置/MQ/Redis/可观测） → 【数据持久层】（当前篇章）

边界与职责

• 对上：为业务服务、基础服务、中间件提供可靠的数据存储和事务支撑；

• 对下：直面物理硬件、磁盘 IO、网络带宽，负责数据落盘。

一句话区分：中间件解决“请求怎么通”，持久层解决“数据怎么存得对、找得快”。

二、大宗商品业务的数据特征盘点

为什么大宗商品系统的数据库特别难搞？因为它的数据特征极度复杂：

1. 单据巨大，主子表强关联

一张销售订单（主表）可能带很多条明细（子表），一次采购入库可能涉及多个仓库、多个批次。主子表必须强一致，不能出现“有头无尾”。

2. 金额敏感，强一致性要求极高

涉及货款、运费、保证金、结算金额，数据库的任何一次丢数据、并发超卖、脏读，都会引发真实的资金损失和法律纠纷。

3. 状态流转复杂，读写比例失衡

单据的生命周期长（待审核→已确认→部分出库→已完结→已作废）。白天高频“写”（开单）+ 高频“读”（查状态），夜间高频“批量读写”（对账、结账）。

4. 历史数据庞大，冷热差异巨大

几年前的运单、出库单几乎没人查，但受合规和审计要求不能删除。这些历史数据占用了大量磁盘和缓存，严重拖慢索引性能。

这就决定了：大宗商品的数据库不能只用一个 MySQL 单机跑到底。必须随着业务增长，进行架构演进。

三、数据持久层全景架构演进

如果画成一张总架构图，数据持久层的演进大致如下：

text

┌─────────────────────────────────────────────────────┐ │ 业务服务 / 基础服务 │ └─────────────────────────────────────────────────────┘ │ ┌─────────────────────────────────────────────────────┐ │ 数据访问层（ORM / DAO） │ │ MyBatis / JPA / 多数据源路由 / 读写分离代理 │ └─────────────────────────────────────────────────────┘ │ ┌─────────────────────────────────────────────────────┐ │ 数据存储与治理层 │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌───────────┐ │ │ │ 事务库 │ │ 只读/报表库 │ │ 冷数据 │ │ │ │ (MySQL集群) │ │ (主从/分片) │ │ 归档库 │ │ │ └──────────────┘ └──────────────┘ └───────────┘ │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌───────────┐ │ │ │ 分布式事务 │ │ 检索引擎 │ │ 数仓/湖 │ │ │ │ (Seata/MQ) │ │ (ES / 异构) │ │ (离线分析)│ │ │ └──────────────┘ └──────────────┘ └───────────┘ │ └─────────────────────────────────────────────────────┘ │ ┌─────────────────────────────────────────────────────┐ │ 底层物理设施（磁盘/云盘） │ └─────────────────────────────────────────────────────┘

演进路径（本项目规划）

1. 初期：单机 MySQL，一主一从。

2. 中期：读写分离 + 缓存兜底（配合 Redis），解决读多写少瓶颈。

3. 爆发期：分库分表 + 分布式主键，解决千万级大表单库瓶颈。

4. 成熟期：分布式事务（跨库单据流转）+ 冷热分离（历史数据归档）+ 异构索引（ES 复杂检索）。

四、国产化落地选型原则

大宗商品行业（尤其涉及国企、央企、大宗供应链）项目，必须满足信创合规要求。数据持久层选型遵循 4 条核心原则：

1. 生态兼容优先

SQL 标准兼容度高，现有代码（基于 MyBatis 等）迁移成本低。MySQL 协议兼容是首选条件。

2. 高可用与强一致

支持主从复制、多副本、故障自动切换。对于财务对账、库存扣减，强一致优先于高可用。

3. 分库分表与海量数据支撑

需具备原生分布式架构能力，或者能够完美适配 ShardingSphere 等分库分表中间件。

4. 国产化适配（非必须）

支持国产 CPU（鲲鹏/飞腾）、国产 OS（麒麟/统信）、国产开源生态。

本项目选型参考：

五、本篇小结

数据持久层是整个销采运储系统中最容不得半点闪失的一环。中间件挂了可以降级重试，缓存挂了可以穿透查库，但数据库如果数据乱了、丢了、表锁死了，业务就彻底瘫痪了。

记住三句话：

1. 数据层不承载业务逻辑，只管数据落得下、找得快、保得住。

2. 大宗商品数据的复杂性，决定了它必须从单机走向集群、分片与冷热分离。

3. 国产化选型不是技术问题，而是企业战略与合规底线。

下篇预告：我们进入数据持久层第一个实战架构：读写分离架构，拆解“为什么单机 MySQL 扛不住大宗商品的开单潮”，详解读写分离的实现方案、从库延迟导致的“刚开单查不到”灾难，以及生产环境如何通过强制路由、半同步复制、缓存兜底来治理主从延迟。