【场景面试题】八、存储、对象、边缘与成本（71～80）

文章目录八、存储、对象、边缘与成本718071. 图片缩略图服务如何设计支持多尺寸、高并发和防重复处理具体示例72. 对象存储如何做上传授权、防盗链和权限控制具体示例73. CDN 缓存如何设计既降低源站压力又能快速刷新具体示例74. 文件夹和文件元数据服务怎么设计支持亿级文件和移动/重命名具体示例75. 如何做冷热数据分层和成本治理具体示例76. 向量检索系统如何设计用于相似内容或语义搜索具体示例77. 附近的人或附近门店怎么做地理位置查询具体示例78. 大规模配置快照如何下发到百万客户端或服务实例具体示例79. 配额、计量和计费系统如何设计具体示例80. 事件 Schema 演进如何治理避免上下游互相打挂具体示例八、存储、对象、边缘与成本718071. 图片缩略图服务如何设计支持多尺寸、高并发和防重复处理场景与难点。用户上传一张原图多个业务要不同尺寸和格式热门图片会被大量访问冷图片又不值得提前生成所有规格。方案。上传后保存原图和元数据常用规格异步预生成长尾规格按需生成并缓存。生成任务用(image_id, spec)幂等避免并发重复转码。缩略图存对象存储CDN 缓存访问。对超大图、异常格式和恶意图片做解析限制。具体示例具体设定。一张头像需要 64x64、200x200、WebP 和 JPEG 四种规格。落地例子。元数据表保存image_id, origin_url, width, height, checksum。请求avatar/123?spec200x200_webp时先查对象存储是否已有没有则提交任务并短暂返回默认图或同步生成小图。任务完成后写derived_image(image_id, spec, url)。面试可讲。缩略图系统要讲原图保留、规格幂等、按需生成、CDN 和安全解析不是简单调用图片库。72. 对象存储如何做上传授权、防盗链和权限控制场景与难点。大文件应直传对象存储但不能把永久密钥发给客户端私有文件还要防止链接被转发后长期可访问。方案。服务端签发短期上传凭证或预签名 URL限制 bucket、key 前缀、大小、Content-Type 和过期时间。下载侧区分公开资源和私有资源公开走 CDN私有走短期签名 URL 或鉴权代理。所有对象 key 不包含敏感信息并记录 owner 与权限。具体示例具体设定。用户上传身份证照片只允许本人和审核员短时间访问。落地例子。客户端先调用create_upload_session服务端返回 10 分钟有效的上传 URLkey 为kyc/user_id/date/random。下载时服务端校验用户权限后生成 60 秒有效的 signed URL审核员访问写审计日志。面试可讲。直传解决带宽问题签名和短 TTL 解决安全问题。不要暴露永久 AK/SK也不要让私有资源用永久 CDN 地址。73. CDN 缓存如何设计既降低源站压力又能快速刷新场景与难点。CDN 能抗读流量但缓存过期、刷新、版本切换和私有资源很容易出问题。不同资源的缓存策略不同静态资源、图片、视频、接口响应不能一刀切。方案。静态资源使用内容 hash 文件名长期缓存可变资源使用短 TTL 或版本化 URL强一致变更走主动刷新或版本切换。源站支持回源鉴权、Range 请求和压缩。监控命中率、回源流量、刷新队列和 4xx/5xx。具体示例具体设定。用户更换头像后别人仍看到旧头像。落地例子。头像 URL 带版本avatar/user_123?v18。更新头像后写新对象并把用户资料中的 avatar_version 从 17 改到 18新页面自然加载新 URL。旧 URL 可等 TTL 过期不必全网刷新。面试可讲。能版本化就少刷新。CDN 刷新有延迟和配额核心资源要设计 URL 版本。74. 文件夹和文件元数据服务怎么设计支持亿级文件和移动/重命名场景与难点。云盘类系统里对象内容在对象存储目录树和权限在元数据服务。移动文件夹、重命名、分享权限、回收站都容易引发大量级联操作。方案。文件表保存file_id, owner_id, parent_id, name, type, object_key, status同一父目录下(parent_id, name)唯一。移动目录只改根节点 parent不递归改所有子节点路径查询可用 materialized path 或祖先索引加速。删除先进入回收站异步清理对象。具体示例具体设定。用户把包含 100 万文件的目录从 A 文件夹移动到 B 文件夹。落地例子。如果每个子文件都更新路径会产生 100 万次写。更好的方式是目录树以parent_id表达移动只更新该目录节点的parent_idB和版本号权限继承由读时计算或异步刷新索引。面试可讲。目录移动要避免级联写爆炸。元数据和对象内容分离文件删除也要有回收站和异步物理删除。75. 如何做冷热数据分层和成本治理场景与难点。数据越存越多热库、搜索、缓存、日志索引都会变贵。成本治理不是简单删数据要结合访问频率、合规保留期和恢复需求。方案。按数据年龄、状态和访问热度分层热层支持低延迟查询温层支持低频检索冷层用对象存储/湖仓压缩保存。归档过程要有校验、索引和回溯入口。查询网关屏蔽冷热差异必要时异步回载。建立数据 TTL、owner 和成本看板。具体示例具体设定。用户订单 3 个月内常查3 年内偶尔查7 年内只为合规保留。落地例子。近 3 个月在交易库3 个月到 3 年进入归档库和搜索摘要3 年以上压缩到对象存储。用户查老订单时先查归档索引详情异步回载或读取冷层文件。面试可讲。冷热分层要讲查询入口、校验和恢复不是把老数据搬走就完事。76. 向量检索系统如何设计用于相似内容或语义搜索场景与难点。向量检索适合“相似图片、相似视频、语义搜索”但要处理 embedding 生成、索引构建、召回延迟、过滤条件和版本更新。方案。内容入库后异步生成 embedding写入向量索引查询时把文本或图片转向量做 ANN 召回再结合业务过滤和排序。向量索引按业务、语言或类目分片embedding 模型版本要记录模型升级时支持双索引灰度。具体示例具体设定。用户上传一张鞋子图片要找相似商品。落地例子。图片模型生成 768 维向量在向量库中按类目shoes搜 Top 1000再过滤库存、价格和商家质量最后用商品点击率和文本相关性重排。索引文档记录embedding_modelv3。面试可讲。向量检索解决语义召回不替代业务过滤和排序。要提模型版本、索引重建和召回后重排。77. 附近的人或附近门店怎么做地理位置查询场景与难点。地理查询要在经纬度上快速找附近对象还要考虑距离排序、实时移动、隐私和城市热点。简单全表计算距离不可行。方案。使用 GeoHash、S2 或数据库空间索引把经纬度映射到网格。查询时先取当前位置所在网格和周边网格候选再精确计算球面距离并排序。高频移动对象写入内存地理索引低频门店可以放搜索引擎或空间数据库。位置数据设置 TTL 和隐私开关。具体示例具体设定。用户想找 3 公里内营业中的咖啡店。落地例子。将门店按 geohash 前缀建索引查询用户所在 geohash 及周边 8 个格子的门店过滤statusopen再用 Haversine 精确算距离返回最近 20 个。面试可讲。地理查询是“网格粗筛 精确距离计算”。网格大小要随半径调整不能只查一个格子。78. 大规模配置快照如何下发到百万客户端或服务实例场景与难点。配置中心不仅服务后端也可能给端上或大量边缘节点下发规则。百万客户端同时拉配置会压垮控制面配置错误还会造成大面积事故。方案。配置生成不可变快照包含版本、签名、灰度规则和回滚指针。客户端启动拉全量运行中通过长连接/推送拿到版本通知再按需拉取差量。控制面使用 CDN/对象存储分发大快照服务端只处理元数据和权限。客户端保留最后一个可用版本。具体示例具体设定。风控规则快照 5MB需要 50 万 App 在 10 分钟内更新。落地例子。控制面生成risk_rules_v20260712上传对象存储和 CDN推送只发送版本号和签名。客户端分批随机延迟拉取校验签名后原子切换拉取失败继续用旧版本。面试可讲。大配置要把“通知”和“内容分发”拆开。版本、签名、灰度和回滚比实时性更重要。79. 配额、计量和计费系统如何设计场景与难点。开放 API、云服务、多租户平台都需要计量和计费。计量要求不重不漏计费要求可追溯、可重算、可对账。方案。请求或资源使用产生 usage event事件带 tenant、resource、amount、unit、request_id 和时间。实时计量用于限额和看板离线账单用于结算。计费规则版本化账单生成后不可直接修改只能用调整单冲正。关键事件保留原始流水支持重算。具体示例具体设定。某开放平台按 API 调用次数收费每 1000 次 1 元失败请求不收费。落地例子。网关对成功请求写usage_event(app_id, api, request_id, unitcall, amount1)。实时聚合更新当月用量离线每天按 request_id 去重后生成账单明细。价格规则price_rule_version202607固化在账单中。面试可讲。计费系统核心是流水、去重、规则版本和对账。不要只用 Redis 计数当账单依据。80. 事件 Schema 演进如何治理避免上下游互相打挂场景与难点。一个事件可能被十几个下游消费随便删字段或改枚举会让消费者失败。事件治理要解决兼容性、版本、owner 和回放。方案。事件用 IDL/Schema Registry 管理变更做兼容性检查。新增字段必须可选且有默认值删除字段走弃用期枚举只能追加。生产者发布前在测试环境回放样本事件下游订阅版本明确。事件中保留 schema_version消费者按版本解析。具体示例具体设定。order_paid事件要新增coupon_amount字段并把pay_type增加APPLE_PAY。落地例子。新字段设为 optional老消费者忽略新增枚举不会改变旧值含义。Schema Registry 校验通过后发布生产者灰度 5%监控下游消费失败率。面试可讲。事件契约是跨团队接口治理比代码细节更重要。兼容性检查和灰度是防事故关键。