SRE-谷歌运维揭秘
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-05-14
缓存系统设计全景——从原理到生产的完整指南
缓存是提升系统性能的第一利器，但也是引发故障的第一杀手。从缓存穿透、击穿、雪崩三大经典问题，到多级缓存架构、分布式锁、热点 Key 治理，缓存设计几乎贯穿后端工程师的整个职业生涯。 本文将系统性地剖析缓存系统的设计原则与生产实践，从单机进程内缓存到分布式 Redis 集群，从理论模型到可落地的代码方案，构建一套完整的缓存知识体系。 mindmap root((缓存架构)) 何时使用 读多写少 热点集中 可容忍最终一致性 缓存层次 近端缓存 Guava Caffeine EhCache 远端缓存 Redis Memcached 核心挑战 更新策略 Cache Aside Read Through Write Through Write Behind 一致性保障 故障防护 击穿防护 雪崩防...
2025-07-29
Java 集合框架完全指南
Java 集合框架完全指南 本文系统性地介绍 Java 集合框架的核心概念、实现原理和设计模式。内容涵盖集合框架体系结构、列表与队列机制、哈希表家族的扩缩容策略、缓存淘汰算法实现以及系统级扩缩容设计。通过深入分析源码实现和性能特征，帮助理解各集合类的适用场景和最佳实践。 第一章：全景导图 文章结构 mindmap root((Java集合框架完全指南)) 集合框架体系 Iterable接口 Collection体系 Map体系 Sorted接口 Navigable接口 抽象类层次 列表与队列 ArrayList扩缩容 队列六操作 PriorityQueue DelayQueue Deque体系 哈希表家族 HashMap结构 扩容机制 扰动函数 树化反树化 ConcurrentHashMap LinkedHashMap EnumSet/Ma...
2026-04-01
Compound Engineering：当 AI 工程从"模型调优"走向"系统组合"
2024 年之前，AI 工程的核心问题是"怎么让模型更好"。2024 年之后，核心问题变成了"怎么让多个组件协作得更好"。这个转变的名字叫 Compound AI Systems，而围绕它的工程学科叫 Compound Engineering。本文从"为什么单体模型不够"出发，系统梳理复合 AI 系统的架构模式、工程实践和与其他 Engineering 概念的关系。 一个类比秒懂 Compound Engineering 在讲技术之前，先用一个类比。 想象你要建一座现代化医院： 单体模型思维就像雇一个全科天才医生，让他一个人看所有病人——内科、外科、眼科、牙科全包。他确实很聪明，但一个人的精力和专业深度终究有限。 Compound AI Systems 思维就像建一个多科室协作的医院系统：有分诊台（路由器）、各科室的专科医生（专用模型）、病历档案室（检索器）、化验室（外部工具）、会诊机制（多智能体协作）。每个组件做自己最擅长的事，通过协作协议连接在一起。 Compound Engineering 就是设计和运营这...
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-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...
2020-07-12
软件方法
建模带来竞争优势。 前言 “唱曲的名家，唱到极快处，吐字依然干净利落”。 不能站在别人的肩膀上看得更远，只是摘抄别人的观点，无意义。要有足够的积累，和深度的思考。 涉众（stakeholder）往往会做而不会定义，把不同类型的涉众放在一起访谈时，只会剩下在场军衔最高那个人的意见。 需求变更的时候，要注意涉众利益角度分析。 项目的流程步骤： 寻找老大 揣摩愿景 业务建模 系统用例 需求规约 分析模型 设计开发 只有一个领域（核心域）的知识是系统能在市场上生存的理由。 拿来主义要摒除门户之见，不关注流派和风格，着力于细节和应用。 建模与 uml 利润 = 需求 - 设计 需求：提升销售 设计：降低开发维护成本 几种弊习： 从需求直接映射设计，会得到大量的重复代码。 从设计出发来定义需求，会得到一堆假的“需求”。 从涉众视角对系统功能分包会得到需求包。 子系统是基于内部视角根据系统部件的耦合和内聚情况进行切割。 需求 设计 卖的视角 做的视角 具体 抽象 产品当项目做 项目当产品做 设计源于需求，高于需求 建模工作流 业务建模：描述组织...
