各位志同道合的朋友们大家好，我是一个一直在一线互联网踩坑十余年的编码爱好者，现在将我们的经验以及架构实战方案分享出来，和大家一起将技术学深学透，如果喜欢，欢迎关注我，我一般都会在每篇文章后面预告下一专题

高可用（HA）是系统架构设计中必须要考虑的，是指系统所能提供无故障服务的一种能力。

简单的说就是避免因服务器宕机而造成的服务不可用的情况，像Elasticsearch并不会因为一节点的宕机而造成整个搜索服务不可用（后面会分享ES的架构原理）。

如何衡量高可用

假设你的系统全年都是正常提供服务，那么就是说你系统的可用性是100%，当然这个值是理想状态下，一般都是以几个9来表示系统的可用性，99.99的可用性较多，9越多就代表可用性越强，下面来看看这个几个9是如何计算出来的

可用性=平均故障间隔/(平均故障间隔 + 故障恢复平均时间)

如何设计系统的高可用

想要高可用就要避免使用单点，你想想看你的单台服务器再强应用优化的再极致，只要它宕机，就啥都凉凉了，所以需要多台机器也就是需要集群，方法论中叫冗余。只是有了集群是不能完全满足复杂业务的高可用的，我们要让系统在当前节点宕机的情况下，自己进行切换到好的节点去，这即所谓的故障转移。所以我们现在设计高可用系统的目标明确了，

那就是：冗余 + 故障转移

我们来先看看当前大部分互联网公司的系统架构：

看上图你会想到什么地方会出现不可用的情况？

1，从客户端到反向代理Nginx这块，这个1台nginx是会可能发生故障的，所以这里可以再冗余一台Nginx，可以利用linux的 keeplived进行探测可用性，当一台Nginx挂了之后，责会自动转移到另一台Nginx机器上来，从而保证高可用。

2，从反向代理到后端服务service这块，反向代理这块，目前最受欢迎的是nginx，性能方面表现也很好，nginx能够自动探测后端服务的可用性，只需在nginx,config配置多台后端服务就行了。

3，从后端服务到缓存这块，缓存这块推荐使用redis主从同步方案来达到高可用，redis主从同步加上sentine哨兵机制来自动探活redis实例。

4，从后端服务到写数据库这块，这里可以采用双主机制，一台给线上使用，另一台冗余，当线上那台挂了才会阶梯过来使用写功能，同样是通过linux的keepalived进行自动探活。

5，从后端服务到读数据库这块，这里同样是将读库部署多台，例如部署2台，通过代码段增加连接池组件进行路由读库和探活。

设计系统高可用延伸思路

上面介绍了我们在宏观方面怎么设计系统高可用，其实我们在编码的时候除了故障转移方案，同样需要考虑很多东西来保证系统的可用性，主要想体现在，超时机制、降级、限流等

超时机制

在我们系统中其实大部分会调用三方接口，而这个三方接口一般是合作公司的或者是公司其他部门提供的，我们并不清楚对方接口的性能情况，有些接口在并发稍大一点的情况下会出现返回很慢，一直占用当前资源，使得我们大量的请求阻塞等。所以这块我们需要对此进行设置合理的超时时间，来快速结束这些慢请求，来保证我们系统的可用性。

我们线上就有一个业务发生过类似的事情，对方接口在我们一定并发的时候经常很慢很慢才会出现结果，最后造成我们OOM，最终发现是这个业务程序员没有合理设置超时时间造成的。

那么这个超时时间应该设置多少呢，这个并不是绝对的，需要我们根据自己的业务以及接口情况加上多次分析线上时间，来合理设置，可以不停的对其设置直到业务愉快的进行。

降级

降级也是互联网中老生常谈的话题，那么我们使用降级方案如何来保证系统的可用性呢，分析自己的业务，在面对流量剧增的时候，例如，秒杀，大促等这些剧增的大流量，可以将不影响本次业务的流程也砍掉，不去调用了，直接走核心业务。其实各大电商都是采取这种方案来保证系统的可用性的。

限流

限流是，本来我系统只能抗住10万并发，然后现在我们运营搞了什么牛逼的大促，搞的来了10倍的流量，那么系统就把瞬间不能处理的流量给截断，直接返回给用户，用户可以待会儿再试。所以限流就是为了保证系统的高可用而限制住大流量的情况发生。

总结

今天分享了什么是高可用架构，以及高可用架构的设计思路关键点即故障转移、超时机制、降级、限流等，欢迎大家交流，一起把技术学深学透，大家喜欢就帮忙点点赞，转发，拜谢！

下一集预告：互联网架构另一个设计点：可扩展系统的设计有福利相送，敬请期待！