1.2 桶、对象与纠删集：核心术语拆解

1.2 桶、对象与纠删集：核心术语拆解

本节摘要：桶是对象的名字空间与管理单元，对象是"键 + 数据 + 元数据"的三位一体，纠删集是数据分片实际落盘的磁盘编队。这三个术语构成 MinIO 全部日常操作的地基，本节用一条真实命令会话把它们逐个对上号。

先把术语摆上台面

第 1 章的选型会上，CTO 听完方案汇报后问了一个问题："你们说的桶，和文件夹有什么区别？"汇报的人卡了壳。这个问题答不好，后面的容量规划、权限设计全会走样——所以本节先不谈怎么部署，专门把词掰正。以下对照表是全书的术语基准，后面章节不再重复定义。

桶：扁平世界里唯一的管理单元

桶是 S3 语义里的顶层容器，名字全局唯一（在 MinIO 里是集群内唯一）。权限策略、版本控制、生命周期规则、事件通知，全部挂在桶上——你无法给"半个桶"单独开版本控制，也无法绕过桶策略直接给某个对象设 ACL 之外的花样（MinIO 支持的对象级控制比 AWS S3 更收敛，这是有意的取舍）。桶内是绝对的扁平空间，你看到的所有"目录"都只是键名里的字符串前缀。

用客户端工具连上集群，能最直观地感受这套语义。以下会话里，mc 是 MinIO 官方命令行工具，myminio 是本地配置好的集群别名：

# 列出集群中的桶
$ mc ls myminio
[2026-03-12 09:14:22 CST]     0B courseware/
[2026-03-18 17:41:03 CST]     0B backup-veeam/

# 带斜杠前缀"创建目录"——实际只是写入了一个 0 字节、键名为 courseware/ 的对象
$ mc cp logo.png myminio/courseware/chapter01/
/home/ops/logo.png ->  myminio/courseware/chapter01/logo.png

# 查看这个对象的元数据：注意键的完整形态，斜杠是键的一部分
$ mc stat myminio/courseware/chapter01/logo.png
Name      : logo.png
Size      : 48.2 KiB
ETag      : d41d8cd98f00b204e9800998ecf8427e
Metadata  :
  Content-Type : image/png
​

看懂这个会话，就理解了对象存储一半的脾气：所谓"目录 chapter01"从未真实存在，mc cp 命令末尾那个斜杠只是让客户端把键名拼成 chapter01/logo.png。删除 chapter01/ 这个"目录"，删的只是那个 0 字节占位对象，chapter01/logo.png 原封不动。

对象：键、数据与元数据的三位一体

一个对象由四部分组成：键（最长可达 1024 字节的 UTF-8 字符串）、数据本体（从 0 字节到 5 TB）、系统元数据（大小、ETag 校验值、修改时间）、用户元数据（键值对形式的自定义标签）。写一次之后，数据与元数据就绑定为不可变整体——你不能修改对象的一部分，只能整体替换或删除。这是它与文件系统最深的分野：文件可以 seek 到中间改几个字节，对象永远整存整取。

不可变性还派生出一个行为差异：对已有键再次 PUT,得到的是一个新版本（若桶开了版本控制）或一次静默覆盖（未开启时）。很多"数据丢了"的工单，最后查出来都是后者——没人开版本控制，覆盖无从追溯。版本控制的正确姿势是第 5 章的主题，此处先埋个种子。

纠删集：数据真正居住的地方

前两个术语是逻辑层的，纠删集是物理层的。MinIO 把集群里固定数量的磁盘（通常 8 到 16 块）编成一个纠删集，每个对象写入时被切分成数据分片与校验分片，散布在同一纠删集的各块盘上。对象落在哪个纠删集，由对象键经哈希决定——这是确定性的：同一个键永远落到同一个纠删集，这也是对象存储能做强一致读的前提之一。

图 1-2 一次对象写入在集群中的落位

两个推论值得现在就记下。其一，纠删集大小在建仓时锁定，之后加盘加节点都是新增纠删集或新增 Server Pool，已写入的对象不会重新分片——扩容模型因此是"加仓库"而不是"搬货物"。其二，元数据跟着分片一起走纠删码保护，没有独立的元数据服务器可挂，也没有元数据备份要单独操心，这是 MinIO 无主架构能立住的关键。

Server Pool 与集群的层次

把视角再拉高一层：若干节点与它们的盘组成一个 Server Pool（服务池），一个集群可以有一个或多个池。写请求按池的剩余空间与权重分发，读请求按对象所在位置直达。池与池之间数据互不搬移——"池 A 满了自动匀给池 B"这种事不存在，容量规划必须在建池时算清，或者及时加池。这个模型简单、可预期，代价是规划责任前移给了你，第 4 章的扩容复盘会专门消化它。

FAQ：新人最常踩的三个术语坑

桶名可以后期改吗？

不能。桶名是对象寻址的一部分，改名等于全量搬迁。上线前把桶命名规范定好（比如"业务线-环境-用途"三段式），比事后改名便宜一百倍。

一个集群最多多少对象？

MinIO 的元数据设计没有硬编码的总量上限，生产环境里百亿对象规模的集群并不罕见。真正的瓶颈通常先出现在网络与纠删集的并行度上，而不是"对象数上限"。

纠删集数量怎么算？

集群总盘数除以单个纠删集的盘数。例如 4 节点每节点 4 盘共 16 盘，纠删集大小设 16 就是 1 个大集；设 8 就是 2 个集。集越大冗余调度空间越大，但故障恢复时牵动的盘也越多——这个权衡第 2 章部署时要用到。

本节要点回顾

• 桶是管理单元：策略、版本、生命周期全挂桶上；桶内扁平，目录只是键名前缀的视觉假象。
• 对象不可变：整存整取，没有局部改写；覆盖写要么产生新版本要么无声吞掉旧数据。
• 纠删集是物理编队：键哈希定集、分片打散落盘，元数据与数据同受纠删码保护。
• Server Pool 是扩容单元：池间数据不自动搬移，容量规划的责任在设计时就属于你。

术语在手，1.3 回到那场选型会，把 MinIO、Ceph、公有云 OSS 三张底牌摊开来比。