对象存储如何让海量对象不丢失？元数据服务与数据服务交互设计全解析

对象存储如何让海量对象不丢失元数据服务与数据服务交互设计全解析【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insiders Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notessystem-design-notes是一套系统设计的开源学习笔记覆盖了经典书籍《System Design Interview - An Insiders Guide》中的 28 个主题。其第 24 章以 Amazon S3 为原型完整拆解了对象存储服务的设计。本章中最值得细读的部分就是元数据服务Metadata Service与数据服务Data Store之间的交互设计——两个服务如何分工、如何用一个 UUID 把元数据和真实数据串起来。本文将带你逐步看懂这套机制。为什么对象存储要拆分元数据与数据对象存储与块存储、文件存储并列为三大存储类型它用部分性能换取高持久性、海量扩展能力和低成本主要面向备份、归档等冷数据场景。对象存储的核心设计哲学与 UNIX 文件系统如出一辙保存文件时文件名先记录到 inode 中文件内容单独存放在磁盘的不同位置访问文件时先从 inode 读取元数据再根据块指针获取文件内容对象存储同理元数据服务负责记录文件在哪数据服务负责存放内容本身。这种拆分带来了关键优势两类存储可以独立扩展。Bucket存储桶是全局唯一命名的逻辑容器对象在桶内平铺存放没有层级目录总体架构元数据服务与数据服务的协作分工对象存储的高层设计包含 5 个核心组件组件职责负载均衡器将 API 请求分发到不同的服务副本API 服务无状态编排层是协调元数据服务与数据服务的指挥者IAM 服务统一的身份认证与访问授权元数据服务记录对象元数据底层是 Metadata DB数据服务持久化对象真实数据由一个主节点 两个从节点组成两个服务交互的枢纽是一个UUID上传时数据服务生成 UUID下载时 API 服务先向元数据服务查 UUID再拿它向数据服务取内容。对象上传流程先落数据再记元数据上传script.txt的完整时序用户发送 HTTP PUT 请求创建名为 bucket-to-share 的桶API 服务向 IAM 验证身份与写权限验证通过后元数据服务创建桶记录返回成功用户再次发送 HTTP PUT 请求上传对象 script.txtAPI 服务校验用户写权限对象内容先发送给数据服务数据服务持久化后返回对象 UUIDAPI 服务再在元数据服务中创建新条目写入 object_id、bucket_id、bucket_name 等元数据⚠️ 注意顺序数据服务先返回 UUID元数据服务后登记。这样能保证元数据里记录的 ID 一定能在数据服务中找到对应内容避免出现元数据指向空数据的悬挂记录。对象下载流程先查元数据再取数据下载流程与上传正好相反体现了元数据服务的索引价值客户端发送 HTTP GET 请求如GET /bucket-to-share/script.txtAPI 服务向 IAM 验证用户是否有读桶权限API 服务查询元数据服务根据桶名对象名拿到对象 UUIDAPI 服务凭 UUID 向数据服务请求对象内容内容返回给客户端 桶内没有真实目录结构通过桶名对象名拼接可以模拟出文件夹层级如photos/2024/01.jpg。数据服务内部路由、放置与数据节点三件套协作在 API 服务视角与数据服务的接口极其简洁上传时传入file_content拿回ObjectID下载时传入ObjectID拿回文件内容。数据服务内部则是三组件结构数据路由服务无状态对外提供 RESTful/gRPC API。负责查询放置服务选出最佳数据节点以及读写数据扩容只需加机器放置服务维护一张虚拟集群地图掌握集群物理拓扑决定对象该落到哪个数据节点同时监听数据节点心跳判断节点健康。作为关键服务建议部署 5 或 7 个副本并通过 Paxos/Raft 共识同步——7 节点集群可容忍 3 个节点故障数据节点存放真实对象数据。每个节点运行守护进程向放置服务发送心跳汇报管理多少块磁盘、每块盘存了多少数据数据持久化流程副本同步与强一致性的取舍持久化五步走API 服务把对象数据转发给数据服务数据路由服务向放置服务查询选定主数据节点数据被发送到主节点主节点先本地落盘再复制到两个从节点复制成功后才返回响应对象 UUID 返回给 API 服务这里有两个设计要点给定对象 UUID其副本组通过一致性哈希确定性地选定——所以下载时随时能找回数据在哪主节点在复制完成后才响应是典型的用更高延迟换强一致性的取舍WAL 大文件与对象映射表如果每个对象存成单独文件海量小文件会让文件系统崩溃HDD 上每个文件至少占用一个 4KB 块且 inode 数量有限。改进方案是用**写前日志WAL**把多个小对象顺序拼进大文件文件写满通常几 GB后新建一个。同时数据节点维护一张object_mapping映射表记录 object_id、文件名、偏移量、大小通常直接在内嵌一个 SQLite 这类轻量关系库避免为查找表单独部署数据库集群带来的网络延迟元数据服务数据模型与分片策略元数据服务维护两张核心表bucket 表bucket_name、bucket_id、owner_id、enable_versioningobject 表bucket_name、object_name、object_version、object_id需要支持的查询只有三类按名称查对象 ID、按名称插入/删除、列出桶内同前缀对象。分片策略的权衡是本章的精华之一按bucket_id分片 → 热门桶可能含数十亿对象出现热点按object_id分片 → 负载均匀但按名称查询变慢最终选择按hash(bucket_name, object_name)分片匹配绝大多数查询模式分片后按前缀列对象变成跨片查询分页困难。务实的做法是额外建一张按 bucket_id 分片的反规范化列表表把列表操作隔离到单个实例对象存储本就不为列表优化牺牲一点列表性能可以接受。对象版本化则通过object_version列TIMEUUID 类型实现每个新版本生成新的 object_id天然可按时间排序删除对象等价于插入一个特殊版本标记查询它时返回 404。小结元数据服务与数据服务的交互本质是一套**UUID 接力** 机制上传数据服务先落数据产出 UUID → 元数据服务登记映射下载元数据服务查 UUID → 数据服务凭 UUID 取数一致性副本复制完成才返回强一致优先扩展性元数据与数据各自独立分片、独立扩容想继续深入的对象还有大文件分片上传Multipart Upload、纠删码Erasure Coding与副本的取舍、垃圾回收与 Compaction。完整原文见 第24章S3-like Object Storage全部 28 章笔记的目录见项目根目录 Readme.md。【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insiders Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考