高并发系统设计学习笔记(四) 系统设计三大目标(二) 系统如何做到高可用

目录

一、可用性的度量

二、高可用系统设计的思路

1.系统设计

(1)Failover

(2)调用超时

2.系统运维

(1)灰度发布

(2)故障演练

---

一、可用性的度量

一个高并发大流量的系统，系统出现故障比系统性能低更损伤用户的使用体验。想象一下，一个日活用户过百万的系统，一分钟的故障可能会影响到上千的用户。

MTBF（Mean Time Between Failure） 是平均故障间隔的意思，代表两次故障的间隔时间，也就是系统正常运转的平均时间。这个时间越长，系统稳定性越高。

MTTR（Mean Time To Repair） 表示故障的平均恢复时间，也可以理解为平均故障时间。这个值越小，故障对于用户的影响越小。 

下面的公式表示它们之间的关系

Availability = MTBF / (MTBF + MTTR)

一般来说，我们会使用几个九来描述系统的可用性

三个九之后，系统的年故障时间从3天锐减到8小时。到了四个九之后，年故障时间缩减到1小时之内。在这个级别的可用性下，你可能需要建立完善的运维值班体系、故障处理流程和业务变更流程。你可能还需要在系统设计上有更多的考虑，如果发生故障，是否不用人工介入就能自动恢复。在工具建设方面，你也需要多加完善，以便快速排查故障原因，让系统快速恢复。到达五个九之后，故障就不能靠人力恢复了，这个级别的可用性考察的是系统的容灾和自动恢复的能力，让机器来处理故障，才会让可用性指标提升一个档次。一般来说，我们的核心业务系统的可用性，需要达到四个九，非核心系统的可用性最多容忍到三个九。

---

二、高可用系统设计的思路

1.系统设计

"Design for failure"是我们做高可用系统设计时秉持的第一原则。在承担百万QPS的高并发系统中，集群中机器的数量成百上千台，单机的故障是常态，几乎每一天都有发生故障的可能。

未雨绸缪才能决胜千里。我们在做系统设计的时候，要把发生故障作为一个重要的考虑点，预先考虑如何自动化地发现故障，发生故障之后要如何解决。当然了，除了要有未雨绸缪的思维之外，我们还需要掌握一些具体的优化方法，比如failover（故障转移）、超时控制以及降级和限流。

(1)Failover

 发生failover的节点可能有两种情况

1.是在完全对等的节点之间做failover

2.是在不对等的节点之间，即系统中存在主节点也存在备节点

Nginx可以配置当某一个Tomcat出现大于500的请求的时候，重试请求另一个Tomcat节点

针对不对等节点的failover机制会复杂很多。比方说我们有一个主节点，有多台备用节点，这些备用节点可以是热备（同样在线提供服务的备用节点），也可以是冷备（只作为备份使用），那么我们就需要在代码中控制如何检测主备机器是否故障，以及如何做主备切换。

使用最广泛的故障检测机制是“心跳”。你可以在客户端上定期地向主节点发送心跳包，也可以从备份节点上定期发送心跳包。当一段时间内未收到心跳包，就可以认为主节点已经发生故障，可以触发选主的操作。

选主的结果需要在多个备份节点上达成一致，所以会使用某一种分布式一致性算法，比方说Paxos，Raft。

(2)调用超时

复杂的高并发系统通常会有很多的系统模块组成，同时也会依赖很多的组件和服务，比如说缓存组件，队列服务等等。它们之间的调用最怕的就是延迟而非失败，因为失败通常是瞬时的，可以通过重试的方式解决。而一旦调用某一个模块或者服务发生比较大的延迟，调用方就会阻塞在这次调用上，它已经占用的资源得不到释放。当存在大量这种阻塞请求时，调用方就会因为用尽资源而挂掉。

超时时间短了，会造成大量的超时错误，对用户体验产生影响

超时时间长了，又起不到作用

过收集系统之间的调用日志，统计比如说99%的响应时间是怎样的，然后依据这个时间来指定超时时间

两种有损的方案能保证系统的高可用，它们就是降级和限流 

 降级是为了保证核心服务的稳定而牺牲非核心服务的做法

比方说我们发一条微博会先经过反垃圾服务检测，检测内容是否是广告，通过后才会完成诸如写数据库等逻辑。反垃圾的检测是一个相对比较重的操作，因为涉及到非常多的策略匹配，在日常流量下虽然会比较耗时却还能正常响应。但是当并发较高的情况下，它就有可能成为瓶颈，而且它也不是发布微博的主体流程，所以我们可以暂时关闭反垃圾服务检测，这样就可以保证主体的流程更加稳定。

 限流通过对并发的请求进行限速来保护系统

比如对于Web应用，我限制单机只能处理每秒1000次的请求，超过的部分直接返回错误给客户端。虽然这种做法损害了用户的使用体验，但是它是在极端并发下的无奈之举，是短暂的行为，因此是可以接受的。 

2.系统运维

(1)灰度发布

在业务平稳运行过程中，系统是很少发生故障的，90%的故障是发生在上线变更阶段的。比方说，你上了一个新的功能，由于设计方案的问题，数据库的慢请求数翻了一倍，导致系统请求被拖慢而产生故障。

灰度发布指的是系统的变更不是一次性地推到线上的，而是按照一定比例逐步推进的。一般情况下，灰度发布是以机器维度进行的。比方说，我们先在10%的机器上进行变更，同时观察Dashboard上的系统性能指标以及错误日志。如果运行了一段时间之后系统指标比较平稳并且没有出现大量的错误日志，那么再推动全量变更。

(2)故障演练

故障演练指的是对系统进行一些破坏性的手段，观察在出现局部故障时，整体的系统表现是怎样的，从而发现系统中存在的，潜在的可用性问题。