大宗商品销采运储系统・六层架构连载数据持久层前面我们完成了公共中间件层的完整底座搭建服务发现、动态配置、消息通信、缓存加速、流量防护、调用治理、可观测闭环。中间件层解决了系统的“稳”与“快”但支撑整个架构最底层、最核心的命脉始终是数据。大宗商品销采运储系统从采购开单、入库出库、物流发运到财务对账、结算每天产生海量单据。所有流转的业务动作最终都要落盘。如果中间件是高速公路数据持久层就是承载一切的地基。地基不稳上面修得再漂亮也经不起海量数据和高并发的冲击。由此我们进入六层架构的新篇章数据持久层事务存储层。一句话定调中间件层决定系统“跑得多快”数据持久层决定系统“活得多长”。数据持久层不承载业务逻辑只承载数据落地、隔离、性能与强一致性。一、数据持久层在六层架构中的定位先回顾我们的六层架构text展示层 → 统一网关 → 业务服务层采购/销售/仓储/运输 → 基础服务层用户/日志/接口/调度/报表 → 公共中间件层注册/配置/MQ/Redis/可观测 → 【数据持久层】当前篇章边界与职责对上为业务服务、基础服务、中间件提供可靠的数据存储和事务支撑对下直面物理硬件、磁盘 IO、网络带宽负责数据落盘。维度公共中间件层数据持久层核心目标分布式通信与高可用防护数据存储、检索、事务与一致性典型组件Nacos、RocketMQ、Redis、SentinelMySQL、分库分表中间件、ES、数仓故障表现服务调不通、流量被打崩数据丢失、主从延迟、锁死、慢查雪崩数据特征易失性缓存、暂存性消息持久化、强一致性、不可篡改一句话区分中间件解决“请求怎么通”持久层解决“数据怎么存得对、找得快”。二、大宗商品业务的数据特征盘点为什么大宗商品系统的数据库特别难搞因为它的数据特征极度复杂1. 单据巨大主子表强关联一张销售订单主表可能带很多条明细子表一次采购入库可能涉及多个仓库、多个批次。主子表必须强一致不能出现“有头无尾”。2. 金额敏感强一致性要求极高涉及货款、运费、保证金、结算金额数据库的任何一次丢数据、并发超卖、脏读都会引发真实的资金损失和法律纠纷。3. 状态流转复杂读写比例失衡单据的生命周期长待审核→已确认→部分出库→已完结→已作废。白天高频“写”开单 高频“读”查状态夜间高频“批量读写”对账、结账。4. 历史数据庞大冷热差异巨大几年前的运单、出库单几乎没人查但受合规和审计要求不能删除。这些历史数据占用了大量磁盘和缓存严重拖慢索引性能。这就决定了大宗商品的数据库不能只用一个 MySQL 单机跑到底。必须随着业务增长进行架构演进。三、数据持久层全景架构演进如果画成一张总架构图数据持久层的演进大致如下text┌─────────────────────────────────────────────────────┐ │ 业务服务 / 基础服务 │ └─────────────────────────────────────────────────────┘ │ ┌─────────────────────────────────────────────────────┐ │ 数据访问层ORM / DAO │ │ MyBatis / JPA / 多数据源路由 / 读写分离代理 │ └─────────────────────────────────────────────────────┘ │ ┌─────────────────────────────────────────────────────┐ │ 数据存储与治理层 │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌───────────┐ │ │ │ 事务库 │ │ 只读/报表库 │ │ 冷数据 │ │ │ │ (MySQL集群) │ │ (主从/分片) │ │ 归档库 │ │ │ └──────────────┘ └──────────────┘ └───────────┘ │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌───────────┐ │ │ │ 分布式事务 │ │ 检索引擎 │ │ 数仓/湖 │ │ │ │ (Seata/MQ) │ │ (ES / 异构) │ │ (离线分析)│ │ │ └──────────────┘ └──────────────┘ └───────────┘ │ └─────────────────────────────────────────────────────┘ │ ┌─────────────────────────────────────────────────────┐ │ 底层物理设施磁盘/云盘 │ └─────────────────────────────────────────────────────┘演进路径本项目规划初期单机 MySQL一主一从。中期读写分离 缓存兜底配合 Redis解决读多写少瓶颈。爆发期分库分表 分布式主键解决千万级大表单库瓶颈。成熟期分布式事务跨库单据流转 冷热分离历史数据归档 异构索引ES 复杂检索。四、国产化落地选型原则大宗商品行业尤其涉及国企、央企、大宗供应链项目必须满足信创合规要求。数据持久层选型遵循 4 条核心原则1. 生态兼容优先SQL 标准兼容度高现有代码基于 MyBatis 等迁移成本低。MySQL 协议兼容是首选条件。2. 高可用与强一致支持主从复制、多副本、故障自动切换。对于财务对账、库存扣减强一致优先于高可用。3. 分库分表与海量数据支撑需具备原生分布式架构能力或者能够完美适配 ShardingSphere 等分库分表中间件。4. 国产化适配非必须支持国产 CPU鲲鹏/飞腾、国产 OS麒麟/统信、国产开源生态。本项目选型参考选型适用场景说明MySQL 8.0核心业务主库生态最好搭配 ShardingSphere 解决分片主流选择达梦 DM8信创强要求场景国产化替代首选高度兼容 Oracle需注意与 MySQL 语法差异OceanBase / TiDB金融级/超大规模原生分布式强一致适合对扩展性要求极高的核心表Elasticsearch单据检索、多条件查询不存主数据做异构索引解决分库分表后的复杂查询五、本篇小结数据持久层是整个销采运储系统中最容不得半点闪失的一环。中间件挂了可以降级重试缓存挂了可以穿透查库但数据库如果数据乱了、丢了、表锁死了业务就彻底瘫痪了。记住三句话数据层不承载业务逻辑只管数据落得下、找得快、保得住。大宗商品数据的复杂性决定了它必须从单机走向集群、分片与冷热分离。国产化选型不是技术问题而是企业战略与合规底线。下篇预告我们进入数据持久层第一个实战架构读写分离架构拆解“为什么单机 MySQL 扛不住大宗商品的开单潮”详解读写分离的实现方案、从库延迟导致的“刚开单查不到”灾难以及生产环境如何通过强制路由、半同步复制、缓存兜底来治理主从延迟。 
长河君 · 2026/10/21 2:35:25 · 阅读 1.2k 微服务架构落地：数据持久层 —— 从单机瓶颈到海量数据
大宗商品销采运储系统・六层架构连载数据持久层前面我们完成了公共中间件层的完整底座搭建服务发现、动态配置、消息通信、缓存加速、流量防护、调用治理、可观测闭环。中间件层解决了系统的“稳”与“快”但支撑整个架构最底层、最核心的命脉始终是数据。大宗商品销采运储系统从采购开单、入库出库、物流发运到财务对账、结算每天产生海量单据。所有流转的业务动作最终都要落盘。如果中间件是高速公路数据持久层就是承载一切的地基。地基不稳上面修得再漂亮也经不起海量数据和高并发的冲击。由此我们进入六层架构的新篇章数据持久层事务存储层。一句话定调中间件层决定系统“跑得多快”数据持久层决定系统“活得多长”。数据持久层不承载业务逻辑只承载数据落地、隔离、性能与强一致性。一、数据持久层在六层架构中的定位先回顾我们的六层架构text展示层 → 统一网关 → 业务服务层采购/销售/仓储/运输 → 基础服务层用户/日志/接口/调度/报表 → 公共中间件层注册/配置/MQ/Redis/可观测 → 【数据持久层】当前篇章边界与职责对上为业务服务、基础服务、中间件提供可靠的数据存储和事务支撑对下直面物理硬件、磁盘 IO、网络带宽负责数据落盘。维度公共中间件层数据持久层核心目标分布式通信与高可用防护数据存储、检索、事务与一致性典型组件Nacos、RocketMQ、Redis、SentinelMySQL、分库分表中间件、ES、数仓故障表现服务调不通、流量被打崩数据丢失、主从延迟、锁死、慢查雪崩数据特征易失性缓存、暂存性消息持久化、强一致性、不可篡改一句话区分中间件解决“请求怎么通”持久层解决“数据怎么存得对、找得快”。二、大宗商品业务的数据特征盘点为什么大宗商品系统的数据库特别难搞因为它的数据特征极度复杂1. 单据巨大主子表强关联一张销售订单主表可能带很多条明细子表一次采购入库可能涉及多个仓库、多个批次。主子表必须强一致不能出现“有头无尾”。2. 金额敏感强一致性要求极高涉及货款、运费、保证金、结算金额数据库的任何一次丢数据、并发超卖、脏读都会引发真实的资金损失和法律纠纷。3. 状态流转复杂读写比例失衡单据的生命周期长待审核→已确认→部分出库→已完结→已作废。白天高频“写”开单 高频“读”查状态夜间高频“批量读写”对账、结账。4. 历史数据庞大冷热差异巨大几年前的运单、出库单几乎没人查但受合规和审计要求不能删除。这些历史数据占用了大量磁盘和缓存严重拖慢索引性能。这就决定了大宗商品的数据库不能只用一个 MySQL 单机跑到底。必须随着业务增长进行架构演进。三、数据持久层全景架构演进如果画成一张总架构图数据持久层的演进大致如下text┌─────────────────────────────────────────────────────┐ │ 业务服务 / 基础服务 │ └─────────────────────────────────────────────────────┘ │ ┌─────────────────────────────────────────────────────┐ │ 数据访问层ORM / DAO │ │ MyBatis / JPA / 多数据源路由 / 读写分离代理 │ └─────────────────────────────────────────────────────┘ │ ┌─────────────────────────────────────────────────────┐ │ 数据存储与治理层 │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌───────────┐ │ │ │ 事务库 │ │ 只读/报表库 │ │ 冷数据 │ │ │ │ (MySQL集群) │ │ (主从/分片) │ │ 归档库 │ │ │ └──────────────┘ └──────────────┘ └───────────┘ │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌───────────┐ │ │ │ 分布式事务 │ │ 检索引擎 │ │ 数仓/湖 │ │ │ │ (Seata/MQ) │ │ (ES / 异构) │ │ (离线分析)│ │ │ └──────────────┘ └──────────────┘ └───────────┘ │ └─────────────────────────────────────────────────────┘ │ ┌─────────────────────────────────────────────────────┐ │ 底层物理设施磁盘/云盘 │ └─────────────────────────────────────────────────────┘演进路径本项目规划初期单机 MySQL一主一从。中期读写分离 缓存兜底配合 Redis解决读多写少瓶颈。爆发期分库分表 分布式主键解决千万级大表单库瓶颈。成熟期分布式事务跨库单据流转 冷热分离历史数据归档 异构索引ES 复杂检索。四、国产化落地选型原则大宗商品行业尤其涉及国企、央企、大宗供应链项目必须满足信创合规要求。数据持久层选型遵循 4 条核心原则1. 生态兼容优先SQL 标准兼容度高现有代码基于 MyBatis 等迁移成本低。MySQL 协议兼容是首选条件。2. 高可用与强一致支持主从复制、多副本、故障自动切换。对于财务对账、库存扣减强一致优先于高可用。3. 分库分表与海量数据支撑需具备原生分布式架构能力或者能够完美适配 ShardingSphere 等分库分表中间件。4. 国产化适配非必须支持国产 CPU鲲鹏/飞腾、国产 OS麒麟/统信、国产开源生态。本项目选型参考选型适用场景说明MySQL 8.0核心业务主库生态最好搭配 ShardingSphere 解决分片主流选择达梦 DM8信创强要求场景国产化替代首选高度兼容 Oracle需注意与 MySQL 语法差异OceanBase / TiDB金融级/超大规模原生分布式强一致适合对扩展性要求极高的核心表Elasticsearch单据检索、多条件查询不存主数据做异构索引解决分库分表后的复杂查询五、本篇小结数据持久层是整个销采运储系统中最容不得半点闪失的一环。中间件挂了可以降级重试缓存挂了可以穿透查库但数据库如果数据乱了、丢了、表锁死了业务就彻底瘫痪了。记住三句话数据层不承载业务逻辑只管数据落得下、找得快、保得住。大宗商品数据的复杂性决定了它必须从单机走向集群、分片与冷热分离。国产化选型不是技术问题而是企业战略与合规底线。下篇预告我们进入数据持久层第一个实战架构读写分离架构拆解“为什么单机 MySQL 扛不住大宗商品的开单潮”详解读写分离的实现方案、从库延迟导致的“刚开单查不到”灾难以及生产环境如何通过强制路由、半同步复制、缓存兜底来治理主从延迟。