SRE-谷歌运维揭秘
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-10-04
系统设计 14：图片社交：上传成功之后还差一次发布提交
客户端收到对象上传成功，并不代表动态列表中已经有一张可展示的图片。缩略图可能未生成，图片可能未通过检查，元数据事务也可能失败。候选图片社交服务把“字节已经保存”和“用户能够看见”拆成两个状态，半成品只能停留在上传会话内。 Instagram 在这里表示上传、处理和展示的题型，不表示公开资料之外的真实产品架构。范围包括原图、固定尺寸缩略图、私密相册和动态展示；图像推荐模型、直播和全功能社交关系留给后续章节。 候选 SLO 是上传已完成且校验通过的原图中 99% 在两分钟内进入 READY 或可解释的终态 REJECTED；动态读取在五分钟窗口内 p99 小于 200 ms。对象云服务、实际解码与异步变体没有进入本次实验，故这些目标尚未被性能验证；半成品不可见才是已测试的不变量。 把发布作为一个明确的接口 POST /uploads 创建会话，返回上传 ID、对象键、允许的大小和类型，以及限时上传凭据。POST /uploads/{id}/complete 提交实际长度和校验信息，服务端读取对象元数据并检查是否符合会话约束。POST /photos/{...
2025-07-28
Redis 经典用例全解：从数据结构到系统设计
Redis 最容易被误解成“更快的数据库”。这个理解只对了一小半。Redis 更适合放在系统的热路径上，处理短生命周期状态、派生索引、原子协调、近实时统计和少量高频列表；完整事实仍然应该由数据库、日志或对象存储承载。 系统设计面试里，Redis 的价值也不在命令背诵。更重要的是把业务需求翻译成几个稳定的问题模型： 这份数据是否可以过期 这份数据丢了能否重建 读路径是否远热于写路径 是否需要排序、范围查询、集合运算或原子判断 Redis 故障时，系统还能不能保持核心正确性 答案如果把 Redis 当成事实库，通常会在持久性、审核追溯、深页查询或跨 key 一致性上掉坑。更可靠的边界是：数据库保存事实，Redis 保存热路径和派生状态。 Redis 的系统设计位置 Redis 方案设计可以按四步落地： 步骤 要回答的问题 常见错误 抽象操作 业务本质是读写单值、排序、集合、位图、消息流，还是原子判断 上来先套命令 设计 Key Key 的粒度、生命周期、hash slot、热点边界是什么 一个业务对象塞进一个大 key 明确事实源 哪些数据必须落数据库，哪...
2026-10-04
系统设计 29：排行榜的迟到修正与热点代价
如果一场比赛的第 60–120 秒排行榜在第 120 秒立刻封榜，一条第 69 秒发生、但第 121 秒才入站的得分应该去哪？忽略它能让榜单快速稳定，却会让账本与排行榜对不上。排行榜设计首先需要决定：读的是实时暂定榜，还是可纠错的最终榜。 本题假设每个被验证的得分事件 event_id 对同一窗口只计一次；窗口采用事件时间半开区间 [60,120) 秒。相同分数采用并列密集排名，展示顺序再按玩家 ID 字典序稳定排序。删除作弊得分也是修正事件，不是默默改计数。只有权限通过的已确认事件进入榜单，未验证事件不参与计算。 先把榜单合同写全 教学 SLO：暂定榜近 30 天 99% 请求在入口 200 毫秒内返回，且带 computed_through 位点；已受理得分在 5 秒内进入暂定榜（处理完成时间减本地持久化时间的 99%）。终榜在窗口结束后等待 2 分钟迟到宽限，再按相同事件集批量重算并公布版本。以上都是目标，不是实验测出的性能。更晚到达的事件放到修正队列，由业务规则决定是否发新版本。跨赛季汇总、奖金发放和反作弊算法不在本题范围内；有奖金时不能把该暂定榜当财务最终排名。 假设...
2026-10-04
系统设计 25：司机指派竞争与迟到确认
两名乘客同时命中同一位最近司机，地理查询都没有错，却只能有一单得到有效指派。附近搜索解决“谁可能接单”；派单解决“谁独占接单权”。如果将位置索引中的司机从“可用”改为“忙碌”就算确认，两个请求仍可能在旧副本中各拿到一次成功。 本文用一位本地模拟司机、十二个并发乘客请求和真实 SQLite 写事务划清派单边界；不假设任何网约车公司的内部实现。规模和服务目标均为教学假设，非实测性能。 把一次派单拆成两个确认 乘客请求 POST /trips {pickup, destination, request_key}；服务返回 trip_id、状态。派单内部接口 offer(trip_id, driver_id, offer_token, deadline) 把“占有接单机会”写入权威存储；司机本地模拟回调 POST /offers/{token}/ack。状态路径为 requested → offered → accepted → started → completed，在发车前可 cancelled，超时可 expired。本次实验只实现至 ac...
2026-10-04
系统设计 15：文件同步：断点续传和多端冲突要分别解决
两台电脑都从版本 7 开始编辑同一个文件。A 先上传并提交版本 8，B 随后上传自己的内容。如果服务端只采用最后到达的请求，A 的修改就被静默覆盖；如果只拒绝 B，B 又可能丢掉已经完成的工作。文件同步需要保存字节，也需要保存每次修改相对于哪个版本发生。 Dropbox 在这里表示多端文件同步题型。候选方案支持普通二进制文件、分块上传、离线编辑与冲突副本，不承诺理解任意文档格式并自动合并。正文沿上传恢复和版本提交两条路径展开。 候选 SLO 是全部块已经在服务端校验后的版本提交在五分钟窗口内 p99 小于 500 ms；一旦返回提交成功，新读取要么看到完整新版本，要么在明确隔离的副本延迟窗口中返回旧完整版本，不得看到缺块版本。网络上传、断线补传耗时不计入提交延迟；本地脚本只验证字节校验和条件更新，并未验证该延迟或跨副本行为。 文件身份不等于文件路径 文件拥有稳定 file_id，名称与父目录只是可变元数据。否则重命名会被误识别为删除旧文件再创建新文件，其他设备的未完成上传也会失去归属。基础数据有 files(file_id, parent_id, name, current_v...
2026-10-04
系统设计 20：社交内容搜索的增量索引与新鲜度
一条动态先写下 blue bird，后来改成 green bird，最后被删除。搜索端如果只追加“新增词项”，blue 和 green 可能同时搜到同一条；即使正确删除了词项，迟到的旧编辑事件还能把已删内容重新放回结果。这是 Twitter Search 类型题目里比“用什么倒排索引”更先要回答的问题：一次修改怎样替换旧词集，重放为什么不能覆盖新版本，以及用户究竟在等哪个“可搜索”时刻。 本文设计公共短文本搜索，不声称是 Twitter 的真实架构；第 19 篇信息流候选排序与权限撤销处理旧候选的读时安全门禁，下一篇输入联想则查询词条前缀而不是全文。分片与排名是教学设计；实验的延迟是本地 SQLite FTS5 查询观测，不代表分布式搜索引擎性能。 “发布成功”和“能搜到”分开定义 允许发帖、编辑、删除、按单词查询公开内容；搜索结果不得混入另一个租户或私密帖子。帖子权威数据与索引分离，发帖成功表示权威状态及可重放变更记录已持久接受，不等于已经刷新可搜索索引。编辑在索引里必须替换旧版本的词项，删除必须同时撤掉词项并保留能挡住旧事件的墓碑。对任一 post_id，索引应用的版本只能...
