SRE-谷歌运维揭秘
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2020-07-12
软件方法
建模带来竞争优势。 前言 “唱曲的名家，唱到极快处，吐字依然干净利落”。 不能站在别人的肩膀上看得更远，只是摘抄别人的观点，无意义。要有足够的积累，和深度的思考。 涉众（stakeholder）往往会做而不会定义，把不同类型的涉众放在一起访谈时，只会剩下在场军衔最高那个人的意见。 需求变更的时候，要注意涉众利益角度分析。 项目的流程步骤： 寻找老大 揣摩愿景 业务建模 系统用例 需求规约 分析模型 设计开发 只有一个领域（核心域）的知识是系统能在市场上生存的理由。 拿来主义要摒除门户之见，不关注流派和风格，着力于细节和应用。 建模与 uml 利润 = 需求 - 设计 需求：提升销售 设计：降低开发维护成本 几种弊习： 从需求直接映射设计，会得到大量的重复代码。 从设计出发来定义需求，会得到一堆假的“需求”。 从涉众视角对系统功能分包会得到需求包。 子系统是基于内部视角根据系统部件的耦合和内聚情况进行切割。 需求 设计 卖的视角 做的视角 具体 抽象 产品当项目做 项目当产品做 设计源于需求，高于需求 建模工作流 业务建模：描述组织...
2021-09-05
基本编程范式、模型和风格
盒子模型 表达式由一系列盒子组成，这些盒子相互决定位置和大小。 流水线模型 模式-动作范式 一系列的输入会被每个模式所检查，模式匹配时，执行相应的输入。 复杂流程总-分架构 流程被分为：step1、step2、step3；stage1、stage2、stage3；phase1、phase2、phase3。 数据只要可以在同层内串联，每一层就可能被抽象成 step。如果 step 的输入输出是无关的，则需要使用 context 模式；否则使用 stream 模式，每个 step 可以由<T,R>指定输入输出类型，每个 step 的输出会成为下一个阶段的输入。。每一步如果可以在实现上变化，可以使用策略模式，如果需要实现差异化的聚合，需要使用组合模式。 我们使用 Step 的时候最好先指定<T,R>。
2025-07-28
Redis 经典用例全解：从数据结构到系统设计
Redis 不只是缓存。它是一把瑞士军刀——凭借五种基础数据结构和若干扩展模块，Redis 能解决从分布式锁到社交网络、从排行榜到消息队列的几乎所有高频系统设计问题。 本文的目标是：建立一套从业务问题到 Redis 数据结构的映射思维。对于每个用例，我们都会回答三个问题： 业务问题是什么？ 需求的本质是什么操作？ 为什么选 Redis？ 相比 MySQL、MQ 等方案，Redis 的优势和代价是什么？ 怎么设计？ 用哪种数据结构，Key 怎么命名，核心命令是什么？ mindmap root((Redis 用例全景)) 基础存储 缓存策略 Cache-Aside 穿透/击穿/雪崩 分布式会话 Session 共享 验证码/短链接 分布式 ID INCR 自增 日期分段 并发控制 分布式锁 SET NX Redlock 看门狗续期 计数器与限流 ...
2025-07-29
Java 集合与系统设计中的扩缩容机制全解析
从 ArrayList 的 1.5 倍扩容到 Redis 的渐进式 Rehash，从线程池的弹性伸缩到 LRU/LFU 的淘汰策略——扩缩容是计算机科学中最普遍的设计模式之一。本文将系统性地梳理 Java 集合框架和分布式系统中的扩缩容机制，揭示它们背后共同的设计哲学。 引言：扩缩容的本质 时间-空间权衡 扩缩容的核心是时间与空间的权衡： 预分配过多空间：浪费内存，但减少扩容次数 预分配过少空间：节省内存，但频繁扩容导致性能下降 均摊分析（Amortized Analysis） 动态数组（如 ArrayList）的扩容看似昂贵（需要复制所有元素），但通过均摊分析可以证明，每次插入操作的均摊时间复杂度仍然是 O(1)。 假设初始容量为 1，每次扩容翻倍。插入 n 个元素时，扩容发生在第 1, 2, 4, 8, …, n 次插入时，总复制次数为： 11 + 2 + 4 + 8 + ... + n = 2n - 1 均摊到 n 次插入，每次插入的均摊成本 = (n + 2n - 1) / n ≈ 3 = O(1)。 Part 1: ArrayList——动态数组的经典实现 内部...
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...
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 顺序写延迟...
