一、先算清楚你的并发与写入量级

100 产线 × 30 工站 = 3000 个终端同时在线

每个工站操作：过站采集、扫码、不良录入、设备参数上报，分两类数据流：

1. 低频业务事务：员工扫码过站、提交不良、绑定工单，单工站每分钟几笔，全系统 QPS 几百；
2. 高频时序采集：设备工艺参数、节拍、电压温度，秒级 / 5 秒上报一条，3000 终端持续写入。

这个压力在内网系统里算中大规模，但和懂x帝公网百万并发、热点瞬间流量翻百倍有本质区别：

• MES 流量平稳可控、内网低延迟、无爬虫 / 突发洪峰；
• 懂x帝随时一条爆款视频带来几十万瞬时读写，流量不可预测； 所以不需要懂x帝多套分片 MySQL、流量回放、CC 防护，但分层、预发、冷热分离、时序剥离这套核心思想 100% 能用。

二、传统 MES 踩的致命坑（你大概率会遇到）

1. 所有采集、过站记录塞一张大表，运行 1 年千万行，报表查询、扩字段直接锁表，全厂工站页面卡死；
2. 开发改表、加采集字段直接在线执行，白天生产高峰期触发长锁，3000 工站全部阻塞；
3. 实时看板、产量统计反复全表扫描，数据库 CPU 长期打满；
4. 工艺图片、质检附件和业务库混存，测试上传垃圾文件污染正式资源。

三、把懂x帝整套架构逻辑平移改造适配 3000 工站 MES

1. 双环境隔离：mes（生产） + mes-lf（预发测试），解决改表卡死产线

内网 DNS 两套解析，两套独立 MySQL、独立文件存储：

• mes.inner.com：100 条产线 3000 工站日常使用；
• mes-lf.inner.com：仅 IT / 工艺工程师 IP 白名单访问，普通工站看不到。

标准工作流（复刻懂x帝发布流程）：

1. 在 lf 预发搭建和生产一致的数据规模：每晚自动同步全量生产采集数据；
2. 新增工站采集点位、扩数据库字段、新增报表，全部在 lf 完成； 同时模拟 3000 工站并发写入，测试 ALTER 是否锁表、查询是否超时；
3. 验证无风险，凌晨低峰在线执行变更；复杂大表变更用分批回填，避免锁表；
4. 质检图片、工艺文档先上传 lf 存储目录，测试预览正常，一键同步到生产存储。

核心价值：任何变更风险全部前置拦截，绝不影响车间生产。

2. 数据库分层拆分，彻底解决海量工站采集大表问题

分层 1：业务 MySQL（工单、人员、工艺、基础配置）

数据量小、强事务，单库单实例足够，不用分片。

分层 2：生产过站、产量记录表 → 按月分表（替代互联网水平分片）

表名 station_record_202606、station_record_202607

适配 MES 时序增长特性：

1. 每月一张独立表，单表行数可控，索引体积小，日报 / 月报只查当月表，速度极快；
2. 新增采集字段仅修改当月空表，历史归档表不改动，变更风险极小；
3. 上月之前冷数据可归档压缩，移出在线业务库，不占用缓冲池。

分层 3：高频设备参数采集，完全剥离 MySQL，用时序库 TDengine 承载（对标懂x帝 ClickHouse）

每个工站 30 个参数、秒级上报，这类流水数据不进 MySQL：

1. PLC / 工站客户端上报数据写入本地 MQ，落地 TDengine；
2. MySQL 只存汇总统计结果：单产线小时产量、不良率，车间实时看板读汇总数据；
3. 原始毫秒级工艺参数仅用于品质追溯，需要时单独查询时序库，完全不挤占业务数据库性能。

这一步直接削减 MySQL 70% 写入压力，3000 工站同时上报也不会打满数据库 IO。

3. Redis 缓存层，降低 3000 工站并发查询压力（复用懂x帝缓存思路）

车间所有高频展示数据全部缓存：

• 当前产线实时产量、不良 TOP、工站在线状态、工单进度； 工人刷新页面、看板轮询 90% 请求命中 Redis，不会频繁扫描千万行过站大表。

4. 文件存储双目录隔离（懂x帝视频存储逻辑）

同一台存储 / NAS 划分两套目录：

• lf-file/：预发环境上传测试质检照片、SOP 文档；
• prod-file/：正式生产附件； 后台同步脚本校验文件完整性后复制，两套路径 URL 区分，测试垃圾文件不会混入正式资料。

四、为什么不用照搬懂x帝重型分布式组件？

1. 内网 3000 终端并发平稳，不存在公网瞬间流量暴涨，不需要分片集群、熔断限流、流量回放；
2. 数据按月规整增长，按月分表即可控制单表体量，无需复杂哈希分片、分片扩容迁移；
3. 无海量短视频转码、CDN 分发、防盗链需求，省去一整套媒体基建；
4. 单人 / 小型 IT 团队可维护，不会出现分布式组件过多、故障点爆炸、运维负担过重问题。

五、整套架构对比传统一体化 MES 核心优势

1. 变更零生产事故：所有表结构、新功能预发全量数据 + 并发模拟验证，杜绝白天锁表卡死全部工站；
2. 数据库压力分层化解：高频设备采集丢时序库，业务 MySQL 只处理工单、过站事务；按月分表避免无限膨胀超大单表；
3. 并发访问更流畅：实时看板、产量统计走 Redis 缓存，3000 工站同时刷新无延迟；
4. 资源隔离：测试素材、测试数据和生产完全分开，不会误删正式生产资料；
5. 低成本落地：仅需两台低配服务器（生产 + 预发）+ TDengine 免费版 + Redis，中小企业预算完全承载，不用昂贵分布式集群。

总结

3000 工站同时在线、海量产量采集，数据压力确实不小，但不需要复刻懂x帝面向公网亿级用户的重型分布式架构；

只吸收它的核心设计思想：环境隔离预发验证、数据分层存储、冷热分离、缓存卸压、媒体资源双环境同步，再结合 MES 时序数据特点改用「按月分表 + TDengine 承载高频采集」轻量化改造，就能完美解决车间多工站并发、大表卡顿、改表风险等所有痛点。

200 条产线、200×30=6000 个工站终端，这套分层隔离思路直接复用，只需要轻微上调资源规格，架构逻辑一点不用改。

1、先算并发规模

6000 台工站终端分两类写入：

1. 业务操作（扫码过站、不良提交、工单绑定）：内网流量平稳，峰值 QPS 一千出头；
2. 设备工艺高频采集（秒级上报参数）：全部剥离 MySQL，交给 TDengine 时序库扛。 MySQL 只承载业务事务，压力不会爆炸。

2、整套架构完全不变，只微调硬件配置

（1）预发 + 生产双环境（mes /mes-lf）不变

依旧两套独立 MySQL、独立文件存储，所有 DDL 扩字段、新采集逻辑、报表改造全部在预发验证，模拟 6000 终端并发压测，避免白天全线卡顿。

200 产线数据量更大，预发库必须完整同步生产全量数据，不能用少量测试数据糊弄，否则测不出锁表、慢查询问题。

（2）数据分层逻辑不变

1. 工单、人员、工艺基础台账：单 MySQL 业务库；
2. 工站过站、产量记录：按月分表 station_record_202606，控制单表行数，方便冷热归档；
3. 高频设备温度 / 节拍 / 电压采集：全部进 TDengine，不污染业务 MySQL； 6000 终端持续上报，时序库天生适配海量时序写入，性能远强 MySQL。

（3）Redis 缓存不变，仅扩容内存

车间实时产量、产线状态、不良统计、工单进度全放缓存；

200 条产线看板同时轮询，大量查询直接命中 Redis，避免频繁扫描千万级生产记录表。

（4）文件存储双目录隔离不变

质检图片、SOP、检测报告分 lf 测试目录 /prod 正式目录，一键同步，测试垃圾文件不干扰生产。

3、相比 100 条产线，只需要提升 3 处硬件规格，成本增加很少

1. 生产数据库服务器：CPU 升级 6 核 16G，SSD 大容量；
2. TDengine 服务内存提升，承载 6000 终端秒级上报；
3. Redis 内存翻倍，缓存 200 条产线实时统计数据； 预发服务器配置不用同步拉满，保持低配仅做测试验证。

4、核心收益对 200 产线更重要

产线越多，停机、系统卡顿损失越大：

1. 任何字段扩容、索引新增、报表优化先在预发模拟全线压力，杜绝白天锁表，200 条产线不会集体卡死；
2. 时序采集和业务库拆分，不会因为设备海量上报拖垮车间扫码业务；
3. 按月分表 + 冷热归档，运行 3~5 年也不会出现一张超大表导致报表越跑越慢；
4. 测试、生产资源完全隔离，工艺在预发调试新采集规则，完全不影响现场生产。

一句话总结

100 条、200 条、甚至 300 条产线，底层设计思路完全通用；区别只在于服务器内存、CPU 小幅升级，架构分层、预发环境、冷热分离、时序库卸压这套核心方案不用重构。