SRE-谷歌运维揭秘
Created|Updated|基础设施
|Word Count:8|Reading Time:1mins|Post Views:
Author: magicliang
Link: https://magicliang.github.io/2021/09/15/SRE-%E8%B0%B7%E6%AD%8C%E8%BF%90%E7%BB%B4%E6%8F%AD%E7%A7%98/
Copyright Notice: 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 集合框架的核心概念、实现原理和设计模式。内容涵盖集合框架体系结构、列表与队列机制、哈希表家族的扩缩容策略、缓存淘汰算法实现以及系统级扩缩容设计。通过深入分析源码实现和性能特征,帮助理解各集合类的适用场景和最佳实践。 第一章:全景导图 文章结构 模式总览 模式名 口诀 覆盖场景 扩容因子1.5倍 扩容1.5倍,平衡空间时间 ArrayList扩容、StringBuilder扩容 队列六操作 add/offer/put,peek,poll/take 所有队列实现的标准操作 优先级堆 小顶堆TopK,大顶堆调度 PriorityQueue、任务调度 延迟队列 getDelay负值出队,compareTo排序 DelayQueue、缓存过期、订单超时 扰动函数 高16异或低16,分散哈希冲突 HashMap哈希优化 2的幂容量 位运算取余,快速计算索引 HashMap、ConcurrentHashMap 树化阈值8 泊松分布概率,红黑树优化 HashMap性能优化 反树化阈值6 低于阈值退...
2026-06-20
生产运维:集群扩缩、监控指标与故障排查
上一篇解决了安全体系的认证、授权与加密。这一篇进入生产运维。 生产运维容易被理解为"改配置 + 重启"。更准确的说法是:Kafka 集群的运维本质上是对分布式日志的分区所有权、副本状态和元数据的受控迁移,每一步操作都在改变哪些 broker 持有哪些 partition 的哪个角色。 本文只抓三个问题:如何安全地扩缩 broker,应该盯哪些 JMX 指标,以及遇到常见故障时从哪里开始排查。 集群扩缩容模型 Kafka 集群的 broker 状态可以用一个简化模型描述: 123456789101112当前集群: [broker-0, broker-1, broker-2]partition 分布: topic-A-0 -> leader=0, follower=[1,2] topic-A-1 -> leader=1, follower=[0,2]加 broker-3 后: broker-3 加入集群,无 partition -> 手动触发 partition reassignment topic-A-0 -> leader=0...
2026-04-14
Anthropic Managed Agents 深度研究:解耦大脑与双手的架构哲学
原文链接:Scaling Managed Agents: Decoupling the brain from the hands 研究时间:2026-04-14 研究方法:多轮迭代搜索 + 交叉验证 + 结构化综合 前言:从"程序即未设想之物"说起 Anthropic 在 2026 年 4 月发布的 Managed Agents 服务,解决了一个经典的计算机科学问题:如何为"尚未设想的程序"设计系统。 这个问题的答案,早在几十年前操作系统设计时就已经给出——通过虚拟化硬件为通用抽象(进程、文件),使得 read() 系统调用既能访问 1970 年代的磁盘组,也能访问现代 SSD。抽象层保持稳定,底层实现自由演进。 Managed Agents 做了同样的事情:将 Agent 组件虚拟化为三个核心组件——Session(追加式事件日志)、Harness(调用 Claude 并将工具调用路由到相关基础设施的循环)、Sandbox(Claude 可以运行代码和编辑文件的执行环境),并在此基础上通过**两个扩展维度——Many Brains(多...
2026-07-13
动态资源分配与作业调度:多租户集群的资源博弈
上一篇解决了 Spark 在 YARN 和 K8s 上的部署模式。这一篇进入资源调度——在多个作业共享集群时,Spark 如何动态分配和回收资源。 默认情况下,一个 Spark 应用在启动时申请固定数量的 Executor,作业结束前一直占用。这在单用户开发环境下可以接受,在多租户生产集群中会造成严重的资源浪费——一个空闲的 Spark 应用占着 100 个 Executor 不释放,其他作业排队等待。 本文只抓一个问题:动态资源分配如何按需申请和释放 Executor,以及 FAIR 调度器如何在多个作业之间公平分配资源。 动态资源分配(DRA) Dynamic Resource Allocation(DRA)允许 Spark 应用根据工作负载动态增减 Executor 数量:有 pending Task 时申请新 Executor,Executor 空闲超时后释放。 12345678910111213141516作业生命周期中的 Executor 数量变化: Executor 数量 8 │ ┌────┐ 6 │ ┌────┤ ├──...
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
设计一个亿级 IM 即时通讯系统
如何设计一个支撑亿级用户的即时通讯(IM)系统?这是系统设计面试中最经典的题目之一,也是实际工程中最复杂的分布式系统之一。本文将从需求分析出发,逐步构建一个完整的 IM 系统架构,涵盖长连接管理、消息投递、在线状态、多设备同步、群聊优化等核心问题。 Part 1: 需求分析与容量估算 功能需求 功能 优先级 说明 单聊 P0 一对一实时消息 群聊 P0 多人群组消息(最大 500 人) 在线状态 P1 显示用户是否在线 消息已读 P1 已读/未读状态 多设备同步 P1 手机、电脑、平板同时在线 离线消息 P0 离线用户上线后拉取未读消息 消息类型 P0 文本、图片、语音、视频、文件 消息搜索 P2 全文搜索历史消息 推送通知 P1 离线时通过 APNs/FCM 推送 非功能需求 指标 目标 DAU 1 亿 同时在线 2000 万 消息延迟 P99 < 200ms 消息可靠性 不丢消息(at-least-once) 消息有序性 单会话内有序 可用性 99.99%(全年停机 < 53 ...
Announcement
人生只是,守株待兔

