冗余设计核心目标：消除单点故障，当硬件、服务器、网络、存储任一组件失效时，业务不中断或快速恢复；不是简单重复设备，而是从网络、服务器、存储、数据库、应用层逐层做冗余，同时配套故障自动切换机制。
核心原则：分层冗余、故障自动感知、故障自动转移、保留回退能力，冗余不等于无限叠加设备，需要权衡成本与业务可用等级。
一、网络层冗余（最基础，优先做）
网络中断会导致整套架构不可用，常见单点：网卡、网线、交换机、网关。
- 服务器网卡冗余（网卡绑定 Bonding / Teaming）
- 交换机冗余
- 链路冗余
二、应用服务器层冗余（Web / 应用服务）
应用层属于无状态服务，最容易实现冗余，如 Nginx、Tomcat、API 服务。
- 多实例集群 + 负载均衡
- 负载均衡本身也要冗余
- 部署多可用区
三、存储层冗余
存储单点故障会造成数据丢失，分为本地 RAID、共享存储、分布式存储。
- 本地硬盘 RAID
- 共享存储冗余（SAN/NAS）
- 分布式存储（Ceph 等）
重点提醒：RAID / 存储冗余 ≠ 备份。冗余解决硬件故障，备份解决误删除、勒索病毒、逻辑错误。
四、数据库层冗余（最难，有状态服务）
数据库保存核心数据，有状态，切换需要保证数据一致性。
- 主从复制（主备）
- 数据库集群
- 跨机房数据库灾备
五、中间件冗余（Redis、MQ）
中间件同样不能单点：
- Redis：主从 + 哨兵 Sentinel，主节点故障自动切换；核心业务使用 Redis Cluster 集群。
- MQ（RabbitMQ/Kafka）：集群部署，消息持久化，多副本保存消息，节点故障不丢失消息。
六、管理与监控冗余
- 监控系统本身冗余：监控平台不要部署在业务服务器上，独立部署，防止业务机房故障连告警都收不到。
- 管理入口冗余：服务器远程管理 IPMI/iDRAC 走独立管理网络，业务网断了依旧可以登录服务器排查。
七、冗余设计配套机制（光有设备不够）
- 健康检查机制
负载均衡、集群组件持续探测节点状态，识别宕机、端口异常，自动摘除故障节点。 - 故障自动切换（HA）
区分：
- 容量预留
集群预留资源，当一台节点宕机后，剩下节点可以承载全部业务流量，不能满负荷运行。例：3 节点集群，预留 1 节点资源，允许 1 台故障。 - 故障演练
定期混沌测试：手动关闭一台服务器、拔掉网线，验证架构是否真的可以自动切换，业务是否受影响。很多冗余架构只是 “看起来冗余”，实际切换失败。 - 灾备预案
区分：高可用（HA）：解决单机房内部硬件 / 服务器故障；灾难恢复 DR：应对整个机房损毁。
八、冗余设计分级参考
- 普通内部业务：应用多机 + RAID 硬盘，数据库主从，单机故障业务短暂影响。
- 重要线上业务：跨机架 / 跨可用区部署，双 LB，数据库自动主从切换，RTO 分钟级。
- 核心金融类业务：同城双活 + 异地灾备，RTO 秒级，几乎业务无感知。
九、常见坑
- 双网卡接同一台交换机 → 交换机坏，两台网卡同时断，冗余失效。
- 所有服务器供电来自同一个 PDU → PDU 故障，全部宕机。
- 集群资源打满，一台宕机后剩余机器扛不住流量，引发雪崩。
- 只做硬件冗余，没有数据备份，遇到误删、病毒，冗余架构全部同步损坏数据。
- 只搭建架构，不做故障演练，故障发生时切换失败。
总结
冗余设计要自上而下分层：网络冗余 → 应用负载均衡集群 → 存储多副本 → 数据库主备 / 集群 → 监控告警。
无状态服务优先做多实例负载均衡；有状态数据库、存储重点解决数据同步与一致性；冗余架构必须配合故障演练和独立备份。
