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

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
设计一个亿级 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 ...

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-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
Java 集合框架完全指南
Java 集合框架完全指南 本文系统性地介绍 Java 集合框架的核心概念、实现原理和设计模式。内容涵盖集合框架体系结构、列表与队列机制、哈希表家族的扩缩容策略、缓存淘汰算法实现以及系统级扩缩容设计。通过深入分析源码实现和性能特征,帮助理解各集合类的适用场景和最佳实践。 第一章:全景导图 文章结构 mindmap root((Java集合框架完全指南)) 集合框架体系 Iterable接口 Collection体系 Map体系 Sorted接口 Navigable接口 抽象类层次 列表与队列 ArrayList扩缩容 队列六操作 PriorityQueue DelayQueue Deque体系 哈希表家族 HashMap结构 扩容机制 扰动函数 树化反树化 ConcurrentHashMap LinkedHashMap EnumSet/Ma...

2026-05-14
缓存系统设计全景——从原理到生产的完整指南
缓存是提升系统性能的第一利器,但也是引发故障的第一杀手。从缓存穿透、击穿、雪崩三大经典问题,到多级缓存架构、分布式锁、热点 Key 治理,缓存设计几乎贯穿后端工程师的整个职业生涯。 本文将系统性地剖析缓存系统的设计原则与生产实践,从单机进程内缓存到分布式 Redis 集群,从理论模型到可落地的代码方案,构建一套完整的缓存知识体系。 mindmap root((缓存架构)) 何时使用 读多写少 热点集中 可容忍最终一致性 缓存层次 近端缓存 Guava Caffeine EhCache 远端缓存 Redis Memcached 核心挑战 更新策略 Cache Aside Read Through Write Through Write Behind 一致性保障 故障防护 击穿防护 雪崩防...
Announcement
人生只是,守株待兔

