SRE-谷歌运维揭秘
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-10-04
系统设计 26：占座到期与支付回调的库存边界
同一个座位的最后一张票，甲乙同时点击购买。排队系统可以让请求平稳进入，却不能代替库存判断；缓存中“锁住 A1”也无法回答这样的问题：甲占座到期释放给乙后，甲的支付成功回调才到，应该给谁出票？答案取决于座位与订单的权威状态，而不是谁最先收到回调。 本文只讨论实名/价格之外的单座位库存、限时占座、支付结果和重复回调。支付调用是本地模拟；并发与唯一约束由实际 SQLite 文件中的事务验证，不把它外推为真实票务或第三方支付的端到端保证。 谁能作出“卖出”承诺 接口按状态划分：POST /queue/entries {event_id} 返回有期限的准入票据；POST /holds {seat_id, request_key} 返回 order_id, expires_at 或明确的不可占用；GET /orders/{id} 查询权威状态；POST /payment-callbacks {event_id, order_id, result} 仅供验证签名的支付系统调用。排队票据限制到达率，不是库存所有权；...
2026-05-14
缓存系统设计全景——从原理到生产的完整指南
缓存是提升系统性能的第一利器，但也是引发故障的第一杀手。从缓存穿透、击穿、雪崩三大经典问题，到多级缓存架构、分布式锁、热点 Key 治理，缓存设计几乎贯穿后端工程师的整个职业生涯。 本文将系统性地剖析缓存系统的设计原则与生产实践，从单机进程内缓存到分布式 Redis 集群，从理论模型到可落地的代码方案，构建一套完整的缓存知识体系。 Part 1: 缓存的本质与适用场景 什么是缓存 缓存是一种以空间换时间的优化技术，通过在计算代价较高的数据源（数据库、外部服务等）和消费方之间插入高速存储层，减少重复计算的执行次数。 存储介质延迟对比 存储介质 访问延迟 吞吐量 成本 CPU L1 Cache ~1 ns — 极高 CPU L3 Cache ~10 ns — 高 内存（RAM） ~100 ns ~10 GB/s 中 SSD ~100 μs ~500 MB/s 低 HDD ~10 ms ~100 MB/s 极低 网络（同机房） ~500 μs — — 网络（跨机房） ~50 ms — — 内存访问比 SSD 快 1000 倍，比 HDD ...
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
系统设计 E03：指标日志平台的基数与保留代价
指标平台常在查询量还不大时就被标签组合拖垮。一个请求计数器加上 user_id，不是多存一个字符串，而是可能把六十条时间序列变成六万条。保留期和降采样又会改变哪些历史问题还能回答，平台设计不能只报“每天写入多少 GB”。 本篇限定为内部服务指标与结构化日志，支持服务健康查询、地域汇总和单请求排查。排除完整 APM、全文搜索产品复刻与真实用户数据。写入确认只承诺进入约定持久层，查询需返回数据时间范围及缺失信息；已过期原始数据不得用降采样结果冒充原始精度。 先固定查询集，再选数据布局 三类查询决定三条访问路径：查询某服务最近一分钟最大延迟，需要细粒度窗口值；查询各地域总请求量，需要按有限标签聚合；查询 request_id 的错误日志，需要可定位明细。把三类数据都放同一套标签系统，会让单请求排查所需高基数标识污染常驻指标。 指标模型为 metric_name, labels, timestamp, value，标签集合标识一条序列；日志模型为 timestamp, service, level, request_id, body。写接口 POST /metrics/batch、PO...
2025-07-29
副本复制算法与架构——PacificA、Elasticsearch、Kafka、Pulsar 全面对比
本文将深入剖析 PacificA、Elasticsearch、Kafka、Pulsar 四大分布式系统的副本复制机制，揭示它们在一致性、可用性和性能之间的精妙权衡。这些系统虽然都通过副本复制来保证数据可靠性和高可用性，但在具体的实现策略上各有特色，反映了不同的设计哲学和适用场景。 引言：为什么需要副本复制 数据可靠性与高可用性 在分布式系统中，硬件故障是常态而非例外。Google 的统计数据显示，一个拥有 10,000 台服务器的数据中心，每天平均会有 2-3 台服务器发生故障。如果数据只存储在一台机器上，那么这台机器的故障就意味着数据的永久丢失。 副本复制（Replication） 是解决这个问题的核心手段：将数据复制到多台机器上，即使部分机器故障，数据仍然可用。 CAP 定理的实际影响 CAP 定理告诉我们，在网络分区（Partition）发生时，分布式系统只能在**一致性（Consistency）和可用性（Availability）**之间二选一： 选择 含义 代表系统 CP 网络分区时拒绝服务，保证一致性 ZooKeeper、etcd、HBase AP...
2026-10-04
系统设计 02：容量估算——QPS、存储、带宽、并发与成本
容量估算不是猜一台服务器能承受多少 QPS。先把业务动作拆成次数、字节、持续时间和保留期，再看哪一项随假设变化最快。算完只能得到待测的负载，不会凭空得到组件容量。 以图片分享的元数据、原图和预览图为教学场景。本篇重点是估算如何改变“上传流量是否穿过应用”这一设计决定，不讨论完整图片社交产品。此前的需求澄清讨论的是分享撤销契约；本篇使用独立的图片负载，不能把两个场景的指标拼成真实业务画像。 先把单位写在每个假设旁边 以下均为教学假设：5 万上传者每天各上传 4 张，得 20 万张/日；每张图片在 90 天保留期内累计产生平均 20 次预览读取，每次读取 256 KiB。按上传速率和各年龄图片的读取分布稳定、系统已进入稳态估算，日均预览读取量为 200000 × 20 = 4000000，读写比 20:1；这不是每张存量图片每天读取 20 次，后者在保留 90 天的稳态下将产生 200000 × 90 × 20 = 360000000 次读取/日。全天峰值按日均速率的 8 倍计算。每张原图 4 MiB，另外生成 2 张各 256 KiB 的预览；原图及预览保留 90 天、两份。每张...
