对象存储面试题集：从六个问题收口
属于 S9 对象存储 · 收口篇 上一篇：STS 临时凭证
对象存储高频问题，每题练到连续追问三层。答题主线始终扣住剪辑素材场景（clip / 素材 / 成片）。
Q1：对象存储和块存储、文件存储的核心区别是什么？
按对外暴露的接口抽象分：块存储给你裸磁盘块（LBA 地址，SCSI/NVMe），文件存储给你 POSIX 目录树（挂载路径，可随机读写），对象存储给你一个扁平的、通过 bucket + key 全局寻址的键值仓库（HTTP RESTful）。对象不可变（只能整体覆盖，不能原地改几个字节），带丰富可自定义元数据，近乎无限水平扩展。
追问：为什么对象存储要牺牲"原地修改"？ 用可变性换扩展性。放弃随机写后，对象成了自包含的不可变单元，才能被自由地打散、冗余、跨机分布、跨地域缓存分发——这是它能做到海量 + 高并发 + 全球分发的前提。
追问：剪辑素材为什么适合对象存储？ 素材是非结构化整块数据（视频/图片/成片）、写少读多、以整体存取为主、量级持续膨胀、需要跨地域低延迟分发——每条都精准命中对象存储的能力圈。反过来订单/余额这种需频繁随机改写、强事务的，该放数据库。
追问：那"目录"在对象存储里是什么？ 没有真正的目录，clips/2026/a.mp4 整个字符串就是一个 key，/ 只是控制台做前缀聚合展示用的分隔符。列"目录"本质是按前缀（prefix）扫 key，这个前缀后面还直接用来做权限边界。
Q2：为什么需要分片上传（multipart）？三步协议是什么？
单请求整体 PUT 一个几百 MB 的素材有三个问题：中途断网前功尽弃、单请求耗时长易超时、无法并发提速。分片上传三步协议解决：① NewMultipartUpload 申请上传会话拿 uploadID；② PutObjectPart 把文件切片（除最后一片外每片 ≥ 5MiB），逐片上传各返回一个 ETag，分片间独立可并发可乱序；③ CompleteMultipartUpload 提交 (partNumber, ETag) 清单，服务端按 partNumber 排序合并。
追问：断点续传怎么在这套协议上实现？ 客户端记住 uploadID 和已成功的分片号，断网重连后 ListParts 查已传哪些、只续传缺片，不从头再来。手机弱网上传大素材靠它。
追问：上传失败了会留下什么？怎么清理？ 会留下已上传的悬空分片，一直占存储和钱。代码里用 defer 调 AbortMultipartUpload 主动清；生产再配一条 AbortIncompleteMultipartUpload: 7 days 生命周期规则兜底自动清。
追问：怎么判断一个对象是不是分片上传的？ 看 ETag。普通对象 ETag 是内容 MD5；分片合并后的 ETag 是复合形式 <md5>-<分片数>，带横杠和分片数就是分片上传的。
Q3：预签名 URL 的原理是什么？怎么保证安全？
后端用长期密钥对"某桶某 key + 某方法 + 某过期时间"做签名，生成一个带签名参数的临时 URL，客户端拿它直接 HTTP PUT/GET 存储。价值：数据洪流由客户端与存储直连，后端零带宽——不再当数据搬运工，只做鉴权 + 签发 + 触发处理。
追问：URL 泄露了怎么办？边界怎么焊死？ 签发时就卡死边界：短过期（分钟级）、限定方法（上传只签 PUT）、用 POST Policy 限大小和 Content-Type，且永远不把长期 AccessKey 下发到客户端。就算泄露，损失也被限制在"这一个对象、这几分钟、这一种操作"。
追问：比预签名 URL 更可控的方案？ STS 临时凭据——后端向 STS 换一组带权限边界、几十分钟过期的临时 AK/SK/Token 给客户端，客户端用它调 SDK，比裸发 URL 更灵活、可做更细的权限约束。
Q4：多副本和纠删码怎么选？为什么不全用纠删码？
都是靠冗余扛盘坏。多副本：完整复制 N 份（通常 3），简单、读快、恢复轻，但空间放大 = N 倍。纠删码（EC）：切 k 个数据块 + 算 m 个校验块共 k+m 块，任意丢 ≤ m 块可由 Reed-Solomon 解码还原。以 4+2 为例空间放大仅 1.5×（对比 3×），但恢复要读齐 k 块重新解码。
追问：为什么不全用纠删码省钱？ 恢复成本和延迟。多副本坏了直接拷一份，纠删码坏一块要读齐 k 块解码，网络和 CPU 开销大得多；且小文件的切块/校验固定开销摊不平。所以热路径、小对象、低延迟仍用多副本。
追问：剪辑素材实际怎么落地？ 分层混用。刚上传、正被 AutoCut 处理的热素材用多副本（低延迟、恢复快）；发布很久、偶尔回看的冷成片转纠删码（省一半以上成本）。生命周期策略自动在热→温→冷→归档间迁移，用编码方式换成本。
追问：数据落哪台机器怎么定？扩容会全量迁移吗？ 一致性哈希：节点和对象都映射到 0~2³² 的环，对象顺时针找第一个节点。增删机器只影响环上相邻一小段，迁移量从"全量"降到 1/N；再用虚拟节点（每个物理节点放几百个分身）避免数据倾斜。
Q5：S3 的桶权限模型是什么？怎么做最小权限？
三层叠加：IAM Policy（绑身份，细粒度）、Bucket Policy（绑桶，中粒度）、ACL（绑桶/对象，旧机制，现建议禁用）。裁决规则两条铁律：默认拒绝（无任何 Allow 命中即拒）、显式 Deny 压倒一切（任何一处 Deny 命中则无论多少 Allow 都无效）。
追问：最小权限具体怎么收窄？ 以"CDN 只读 public/ 前缀"为例三点收窄：Action 只给 s3:GetObject（不给 List/写/删）、Resource 锁到 .../public/*（private/ 天然落在默认拒绝）、Principal:* 匿名之所以敢用正因 Resource 已收到最窄的只读公开前缀。绝不用 s3:* + Resource:* 的"上帝策略"。
追问：桶为什么会"裸奔"？怎么根治？ 三个根因：图省事整桶设 public-read、用了通配上帝策略、关了 Block Public Access 总闸。根治：桶默认开启 Block Public Access 总开关，只对确需公开的前缀用精确 Bucket Policy 开一个小口，绝不整桶放开。
Q6：上传素材成功后，下游立刻去读会不会读不到？
看操作粒度。现代主流对象存储（S3 自 2020、MinIO、TOS）对单对象的 PUT/GET/DELETE 提供强一致——PUT 返回成功后立刻 GET 一定读到这次内容。所以"上传成功回调 → 触发 GenAI 处理"是安全的。
追问：那什么情况会读到旧的/读不到？ 跨对象操作，尤其是 List。"删了立刻 List 还看得到""传了立刻 List 还没有"这类可能仍是最终一致，有收敛窗口。
追问：所以下游发现新素材的正确姿势是什么？ 别轮询 List。上传成功后主动投递一条消息/事件（key 直接带过去）触发下游流水线，既避开 List 的一致性窗口，又比轮询实时、省资源。这体现你懂一致性边界在业务上怎么落地。
追问：强一致的代价是什么？ 元数据要跨节点同步确认（用 Raft 这类强一致协议保护，见 S8），写延迟略高于最终一致。这是"控制面强一致 + 数据面高吞吐"分离设计的取舍：账本（元数据）不能错，数据本体摊到海量盘上做冗余。
自测清单
六题 + 三层追问全答上，S9 过关。核心追问链：接口抽象差异 → multipart 三步与断点续传 → 预签名原理与安全边界 → 多副本/纠删码权衡与分层 → 三层权限与最小化 → 单对象强一致 vs List 最终一致。面试讲素材链路时，能主动画出"预签名直传 + CDN 回源、后端零带宽"的时序，并点出"上传成功推事件而非轮询 List"，是很加分的架构 sense。