高可用

概述 凌晨 2 点 17 分，手机弹出告警：核心机房 A 区网络设备故障，数据库主从同步中断。值班 SRE 切到灾备机房 B 区，发现应用连上新主库后，部分订单数据查不到——异步复制窗口期丢了 47 秒数据。业务恢复用了 38 分钟，超出 RTO 目标 8 分钟。 这是一次真实的容灾切换事故。事后复盘发现，系统设计了容灾架构，配置了数据同步，也写了切换脚本，但真正切换时还是出了问题。问题不在于"有没有灾备"，而在于容灾架构的每个环节是否真正经得起生产级考验。 本文拆解跨机房容灾的核心架构决策，覆盖同城双活、异地灾备、两地三中心三种模式的选型权衡，同步复制的性能代价与脑裂防护，异步复制的窗口期补偿机制，以及故障切换从决策到执行的完整流程。每个环节都附有真实踩坑记录和性能数据。 在我经手过的跨机房容灾方案中，最终达成 RPO<5min、RTO<30min 的指标。这个数字看起来不算极致，但它是成本、稳定性和业务需求三方博弈后的工程最优解——不是理论上的 RPO=0，而是生产环境能跑通、能验证、能回滚的方案。 RPO 和 RTO 的工程真相 不是技术指标，是业务指标 RPO（Recovery Point Objective）和 RTO（Recovery Time Objective）这两个词被技术圈用烂了，但很多人理解反了——它们首先是业务指标，然后才是技术指标。 RPO 回答的是"能容忍丢多少数据"。比如一个电商系统，订单数据的 RPO 必须是 0（不能丢订单），但用户行为日志的 RPO 可以是 1 小时（丢了不影响核心交易）。RTO 回答的是"能容忍停多久"——核心交易系统 RTO 要 <5 分钟，而报表系统的 RTO 可以是 4 小时。 关键认知：不要一刀切。 我见过太多团队把所有系统都按 RPO=0、RTO<1min 设计，结果容灾建设成本翻了好几倍，非核心系统根本不需要这么高的规格。 按业务重要性分级设计容灾目标： 级别 系统类型 RPO 目标 RTO 目标 同步方式 P0 核心交易、支付 0 <5min 同步复制 P1 用户中心、订单查询 <1min <15min 半同步复制 P2 内容管理、报表 <30min <2h 异步复制 P3 日志分析、离线计算 <1h <4h 定时备份 RPO=0 的代价不是线性的 很多人觉得"RPO 越小越好"，但 RPO 从 1 分钟到 0 的成本跳跃是指数级的：...

概述 PostgreSQL 高可用架构：Patroni 与 etcd 集群部署是SRE运维工作中的重要技能。在实际生产环境中，掌握这些技术能够有效提升系统的稳定性和运维效率。 为什么需要PostgreSQL 高可用架构 随着系统规模的扩大和复杂度的增加，传统的运维手段已经难以满足现代分布式系统的需求。PostgreSQL 高可用架构能够帮助运维团队： 快速定位问题：通过系统化的工具和方法，缩短故障排查时间 提升系统可见性：建立全面的监控和可观测性体系 预防故障发生：通过主动发现和修复潜在风险，降低故障率 优化资源利用：合理分配和调度资源，提升系统性能 核心概念与原理 基础概念 PostgreSQL 高可用架构的核心在于建立标准化的流程和自动化的工具链。主要包括以下几个方面： 数据收集与处理：从各种数据源收集指标、日志和追踪信息 分析与可视化：通过仪表盘和告警系统展示系统状态 自动化响应：基于预设规则自动执行修复操作 持续优化：根据历史数据和反馈不断改进流程 关键技术点 1. 配置管理 合理的配置管理是PostgreSQL 高可用架构的基础。建议使用版本控制工具管理配置文件，确保变更可追溯： # 示例：配置版本控制 # 所有配置文件存放在 Git 仓库中 git init /etc/monitoring cd /etc/monitoring git add . git commit -m "Initial monitoring configuration" 2. 自动化工具选择 根据团队技术栈选择合适的工具： 场景 推荐工具 说明 配置管理 Ansible 无代理，适合中小规模 容器编排 Kubernetes 云原生标准 监控告警 Prometheus + Grafana 开源，社区活跃 日志收集 Loki / ELK 轻量或功能丰富 CI/CD GitLab CI / GitHub Actions 与代码托管集成 实践案例 场景：生产环境故障排查 假设线上服务出现响应延迟，排查步骤如下：...

概述 Redis 运维实践：持久化、高可用与性能监控是SRE运维工作中的重要技能。在实际生产环境中，掌握这些技术能够有效提升系统的稳定性和运维效率。 为什么需要Redis 运维实践 随着系统规模的扩大和复杂度的增加，传统的运维手段已经难以满足现代分布式系统的需求。Redis 运维实践能够帮助运维团队： 快速定位问题：通过系统化的工具和方法，缩短故障排查时间 提升系统可见性：建立全面的监控和可观测性体系 预防故障发生：通过主动发现和修复潜在风险，降低故障率 优化资源利用：合理分配和调度资源，提升系统性能 核心概念与原理 基础概念 Redis 运维实践的核心在于建立标准化的流程和自动化的工具链。主要包括以下几个方面： 数据收集与处理：从各种数据源收集指标、日志和追踪信息 分析与可视化：通过仪表盘和告警系统展示系统状态 自动化响应：基于预设规则自动执行修复操作 持续优化：根据历史数据和反馈不断改进流程 关键技术点 1. 配置管理 合理的配置管理是Redis 运维实践的基础。建议使用版本控制工具管理配置文件，确保变更可追溯： # 示例：配置版本控制 # 所有配置文件存放在 Git 仓库中 git init /etc/monitoring cd /etc/monitoring git add . git commit -m "Initial monitoring configuration" 2. 自动化工具选择 根据团队技术栈选择合适的工具： 场景 推荐工具 说明 配置管理 Ansible 无代理，适合中小规模 容器编排 Kubernetes 云原生标准 监控告警 Prometheus + Grafana 开源，社区活跃 日志收集 Loki / ELK 轻量或功能丰富 CI/CD GitLab CI / GitHub Actions 与代码托管集成 实践案例 场景：生产环境故障排查 假设线上服务出现响应延迟，排查步骤如下：...

概述 当你的业务从"服务一个城市"扩展到"服务全国"甚至"服务全球"时，单机房架构会遇到两个硬约束：距离带来的延迟和单点故障的风险。多地域多活架构是解决这两个问题的工程方案。 但多活架构是 SRE 领域最复杂的主题之一——它不是简单的"在两个机房部署服务"，而是涉及数据一致性、流量调度、故障切换、运维复杂度等一系列深层工程挑战。做对了，系统可用性从 99.9% 提升到 99.99%；做错了，多活架构本身就会成为最大的故障源。 从多活架构模式、数据一致性挑战、流量切换策略、容灾 RTO/RPO 设计、跨地域监控到故障切换演练，详细梳理多活架构的可靠性设计。 关于多活架构的深入讨论，可参考 Google SRE Book - Disaster Preparedness 和 AWS - Multi-Region Active-Active Architecture。 一、为什么需要多活架构 单机房架构的局限 单机房架构： ┌── App Server ×N 用户 ──→ DNS/CDN ──→ Load Balancer ─────┼── App Server ×N └── App Server ×N │ ┌─────────┴─────────┐ │ Database (主从) │ └───────────────────┘ 问题： 1. 如果机房断电/网络中断 → 全站不可用 2. 跨地域用户延迟高（北京到广州 ~30ms RTT） 3. 容量受限于单个机房 多活架构的驱动力 驱动力 说明 优先级 容灾 机房级故障时业务不中断 高 低延迟 就近服务用户，降低访问延迟 高 容量扩展 突破单机房容量上限 中 合规要求 数据必须在特定地域存储 视行业 容灾演练要求 监管要求具备跨机房容灾能力 视行业 容灾的关键指标 在设计多活架构之前，必须先明确两个容灾指标：...

概述 Prometheus 默认是单节点架构，这在生产环境中是一个危险的隐患。一个 Prometheus 实例挂掉意味着整个监控体系失明——你无法在故障期间看到任何指标，告警也会因为规则不评估而完全失效。当数据量增长到单机存储和处理能力的极限时，还会面临写入超时、查询缓慢、磁盘爆满等问题。 本文系统性地分析 Prometheus 高可用和水平扩展方案，从最简单的双副本到 Thanos、Mimir、VictoriaMetrics、Cortex 等远程存储方案，帮助你根据实际场景做出正确的技术选型。 参考来源：Prometheus 官方文档 — HA、Thanos 官方文档 一、单点问题分析 1.1 单点 Prometheus 的风险 ┌──────────────┐ ┌───────────────┐ ┌──────────┐ │ Exporters │ ──→ │ Prometheus │ ──→ │ Grafana │ │ (targets) │ │ (单节点) │ │ Alertmgr│ └──────────────┘ └───────────────┘ └──────────┘ │ ┌──────┴──────┐ │ 本地 TSDB │ │ (15-30 天) │ └─────────────┘ 这个架构的脆弱点： 风险点 影响 发生概率 Prometheus 进程崩溃 监控完全中断，告警失效 中 宿主机宕机 同上，且可能丢失最近数据 中 磁盘故障 历史数据丢失 低-中 磁盘空间耗尽 写入失败，数据丢失 中-高 单机内存/CPU 不足 写入延迟、查询超时 高（数据量增长后） 网络分区 部分 target 无法采集 中 1....