车间 aoi 的相机图片上传，用飞牛 nas，群晖 nas，高并发，按 5TB / 天、60 天、500 台设备，能不能抗住？如果我在一台服务器放多个 ftp 服务，每条线一个 ftp 服务，端口 8001，第二条线 ftp 服务，端口 8002。ftp 靠谱还 nas 靠谱？稳定，生成环境
⚠️ 先修正：MinIO 社区版已经死了
我上一轮推荐了 MinIO，但按最新状态，这条路已经走不通了。官方仓库页面原文是：
“This repository was archived by the owner on Apr 25, 2026. It is now read-only.”
“The MinIO community edition is now distributed as source code only… Production environments using compiled-from-source MinIO binaries do so at their own risk.”
它不是一个突然的决定，而是前后 11 个月的逐步收缩：
| 时间 | 发生了什么 |
|---|---|
| 2021-05 | Apache 2.0 → AGPLv3 |
| 2025-05 | 社区版移除管理控制台（Bucket 策略、用户管理、生命周期改为 CLI-only 或付费版） |
| 2025-10-15 | 最后一个功能发布（CVE 补丁）；随后停止预编译二进制和 Docker 镜像 |
| 2025-12 | 转入 maintenance mode |
| 2026-02 | README 改为 “no longer maintained” |
| 2026-04-25 | 仓库正式归档，只读 |
最关键的一行：官方给出的去向是 AIStor Free（单机）和 AIStor Enterprise（分布式，商业授权）。也就是说——“自建一个免费 MinIO 生产集群”这条路，官方已经不再提供支撑了。
存量集群还能跑（数据不会消失），但你继承了一条没人上游盯着的发布流水线，下一个 CVE 要靠自己找、自己补、自己编。对一个要跑 500 台设备、60 天滚动留存的车间来说，这个风险不可接受。
一、分布式方案全景
我把它们按”对你这个场景的适配度“分四档，而不是按名气排。
第一档：分布式对象存储（你的场景正解）
| 方案 | 协议 | 冗余 | 授权 | 适配度 | 备注 |
|---|---|---|---|---|---|
| SeaweedFS | S3 + FUSE挂载 | 纠删码/副本 | Apache 2.0 | ★★★★★ | 首选。源自 Facebook Haystack 论文，元数据分散到卷服务器，O(1) 磁盘寻址，专为海量小文件设计 |
| RustFS | S3 | 纠删码 | Apache 2.0 | ★★★☆ | 定位接近 MinIO，但较新，建议列入中长期储备 |
| Garage | S3 | 全复制 | AGPLv3 | ★★★ | 单二进制、极简、活跃维护；但全复制意味着 3 节点就用 3 倍磁盘，300TB 有效要 900TB 裸，容量账不划算 |
| Ceph RGW | S3/Swift/RBD/CephFS | 副本/纠删码 | LGPL | ★★★ | 功能最全、PB 级验证充分，但组件多（MON/OSD/MGR/RGW/MDS），需要专职存储团队 |
| FastDFS | 私有 API | 多副本 | Apache 2.0 | ★★☆ | 国产老牌、图片场景积累多；但生态封闭、最终一致、功能单一 |
| ~~MinIO CE~~ | S3 | 纠删码 | AGPLv3 | ✕ | 已归档，新部署避坑 |
为什么 SeaweedFS 最贴你的场景：你的数据模型是”几十亿级小文件 + 高并发写 + 按时间批量过期”，这正是 Haystack 架构要解决的原问题。对比之下 HDFS 的小文件会压垮 NameNode，GlusterFS 大目录遍历成本高，Ceph 是”能力过剩 + 运维过重”的组合。
如果已有 MinIO 存量集群不想动，社区 fork（pgsty/minio）恢复了控制台和二进制，但明确只做 CVE 补丁和 bugfix、不开发新功能——短期续命可以，长期还是要规划迁出。
第二档：分布式文件系统（一般不建议）
CephFS、GlusterFS、HDFS、Lustre/GPFS。共同特点是提供 POSIX 语义，能直接挂成目录——听起来很诱人（AOI 软件不用改，直接写网络盘）。但：
- 小文件元数据开销是通用痛点点
- 挂载语义本身就是生产风险：hard 挂载在网络闪断时进程进 D 状态卡死，直接拖停产线（上一轮说过）
只在一种情况下考虑：AOI 软件完全不可改造、只能写网络盘。那宁可选 CephFS 也不要选 SMB/NFS 单点挂载——至少元数据是分布式的。
第三档：公有云对象存储托管（省心但贵）
腾讯云 COS / 阿里云 OSS / 华为云 OBS，都是 S3 兼容、单桶无容量上限、有生命周期自动过期。
成本账（按 300TB 有效、60 天滚动）：
| 存储类型 | 单价（元/GB/月） | 300TB/月 | 年成本 |
|---|---|---|---|
| 标准存储 | COS 0.118 / OSS 0.12 | 约 3.6 万元 | 约 43 万 |
| 低频访问 | 约 0.059–0.06 | 约 1.8 万元 | 约 22 万 |
| 归档 | 约 0.012–0.03 | 0.4–0.9 万元 | 5–11 万 |
请求费基本可忽略（PUT 约 0.01 元/万次，一天 250 万张图也就几十块）。真正的大头是带宽：
- 5TB/天走公网，需要持续 58 MB/s 上行、峰值 300+ MB/s
- 工厂普通宽带是”侧重下行”的模型，上行先跑满；工业专线才上下行对称、有 SLA
- 参考量级：50Mbps 工业专线年费约 4–8 万，你要的规格远不止 50Mbps
上云的真正门槛不是钱，是”数据能不能出厂”。
第四档：伪分布式（要避坑）
- 多台独立 NAS + rsync 定时同步 —— 无一致性保证，故障切换靠人
- 一台服务器开 N 个 FTP 端口（你上一轮提的方案）—— 端口数 ≠ 并发数，所有实例仍抢同一块阵列的 IO，被动模式还要放行 N 段高端口
二、百度网盘为什么真的不靠谱
不是”体验差”这种软理由，是硬数字直接把你排除在外。
1. 速度：物理上不可能
百度网盘企业版官方知识库自己写的：
“百度网盘免费用户上传速度通常限制在 100KB/s 至 300KB/s 左右…超级会员上传速度理论可达数十 MB/s，实际受文件大小、网络状况及服务器负载影响，不承诺固定值。”
你的需求是持续 58 MB/s、全天 24 小时不断。网盘连超级会员都不承诺固定速度，更别说峰值之外的持续吞吐。差了两个数量级。
2. API 限流：500 台设备直接撞墙
这条最致命，也是很多人想不到的：
“百度网盘企业版 API 对每个接口都有频率限制。比如文件上传接口每秒最多 10 次，列表操作每秒 20 次，超出后会返回 429 错误…如果你的业务有高并发需求（比如几千人同时上传），就需要提前评估一下。”
算一笔账：假设单图 2MB，一天 250 万张 → 平均每秒 29 次上传请求，峰值轻松上百次。限流阈值是 10 次/秒。你连白天均值的零头都过不去。
就算把图片打包成小时级 tar 包降低请求数到每秒几次，你还得面对：单文件上限 20GB、上传只能进”我的应用数据”目录、无版本控制保障、删除后无法找回。
3. 合规：等保直接判不通过
等保测评的高风险项里有一条写得很直白：
“重要数据、源代码等如果备份到互联网网盘、代码托管平台等不可控环境的话，也将会无法通过等保测评。”
AOI 质检图片不是普通文档——它是质量追溯数据，很多主机厂/医疗/军工供应链在合同里就明令禁止出厂。国安也公开发文警示过云存储泄密风险，明确”严禁涉密信息上网”。
这一条是一票否决，跟技术无关。
4. 工程上根本接不进去
- 500 台工控机：要么开 500 个账号，要么共享一个账号（密码写死在 500 台机器上）
- 无 S3/POSIX 接口，AI 复检、MES 追溯、缺陷检索全都对接不了
- 无审计日志导出能力，等保要求的”操作留痕”给不出来
- 无 SLA、无企业级支持承诺
那百度系就完全不能用吗？——要区分两个产品
百度网盘 ≠ 百度智能云 BOS。 后者是真正的对象存储：
- 单 Bucket 公网带宽阈值 10 Gbit/s、内网 50 Gbit/s
- 单文件最大 48.8TB，支持分块上传（分片 100KB–5GB）
- S3 兼容 SDK、有生命周期规则、有 IAM
BOS 在能力上是够的，它跟 COS/OSS 是同一类东西。所以问题从来不是”百度靠不靠谱”，而是”网盘和对象存储是两种完全不同的产品，车间生产数据只能进后者“。
顺带说清网盘的适用边界：非核心、低频、小数据量（比如把月度质检报表导出一份给客户临时分享）可以用；产线原始数据流一律不行。
三、给你的决策路径
纯文本第一步：问甲方/客户合同 —— 质检图片能否出厂？
│
├── 不允许（大概率）→ 必须自建机房
│ └─ SeaweedFS 集群（4–6 节点）+ 工控机本地 SSD 缓冲
│
└── 允许 → 第二步
│
第二步：看单图大小
│
├── < 5MB（文件数上亿）→ 强烈建议自建
│ 边缘打包 + SeaweedFS，云上按对象计费不划算
│
└── > 20MB（文件数千万级）→ 云对象存储可行
需先解决：厂区上行专线 + 生命周期分层
自建配置参考（SeaweedFS，覆盖 300TB 有效 + 冗余 + 增长余量）：
| 项 | 配置 |
|---|---|
| 节点 | 4–6 台，每台 12 盘位 |
| 数据盘 | 16–20TB 企业级 HDD，数据盘用 XFS，盘前不再做 RAID |
| 有效容量 | 6 节点 × 12 盘 × 16TB = 1.15PB 裸，EC 8+2 → 约 860TB 有效 |
| 网络 | 节点间 25G，接入层双万兆 |
| 元数据 | volume server 与 master 分离，master 做 3 副本 |
| 工控机侧 | 本地 SSD 缓存 1–2 天，断网不停产，恢复后补传 |
| 写入方式 | HTTP PUT / S3 SDK 直传；写 .tmp → 校验 MD5 → rename 原子落盘 |
分片上传的经验参数：公网 5–10MB/片、并发 3–5 路是甜区；分片太小请求开销吃掉收益，太大单分片失败成本回升。记得给未完成的上传会话设过期清理（比如 7 天），否则碎片会悄悄吃掉容量。
还差两个数就能定稿
- 甲方合同/等保要求里，质检图片是否允许出厂（决定自建还是上云，这是一票否决项）
- 单张图片平均大小（决定文件数、要不要边缘打包、选 SeaweedFS 还是通用对象存储）
另外顺带确认一下：你上一轮提到的”5TB/天”是全天 24 小时均值，还是单班 8 小时内的量？ 这决定网卡规格和写入突发系数——同样 5TB，摊到 24 小时只要 58MB/s，压在 8 小时就是 174MB/s，峰值差三倍。
