SRE-谷歌运维揭秘
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-10-04
系统设计 03：API 与数据模型——访问模式如何决定表、键和分页
先画一张“万能分享表”再补索引，常会漏掉实际最昂贵的访问：按用户和时间翻页。键、索引和游标应从查询与更新方式反推；如果列表在持续插入期间出现重复，补一台数据库机器也不会修正页面语义。 沿用前两篇的分享元数据场景：需求与撤销约束决定谁能看；容量估算给出怎么算峰值。本篇只回答“用户按时间查看自己的分享列表”，实验使用真实 SQLite，而不是用 Python 排序冒充数据库查询。 API 的三种访问，写入只有一个归属 教学范围有三条请求：POST /shares 创建分享，GET /shares/{share_id} 按标识取单条，GET /users/{owner_id}/shares?limit=20&after=... 按创建时间倒序取列表。已登录的创建者可以 DELETE /shares/{share_id} 撤销；只有本人可以列出自己的分享，列表允许展示已撤销状态但不展示给读者。排除按目标 URL 搜索、全站热度排名及跨用户浏览。对外读取仍按第 01 篇的强撤销契约判断。 读者用链接查单条，创建者按时间浏览列表，两个路径的定位方式不同。候选表 shares(sha...
2026-10-04
系统设计 23：爬虫的访问边界与可恢复队列
一条首页链接指向 /calendar/0，第二页指向 /calendar/1，后面每天都有“下一天”。抓到一百万页不等于建好了搜索入口：如果抓取进程重启后忘了待访问 URL，或者不同写法的同一 URL 占满队列，站点还没抓完，预算已经耗尽。爬虫首先是有边界的调度系统，其次才是 HTTP 客户端。 本篇只抓进程内搭建的合成站点，不请求真实网站。规模与 SLO 都是教学目标，实验只验证有限队列及失败行为，不测生产爬虫吞吐。 先问允许抓什么 需求是发现站点内页面、保留有用内容供后续索引，同时限制对站点的访问速率。核心不变量有三条：未被策略允许的 URL 不发请求；一个规范化 URL 在本轮最多标成一个待处理任务；被确认完成的任务在恢复后不再作为新任务反复抓取。最后一条并不承诺网络请求恰好一次：响应到达与“已完成”提交之间崩溃，恢复只能重抓，再由索引侧按 URL 和内容版本幂等处理。 教学 SLO：允许的源站请求相邻发起时间间隔至少 30 ms；站点出现暂时性 503 时最多重试两次；调度进程故障后五分钟内恢复已提交的任务状态。实验的请求间隔断言容忍 2 ms 服务端观测偏差，不验证五...
2025-07-29
数据库写入的潜规则——合并树与 MPP 架构深度剖析
许多开发者在使用 ClickHouse、HBase、Elasticsearch 等现代数据系统时，都会遇到"不建议高频写入"的限制。这一限制常被归因于"列式存储"，但这是一个常见的误解。 高频写入受限的根本原因在于数据库的存储引擎架构。本文将深入剖析四大主流架构——LSM-Tree、ClickHouse MergeTree、MPP 和 B-Tree——分析它们各自的写入机制、性能权衡，以及它们"偏爱"批量写入的底层原因。 Part 1: 磁盘 I/O 基础——理解一切的前提 深入存储引擎之前，有必要先理解磁盘 I/O 的基本特性，因为所有存储引擎的设计都是围绕磁盘特性做出的权衡。 随机写 vs 顺序写 指标 HDD（机械硬盘） SSD（固态硬盘） 内存（DRAM） 随机写 IOPS ~100-200 10K-100K ~10M 顺序写吞吐 ~100-200 MB/s 500 MB/s - 3 GB/s ~10 GB/s 随机写延迟 ~10ms（寻道时间） ~100μs ~100ns 顺序写延迟...
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
系统设计 22：限流器的原子计数与全局配额
“每个用户每秒允许十次”还不足以实现限流。十次是自然秒内计数、任意一秒窗口，还是长期每秒十次并允许短时突发？配额由一个实例独占，还是十个网关各发十个令牌？请求到达时间、计数位置和原子边界不同，允许数量就不同。 本篇把 API 限流设计成明确的资源分配协议：令牌桶容量为 B、补充速率为 r，请求花费一个令牌；多个入口共享同一逻辑配额。目标是限制成本较高的查询，不承担账户余额、座位库存等不可超发资源的最终正确性。所有容量数字为教学假设，实验在真实 SQLite 上验证共享状态事务，不声称验证了 Redis Lua。 限流键也是授权边界 网关先鉴权，再用稳定的租户 ID 和 API 类别组成配额键。直接信任客户端提交的 user_id 会允许换键绕过限流；只按 IP 则可能惩罚共享出口的公司或学校。未认证请求可以用 IP 做粗粒度保护，但不能由此推导认证用户公平性。 限流调用可表述为 acquire(tenant, route_class, cost, request_id)，返回 allowed, retry_after, remaining。业务 API 被拒绝时返回 429；R...
2026-10-04
系统设计 29：排行榜的迟到修正与热点代价
如果一场比赛的第 60–120 秒排行榜在第 120 秒立刻封榜，一条第 69 秒发生、但第 121 秒才入站的得分应该去哪？忽略它能让榜单快速稳定，却会让账本与排行榜对不上。排行榜设计首先需要决定：读的是实时暂定榜，还是可纠错的最终榜。 本题假设每个被验证的得分事件 event_id 对同一窗口只计一次；窗口采用事件时间半开区间 [60,120) 秒。相同分数采用并列密集排名，展示顺序再按玩家 ID 字典序稳定排序。删除作弊得分也是修正事件，不是默默改计数。只有权限通过的已确认事件进入榜单，未验证事件不参与计算。 先把榜单合同写全 教学 SLO：暂定榜近 30 天 99% 请求在入口 200 毫秒内返回，且带 computed_through 位点；已受理得分在 5 秒内进入暂定榜（处理完成时间减本地持久化时间的 99%）。终榜在窗口结束后等待 2 分钟迟到宽限，再按相同事件集批量重算并公布版本。以上都是目标，不是实验测出的性能。更晚到达的事件放到修正队列，由业务规则决定是否发新版本。跨赛季汇总、奖金发放和反作弊算法不在本题范围内；有奖金时不能把该暂定榜当财务最终排名。 假设...
