2. 对象存储基础
2.1 对象存储与块存储/文件存储的区别
在构建分布式存储系统时，首先需要理解三种主流存储模型的本质差异。块存储、文件存储和对象存储分别对应不同的数据访问模式和适用场景。下表从多个维度进行对比：
| 对比维度 | 块存储 (Block Storage) | 文件存储 (File Storage) | 对象存储 (Object Storage) |
|---|---|---|---|
| 数据组织单元 | 固定大小的块（如 512B/4KB） | 层级目录中的文件 | 扁平命名空间中的对象 |
| 访问协议 | iSCSI、FC、NVMe-oF | NFS、SMB/CIFS | S3、Swift、HTTP/REST |
| 元数据管理 | 无独立元数据，由上层文件系统管理 | 文件系统维护目录树和属性 | 对象自带丰富自定义元数据 |
| 扩展性 | 受限于控制器和 SAN 架构 | 受限于文件系统元数据服务器 | 天然水平扩展，支持 EB 级 |
| 数据修改 | 支持随机读写小块 | 支持追加和部分修改 | 通常整体覆盖或删除，不支持随机写 |
| 典型场景 | 数据库、虚拟机磁盘 | 用户文档、共享目录 | 备份归档、大数据、云原生应用 |
核心差异总结：块存储关注"位置"（LBA），文件存储关注"路径"（目录树），对象存储关注"标识符"（UUID/Key）。对象存储通过放弃原地修改和层级目录，换取了无限扩展能力和扁平化访问效率。
下图展示了三种存储模型在数据访问路径上的本质区别：
2.2 桶(Bucket)与对象(Object)概念
对象存储的核心抽象只有两个实体：桶（Bucket）和对象（Object）。理解这两个概念是掌握 MinIO 架构的基础。
2.2.1 桶（Bucket）
- 定义：桶是对象的逻辑容器，类似于文件系统中的顶层目录，但无层级嵌套。
- 命名空间：桶名称在全局（或租户内）唯一，DNS 兼容命名规则（小写字母、数字、连字符）。
- 属性：桶可以配置版本控制、生命周期策略、加密设置、访问控制策略（Bucket Policy）。
- 数量限制：MinIO 单集群支持数百万个桶，每个桶可包含无限对象。
2.2.2 对象（Object）
- 组成：对象由三部分构成——数据（Data）、元数据（Metadata）、唯一标识符（Key）。
- Key：对象在桶内的唯一标识，通常使用类似文件路径的字符串（如
images/2024/photo.jpg），但实际是扁平键值。 - 元数据：系统元数据（大小、ETag、最后修改时间）和用户自定义元数据（键值对，最多 2KB）。
- 数据：最大支持 5TB（MinIO 默认分片上传上限），实际生产建议单对象不超过 50GB。
最佳实践：对象 Key 的设计直接影响查询性能。建议使用 哈希前缀（如 a1/2024/photo.jpg）来避免热点目录，因为 MinIO 内部通过 Key 哈希分布数据。
下图展示了桶与对象的关系以及对象内部结构：
2.3 数据一致性模型
数据一致性是分布式存储的核心挑战。MinIO 采用强一致性（Strong Consistency）模型，这是它与许多最终一致性对象存储（如 AWS S3 早期版本）的关键区别。
2.3.1 MinIO 的一致性保证
| 操作类型 | 一致性保证 | 说明 |
|---|---|---|
| 写后读（Read-after-Write） | 强一致 | PUT 对象成功后，后续 GET 立即返回最新数据 |
| 列表操作（List Objects） | 强一致 | 写入完成后，List 操作立即包含新对象 |
| 删除操作（Delete） | 强一致 | DELETE 成功后，后续 GET 返回 404 |
| 覆盖写（Overwrite） | 强一致 | 同名对象覆盖后，后续读取返回新版本 |
| 多版本并发 | 线性一致 | 并发写入最终通过法定人数（Quorum）确定唯一版本 |
注意：强一致性是有代价的。MinIO 在写入时要求法定节点（N/2+1）确认后才返回成功，这增加了写入延迟，但消除了"读到旧数据"的脏读问题。对于金融、医疗等场景，强一致性是硬性要求。
2.3.2 一致性实现机制
MinIO 通过以下技术栈保证强一致性：
- Quorum 写入：每个对象写入必须获得至少 N/2+1 个存储节点的成功确认。
- Read Quorum：读取时同样需要从法定节点获取数据，通过校验和验证数据完整性。
- 版本向量（Version Vector）：每个对象维护版本向量，用于检测和解决并发冲突。
- 锁机制：在对象级别使用分布式锁，防止并发写入导致的数据损坏。
2.3.3 与最终一致性系统的对比
| 特性 | MinIO（强一致） | 最终一致性系统 |
|---|---|---|
| 写入延迟 | 较高（需 Quorum 确认） | 较低（异步复制） |
| 读取正确性 | 100% 返回最新数据 | 可能读到旧版本 |
| 冲突处理 | 自动解决，无冲突版本 | 需应用层处理冲突 |
| 适用场景 | 数据库备份、交易记录 | 日志、社交媒体内容 |
架构决策：MinIO 选择强一致性而非最终一致性，是因为它面向企业级工作负载（如 AI 训练数据、数据库备份），这些场景不能容忍数据不一致。代价是写入性能略低于异步复制系统，但通过并行写入和流水线技术，MinIO 仍能达到 10GB/s+ 的聚合写入吞吐。
下图展示了 MinIO 强一致性写入的法定人数流程：
2.4 本章小结
- 对象存储通过扁平命名空间 + 丰富元数据 + HTTP API 实现了与块存储和文件存储的本质区别。
- 桶是逻辑容器，对象是数据、元数据和 Key 的封装体，两者构成对象存储的最小管理单元。
- MinIO 采用强一致性模型，通过 Quorum 机制保证写后读一致性，适用于对数据准确性要求严苛的企业场景。