A characteristic of a system that aims to ensure an agreed level of operational performance (uptime) for a higher-than-normal period. It is an emergent property​ achieved through redundancy, fault tolerance, and graceful degradation, often implemented within a Distributed System​ architecture. It is a key goal that influences architectural decisions.

首先什么是HA，

最严格的ha就是主主（双活或多活），都负责读写，对于数据库来说，写操作需要通知到所有节点，这种一般是利用共识算法来达成一致性，区块链是极限的HA，参考我的文章《distributed_system》；

其次是主备（热备 hot standby），主负责读写，备只是read only；

接着就是主备（温备 warm standby），主负责读写，备只是负责replication，不参与读写，注意温备实际上只是提供了disaster recovery，并不是真正的HA

这三种种都是自动切换，zero downtime；

然后是主备（冷备），手动切换；

最次是backup restore；

load balance VS HA

高可用不一定是负载均衡的，比如主备模式，只有主在干活，多活模式也是要具体看：

load balance强调traffic load balance，或者work load balance，是否高可用呢，这就要看是不是简单的分流还是智能分流，比如123交给A做，456交给B做，那A挂了之后，如果是简单的分流，那123就不会智能的重新分配给B，A上的数据就会丢失，如果是智能分流，A挂了之后，B会接管则数据就不容易丢失（也不能保证不丢失，要具体看），比如kafka集群就是高可用的负载均衡； 换言之，具体要看集群或多节点的一致性算法，如果没有一致性算法保证就只能是普通的分流，如果有就是所谓的高可用；

有无状态？

如果无状态，简单的failover即可，若是有状态则要考虑数据

high availability强调consistency，但是failover时数据也可能会因为不同的策略丢失掉某个时间窗口的数据；

Disaster Recovery强调的是在发生重大灾难事件时，至少大部分的数据还在，并不强调立刻恢复或者自动切换；

7*24

当要求一个系统支持“7乘24小时”不间断运行时，这确实是 高可用性（High Availability, HA）​ 最核心和最典型的目标,实现方式:

  1. 减少停工时间​ 追求极致的可用性百分比（SLA），例如“4个9”（99.99%）的可用性意味着全年停机时间不能超过约53分钟。通过冗余设计（集群化）和自动故障转移来消除单点故障（SPOF）。
  2. 自动化容错​ 系统在组件发生故障时，能够自动检测、切换并恢复，无需或极少需要人工干预。在各层（如负载均衡、服务、数据库）部署健康检查和管理员，实现故障的自动发现与流量切换。
  3. 应对多种风险​ 不仅针对硬件故障，还需应对软件Bug、部署更新、突发流量、人为失误等导致的不可用。采用限流、降级、熔断、蓝绿部署等技术，保证核心业务在压力下的可用性。

业务层面

首先要明确 7*24 的含义，比如该系统是否要面向互联网用户，如果是比如交易系统或互联网应用，需要时刻接受用户的请求并响应，但是如果该系统是面向内部的，比如交易系统的下游系统清算系统，如果不强调非常实时的处理，其实是并不需要做到时刻响应的

硬件层面

磁盘空间：比如日志的定期备份清理，数据库历史数据的备份清理，缓存数据的有效时间等，并且清理不能影响到应用的访问；

cpu和内存：如果应用长时间的运行要确保应用本身不要积累垃圾引用从而造成oom等问题(比如JVM要观察老年代增长)

硬件本身的可用性: k8s

数据中心的可用性: 灾备：不要把多节点的应用部署到同一个数据中心

应用层面

首先应用层面肯定要做到HA(自动容错 failover),如果是面向互联网的应用还存在突发流量的问题；

然后应用的后续升级部署也要考虑到尽量热部署和在线升级，包括应用代码和数据库代码；

案例：

参考《gitlab_server》 《postgresql》