SRE-谷歌运维揭秘
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2025-07-29
Java 集合框架完全指南
Java 集合框架完全指南 本文系统性地介绍 Java 集合框架的核心概念、实现原理和设计模式。内容涵盖集合框架体系结构、列表与队列机制、哈希表家族的扩缩容策略、缓存淘汰算法实现以及系统级扩缩容设计。通过深入分析源码实现和性能特征，帮助理解各集合类的适用场景和最佳实践。 第一章：全景导图 文章结构 mindmap root((Java集合框架完全指南)) 集合框架体系 Iterable接口 Collection体系 Map体系 Sorted接口 Navigable接口 抽象类层次 列表与队列 ArrayList扩缩容 队列六操作 PriorityQueue DelayQueue Deque体系 哈希表家族 HashMap结构 扩容机制 扰动函数 树化反树化 ConcurrentHashMap LinkedHashMap EnumSet/Ma...
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 顺序写延迟...
2025-07-28
Redis 经典用例全解：从数据结构到系统设计
Redis 不只是缓存。它是一把瑞士军刀——凭借五种基础数据结构和若干扩展模块，Redis 能解决从分布式锁到社交网络、从排行榜到消息队列的几乎所有高频系统设计问题。 本文的目标是：建立一套从业务问题到 Redis 数据结构的映射思维。对于每个用例，我们都会回答三个问题： 业务问题是什么？ 需求的本质是什么操作？ 为什么选 Redis？ 相比 MySQL、MQ 等方案，Redis 的优势和代价是什么？ 怎么设计？ 用哪种数据结构，Key 怎么命名，核心命令是什么？ mindmap root((Redis 用例全景)) 基础存储 缓存策略 Cache-Aside 穿透/击穿/雪崩 分布式会话 Session 共享 验证码/短链接 分布式 ID INCR 自增 日期分段 并发控制 分布式锁 SET NX Redlock 看门狗续期 计数器与限流 ...
2020-07-12
软件方法
建模带来竞争优势。 前言 “唱曲的名家，唱到极快处，吐字依然干净利落”。 不能站在别人的肩膀上看得更远，只是摘抄别人的观点，无意义。要有足够的积累，和深度的思考。 涉众（stakeholder）往往会做而不会定义，把不同类型的涉众放在一起访谈时，只会剩下在场军衔最高那个人的意见。 需求变更的时候，要注意涉众利益角度分析。 项目的流程步骤： 寻找老大 揣摩愿景 业务建模 系统用例 需求规约 分析模型 设计开发 只有一个领域（核心域）的知识是系统能在市场上生存的理由。 拿来主义要摒除门户之见，不关注流派和风格，着力于细节和应用。 建模与 uml 利润 = 需求 - 设计 需求：提升销售 设计：降低开发维护成本 几种弊习： 从需求直接映射设计，会得到大量的重复代码。 从设计出发来定义需求，会得到一堆假的“需求”。 从涉众视角对系统功能分包会得到需求包。 子系统是基于内部视角根据系统部件的耦合和内聚情况进行切割。 需求 设计 卖的视角 做的视角 具体 抽象 产品当项目做 项目当产品做 设计源于需求，高于需求 建模工作流 业务建模：描述组织...
2025-08-01
Grokking the System Design
设计一个电梯系统 项目链接 myElevator 思路 1. 这道题考察候选人的什么知识？ 面试官不是真的想让候选人造一台电梯，而是想通过这个问题评估候选人的综合能力，主要包括： 需求分析与沟通能力：这是最重要的一点。一个优秀的工程师在动手前，会先问问题，明确需求和边界。直接埋头开始写代码的候选人通常会失分。 面向对象设计 (OOD) 能力：这个问题是考察OOD的绝佳场景。如何将现实世界的实体（电梯、楼层、按钮、乘客）抽象成清晰、低耦合的对象和类？ 算法与数据结构：电梯调度策略是整个系统的核心，这直接考察候选人的算法设计能力。如何选择合适的数据结构来存储和处理请求，以实现高效的调度？ 状态机建模能力：电梯的运行本身就是一个状态机（静止、上升、下降、开门、关门等）。能否清晰地定义这些状态以及它们之间的转换条件，是衡量逻辑思维严谨性的关键。 并发与同步问题：多部电梯、多个乘客请求，这些都是并发场景。候选人是否能意识到可能存在的竞态条件（Race Condition）和资源同步问题？ 系统扩展性 (Scalability)：设计是只针对一台电梯，还是一个拥有多台电梯的系统？如何将单...
2026-04-01
Compound Engineering：当 AI 工程从"模型调优"走向"系统组合"
2024 年之前，AI 工程的核心问题是"怎么让模型更好"。2024 年之后，核心问题变成了"怎么让多个组件协作得更好"。这个转变的名字叫 Compound AI Systems，而围绕它的工程学科叫 Compound Engineering。本文从"为什么单体模型不够"出发，系统梳理复合 AI 系统的架构模式、工程实践和与其他 Engineering 概念的关系。 一个类比秒懂 Compound Engineering 在讲技术之前，先用一个类比。 想象你要建一座现代化医院： 单体模型思维就像雇一个全科天才医生，让他一个人看所有病人——内科、外科、眼科、牙科全包。他确实很聪明，但一个人的精力和专业深度终究有限。 Compound AI Systems 思维就像建一个多科室协作的医院系统：有分诊台（路由器）、各科室的专科医生（专用模型）、病历档案室（检索器）、化验室（外部工具）、会诊机制（多智能体协作）。每个组件做自己最擅长的事，通过协作协议连接在一起。 Compound Engineering 就是设计和运营这...
