不管是硬件故障、机房断电，还是某个服务突然挂掉，单点永远是系统里最脆弱的环节。想让系统在各种意外情况下还能扛得住，最基本也最有效的办法就是 冗余——关键资源多备几份，坏了一份还有其他的顶上。
这篇文章会把冗余设计的核心概念和常见方案梳理一遍：从 RTO/RPO 这两个容灾指标，到高可用集群、同城灾备、异地多活，再到 Redis Sentinel、Keepalived 这些具体的故障转移方案。
什么是冗余？
冗余（Redundancy） 是提升系统可用性和数据持久性的常见手段，其核心思想是 通过部署多份相同的资源，当某一份资源出现故障时，其他资源可以接管其工作，从而保证系统的持续可用。
冗余是提升系统可用性的基础手段，但冗余本身不等于高可用。只有配合故障检测、流量切换、数据复制、恢复演练和监控告警，才能真正降低故障影响。
冗余设计可以从以下几个维度来理解：
冗余类型说明典型实现硬件冗余关键硬件设备部署多份双电源、双网卡、RAID软件冗余应用服务部署多个实例集群部署、容器化多副本数据冗余数据存储多份副本数据库主从复制、分布式存储多副本网络冗余网络链路和设备冗余多运营商接入、双核心交换机、双链路、负载均衡主备或多实例部署地域冗余在不同地理位置部署系统同城灾备、异地灾备、同城多活、异地多活
冗余类型说明典型实现
冗余类型
说明
典型实现
硬件冗余关键硬件设备部署多份双电源、双网卡、RAID
硬件冗余
关键硬件设备部署多份
双电源、双网卡、RAID
软件冗余应用服务部署多个实例集群部署、容器化多副本
软件冗余
应用服务部署多个实例
集群部署、容器化多副本
数据冗余数据存储多份副本数据库主从复制、分布式存储多副本
数据冗余
数据存储多份副本
数据库主从复制、分布式存储多副本
网络冗余网络链路和设备冗余多运营商接入、双核心交换机、双链路、负载均衡主备或多实例部署
网络冗余
网络链路和设备冗余
多运营商接入、双核心交换机、双链路、负载均衡主备或多实例部署
地域冗余在不同地理位置部署系统同城灾备、异地灾备、同城多活、异地多活
地域冗余
在不同地理位置部署系统
同城灾备、异地灾备、同城多活、异地多活
服务冗余：同一个服务部署两个或多个实例，故障时自动切换到健康实例，大大减少系统的不可用时间，提高系统的可用性。
数据冗余：同一数据存储多份副本，任一副本丢失仍可从其他副本恢复，从而提升数据持久性与可用性。
实际上，日常生活中也有很多冗余设计的例子。拿我自己来说，我对于重要文件的保存方法就是冗余思想的应用。我日常所使用的重要文件都会同步一份在 GitHub 以及个人云盘上，这样就可以保证即使电脑硬盘损坏，我也可以通过 GitHub 或者个人云盘找回自己的重要文件。
容灾核心指标：RTO 和 RPO
在讨论容灾架构之前，需要先理解两个核心指标：
RPO（Recovery Point Objective，恢复点目标）：系统在灾难发生后可接受的数据丢失窗口，也可以理解为恢复时数据最多允许回退到多久之前。RPO 越小，对同步复制、日志复制、跨站点一致性和写入延迟的要求越高。RPO = 0 通常意味着写入必须在多个故障域确认后才能返回，或者有等价的强一致提交机制；代价是写入延迟上升，并且在网络分区时需要在可用性和一致性之间做取舍。
RTO（Recovery Time Objective，恢复时间目标）：可容忍的 最大恢复时间，即从故障发生到系统恢复正常服务的时间。RTO=0 表示目标上不允许可感知中断，但在真实系统中更常见的表述是接近 0 或用户无感切换，仍要看故障检测、流量切换和客户端重试行为。
RTO/RPO 是目标，不是结果。它们是业务对容灾能力的约束，实际恢复能力取决于故障检测速度、切换自动化程度、数据复制延迟、人工流程和运维能力。声明了某个 RPO/RTO 不等于生产环境一定能做到，必须通过定期演练和压测来验证。另外，不同业务链路可以有不同的 RTO/RPO 要求，不必全站统一。
RTO/RPO 是目标，不是结果。它们是业务对容灾能力的约束，实际恢复能力取决于故障检测速度、切换自动化程度、数据复制延迟、人工流程和运维能力。声明了某个 RPO/RTO 不等于生产环境一定能做到，必须通过定期演练和压测来验证。另外，不同业务链路可以有不同的 RTO/RPO 要求，不必全站统一。
下面的 RPO/RTO 是典型配置下的 量级参考，实际结果取决于复制方式（同步/异步）、故障检测阈值、切换自动化程度和团队运维能力。多活是否能做到秒级 RTO/RPO，取决于流量调度、数据复制、故障检测、客户端重试、冲突解决和演练成熟度。
架构方案RPORTO成本单机无备份可能全部丢失不可预估低本地备份取决于备份周期小时级低同城灾备秒级～分钟级分钟～小时级中异地灾备分钟～小时级小时级中高同城多活秒级秒级高异地多活秒级秒级很高
架构方案RPORTO成本
架构方案
RPO
RTO
成本
单机无备份可能全部丢失不可预估低
单机无备份
可能全部丢失
不可预估
低
本地备份取决于备份周期小时级低
本地备份
取决于备份周期
小时级
低
同城灾备秒级～分钟级分钟～小时级中
同城灾备
秒级～分钟级
分钟～小时级
中
异地灾备分钟～小时级小时级中高
异地灾备
分钟～小时级
小时级
中高
同城多活秒级秒级高
同城多活
秒级
秒级
高
异地多活秒级秒级很高
异地多活
秒级
秒级
很高
冗余架构方案对比
高可用集群（High Availability Cluster，简称 HA Cluster）、同城灾备、异地灾备、同城多活和异地多活是冗余思想在高可用系统设计中最典型的应用。
高可用集群
高可用集群 是指同一个服务部署两个或多个实例，当正在使用的服务突然挂掉的话，可以切换到另外一台服务，从而保证服务的高可用。
高可用集群有两种常见模式：
模式说明优点缺点主备模式（Active-Standby）主节点提供服务，备节点待命实现简单，单主写入易控制资源利用率低，备节点闲置主主模式（Active-Active）多个节点同时提供服务资源利用率高，无单点故障写入冲突需要应用层解决；自增 ID、唯一约束等可能冲突
模式说明优点缺点
模式
说明
优点
缺点
主备模式（Active-Standby）主节点提供服务，备节点待命实现简单，单主写入易控制资源利用率低，备节点闲置
主备模式（Active-Standby）
主节点提供服务，备节点待命
实现简单，单主写入易控制
资源利用率低，备节点闲置
主主模式（Active-Active）多个节点同时提供服务资源利用率高，无单点故障写入冲突需要应用层解决；自增 ID、唯一约束等可能冲突
主主模式（Active-Active）
多个节点同时提供服务
资源利用率高，无单点故障
写入冲突需要应用层解决；自增 ID、唯一约束等可能冲突
主备模式通常更容易控制写入路径；如果是同步复制，一致性更好但写延迟更高；如果是异步复制，切换时可能丢失尚未复制的数据。高可用集群单纯是服务的冗余，并没有强调地域。同城灾备、异地灾备、同城多活和异地多活实现了地域上的冗余。
同城灾备
同城灾备 不是简单地将服务冗余部署在同一个机房内，而是将主服务和备用服务分别部署在 同一个城市的不同机房 中。同城灾备通常指主备站点位于同一城市不同机房，常见形态是 active/passive：主站点处理生产流量，备站点平时不承载或只承载少量验证流量，故障时接管。具体是冷备、温备还是热备，要看成本和 RTO 要求。
这样可以避免单个机房出现停电、火灾等故障时导致服务完全不可用。
适用场景：对 RTO 要求较高（分钟级），成本有限的企业。
典型配置：同城双机房距离和延迟没有统一标准，通常需要通过专线时延、故障域隔离、供电和运营商路径独立性来评估。同步复制是否可接受，要以实际 RTT 和写入延迟预算为准。
异地灾备
异地灾备 类似于同城灾备，不同的是，相同服务部署在 异地（通常距离较远，甚至是在不同的城市或者国家）的不同机房中。
适用场景：需要防范区域性灾难（地震、洪水）的核心业务系统。
挑战：网络延迟较大，数据同步通常采用异步方式，可能存在数据丢失。
同城多活
同城多活 类似于同城灾备，但不再区分纯主备，多个同城机房都可以承载生产流量，这样可以充分利用系统资源，提高系统的并发。
适用场景：对性能和可用性都有较高要求的系统。
技术要点：需要解决数据同步、流量调度、会话管理等问题。
异地多活
异地多活 将服务部署在 异地的不同机房 中，并且，它们可以 同时对外提供服务。
和传统的灾备设计相比，同城多活和异地多活最明显的改变在于 "多活"，即所有站点都是同时在对外提供服务的。异地多活是为了应对突发状况，比如火灾、地震等自然或者人为灾害，以及区域性网络中断、机房级故障、合规要求等场景。
同城和异地的主要区别在于 机房之间的距离。异地通常距离较远，甚至是在不同的城市或者国家。
冷备 / 温备 / 热备 / 多活的层次
从容灾等级来看，从低到高可以形成如下连续光谱：
容灾等级资源状态恢复速度成本典型场景冷备备用资源未运行，需手动启动小时～天低非核心业务温备部分资源常驻运行，需扩容接管分钟级中一般业务容灾热备资源和数据持续同步，可快速切换秒～分钟高核心业务多活多站点同时承载生产流量接近实时很高对可用性要求极高的核心业务
容灾等级资源状态恢复速度成本典型场景
容灾等级
资源状态
恢复速度
成本
典型场景
冷备备用资源未运行，需手动启动小时～天低非核心业务
冷备
备用资源未运行，需手动启动
小时～天
低
非核心业务
温备部分资源常驻运行，需扩容接管分钟级中一般业务容灾
温备
部分资源常驻运行，需扩容接管
分钟级
中
一般业务容灾
热备资源和数据持续同步，可快速切换秒～分钟高核心业务
热备
资源和数据持续同步，可快速切换
秒～分钟
高
核心业务
多活多站点同时承载生产流量接近实时很高对可用性要求极高的核心业务
多活
多站点同时承载生产流量
接近实时
很高
对可用性要求极高的核心业务
不同业务可以采用不同等级，不必全系统追求多活。关键在于根据业务影响面、故障概率和建设成本做取舍。
故障转移机制
光有冗余还不够，还需要配合 故障转移（Failover） 机制。所谓故障转移，简单来说就是 将流量从故障节点快速切换到健康节点。
故障转移可以是自动的，也可以是自动检测后人工确认。对无状态服务和缓存系统，通常追求自动切换；对数据库主切、跨地域切流、资金链路等高风险场景，很多团队会保留人工确认或审批步骤。
故障转移通常包含以下几个步骤：
故障检测：通过心跳检测、健康检查等机制发现故障节点。检测阈值要权衡误判和漏判，太敏感容易误切，太保守会延长故障时间。
故障确认：避免误判，通常需要多次检测确认，并通过多数派投票、仲裁节点或租约机制防止脑裂。
故障切换：将流量切换到备用节点。
故障通知：发送告警通知运维人员。
故障恢复：故障节点恢复后重新加入集群。
对于有状态系统，还需要 fencing 机制，确保旧主在失联或恢复后不能继续对共享资源写入。否则即使新主切换成功，也可能出现双主写入和脑裂问题。常见手段包括 fencing token、STONITH（Shoot The Other Node In The Head）、写入令牌和租约。故障恢复后旧主不能直接重新加入写路径，需要先同步数据并通过仲裁确认。
Redis 哨兵模式示例
Redis Sentinel 可以监控 primary（旧文档中也常称 master）节点，在多数 Sentinel 判断 primary 故障后选举并提升某个 replica（旧文档中也常称 slave）为新的 primary；但它不保证 RPO=0。由于 Redis 复制通常是异步的，故障切换时可能丢失尚未复制到 replica 的数据。
生产常见部署至少 3 个 Sentinel。需要注意 quorum 只表示多少 Sentinel 同意 primary 客观下线；实际发起 failover 还涉及 Sentinel 多数派和 leader 选举，因此不要把 quorum 简单理解成 Sentinel 总数的一半。重点关注 down-after-milliseconds（实例不可达多久后被认为下线）、failover-timeout（failover 超时时间）等参数。
down-after-millisecondsfailover-timeout生产环境使用 Redis Sentinel 时，建议关注以下观测指标：
指标类别具体指标复制延迟replica 相对 primary 的 replication lag故障检测down-after-milliseconds 触发次数切换耗时failover 从触发到完成的时间客户端感知客户端重连耗时、主从切换期间写失败率集群状态Sentinel quorum / majority 状态、Sentinel 节点存活
指标类别具体指标
指标类别
具体指标
复制延迟replica 相对 primary 的 replication lag
复制延迟
replica 相对 primary 的 replication lag
故障检测down-after-milliseconds 触发次数
故障检测
down-after-milliseconds 触发次数
down-after-milliseconds切换耗时failover 从触发到完成的时间
切换耗时
failover 从触发到完成的时间
客户端感知客户端重连耗时、主从切换期间写失败率
客户端感知
客户端重连耗时、主从切换期间写失败率
集群状态Sentinel quorum / majority 状态、Sentinel 节点存活
集群状态
Sentinel quorum / majority 状态、Sentinel 节点存活
Nginx + Keepalived 示例
Nginx 可以结合 Keepalived 来实现高可用。Keepalived 基于 VRRP 管理 VIP，可以让 VIP 在主备节点之间漂移，解决入口 IP 高可用问题。如果 Nginx 主服务器宕机的话，Keepalived 可以基于 VRRP 协议自动进行故障转移，备用 Nginx 服务器升级为主服务。由于使用的是 虚拟 IP（VIP），对外 IP 不会改变。
需要注意的是：
Keepalived 不保证已有 TCP 连接无损迁移，切换还受 ARP / 邻居表刷新、二层网络、云厂商 VIP 支持和健康检查脚本影响。
适合单机房或同二层网络下 VIP 漂移，不适合直接解决跨地域流量调度。
云环境下要确认是否支持自定义 VIP 和 ARP / 路由切换。
健康检查脚本要检查 Nginx 进程和业务端口，而不只是 Keepalived 进程本身。
生产中还要根据业务选择抢占或非抢占模式，避免主节点恢复后发生不必要的二次切换。
异地多活的挑战
异地多活架构实施起来非常难，需要考虑的因素非常多：
挑战说明解决思路数据一致性多个机房数据如何保持一致单元化路由、最终一致性、TCC/Saga、冲突解决机制网络延迟异地机房之间网络延迟较大就近接入、数据分区流量调度如何将用户请求分配到合适的机房DNS 智能解析、GSLB会话管理用户会话如何在多机房之间共享优先做无状态设计或按用户单元路由固定到同一站点；跨地域共享 session 虽然可行，但会引入延迟、一致性和故障隔离问题成本多机房建设和运维成本高按业务重要性分级部署
挑战说明解决思路
挑战
说明
解决思路
数据一致性多个机房数据如何保持一致单元化路由、最终一致性、TCC/Saga、冲突解决机制
数据一致性
多个机房数据如何保持一致
单元化路由、最终一致性、TCC/Saga、冲突解决机制
网络延迟异地机房之间网络延迟较大就近接入、数据分区
网络延迟
异地机房之间网络延迟较大
就近接入、数据分区
流量调度如何将用户请求分配到合适的机房DNS 智能解析、GSLB
流量调度
如何将用户请求分配到合适的机房
DNS 智能解析、GSLB
会话管理用户会话如何在多机房之间共享优先做无状态设计或按用户单元路由固定到同一站点；跨地域共享 session 虽然可行，但会引入延迟、一致性和故障隔离问题
会话管理
用户会话如何在多机房之间共享
优先做无状态设计或按用户单元路由固定到同一站点；跨地域共享 session 虽然可行，但会引入延迟、一致性和故障隔离问题
成本多机房建设和运维成本高按业务重要性分级部署
成本
多机房建设和运维成本高
按业务重要性分级部署
异地多活的核心取舍可以用 CAP 来理解：跨地域网络延迟和分区不可避免，系统必须在强一致性和可用性之间取舍。但异地多活的工程难点不仅限于 CAP，还包括跨地域延迟、流量调度、数据分片、冲突解决、成本、合规和演练复杂度。常见做法是按用户或地域做单元化分片，让大部分读写落在同一机房；跨单元操作再通过 TCC / Saga、对账补偿或业务冲突解决保证最终一致。
并不是所有业务都需要异地多活。以下类型的业务要慎重评估：
强一致写入频繁且跨地域冲突多的业务
无法按用户 / 地域 / 租户切分的数据模型
对账补偿能力不足的资金链路
团队没有演练和运维能力支撑
建设成本高于故障损失预期的系统
通常要按业务影响面、故障概率、建设成本综合评估。
如果你想要深入学习异地多活相关的知识，推荐以下资料：
搞懂异地多活，看这篇就够了 - 水滴与银弹 - 2021
四步构建异地多活
《从零开始学架构》— 28 | 业务高可用的保障：异地多活架构
《从零开始学架构》— 28 | 业务高可用的保障：异地多活架构
写在最后
如果内容对你有帮助的话，欢迎顺手给 JavaGuide 点一个免费的 Star 支持一下：GitHub | Gitee。
JavaGuide 已持续维护近七年，累计 6100+ 次提交，来自 620+ 位贡献者共同完善。你的 Star、反馈和 PR，都是这个项目继续更新的动力。
如果你正在准备后端/AI 应用开发面试，也可以了解一下我的知识星球，里面包括后端和 AI 实战项目、简历优化、一对一提问和高频考点资料，已经持续维护六年。