一、什么是高可用性
服务端，顾名思义就是为用户提供服务的。
停工时间，就是不能向用户提供服务的时间。
高可用，就是系统具有高度可用性，尽量减少停工时间。
停工的原因一般有：
服务器故障。例如服务器宕机，服务器网络出现问题，机房或者机架出现问题等。
访问量急剧上升，导致服务器压力过大导致访问量急剧上升的原因有：
时间和访问量都可以预见的，例如秒杀活动，售票系统。
时间和访问量都不可以预见的，例如特发性新闻（马航失联的事件）
停工的原因，可以理解为灾难，所以系统的高可用性就是容灾，即应对灾难的能力，系统有较好的容灾能力，也就是即使灾难出现，系统依然可以正常工作。
二、怎么提升系统的高可用性
1.机器层面的灾难
例如：
机器宕机（其中一台服务器宕机了）
机房故障（机房被水淹了）
网络异常（电信的某条光纤被挖断了）
从范围了说，有可能是一台机器，也有可能是多台机器（机房或者某个区域，例如广东），甚至全部机器（那就没救了..）。
思路就是在多台机器上部署服务，即使一台机器出现问题，其他机器依然可以提供服务。当然，比较可靠的是，多台机器最好在不同的机房，不同的地域，但是对应的成本也会上升。
主从方式
主服务负责提供服务，从服务负责监测主服务器的心跳。当主服务出现问题，立刻转换为从服务器提供服务。例如Mysql的的的主从架构。
2.多机多工方式
在Ñ台机器上面，运行Ñ个服务，通过负载均衡，把请求分发到不同的机器。当其中一台机器出现问题。系统会自动的切换流量，也就是把请求都导流到其他正常的机器上。
2.业务层面的灾难
例如：
程序出错误了
访问量急剧上升（预计QPS是1K，突然去到1W）的
优化思路：
大系统小做。一个大系统，必然会有许多模块，把这些模块切分为多个小服务。例如用户系统，是一个独立的服务，消费系统，是一个独立的服务。每个服务都提供访问的API，给其他服务访问缺点是服务与服务之间的通讯成本增加，开发成本也会增加，因为要开发API但是好处是。：
必要的时候，这些API可以提供给外部
符合高内聚低耦合的原则
当某个服务压力上升时，或者服务出现错误时，其他不依赖于问题服务的服务，依然可以正常工作。例如消费服务出现问题，但是聊天服务可以依然可以正常工作。
有损服务。让服务延迟执行，以保证核心需求得到很好的处理。例如微信抢红包，核心需求是立刻知道抢红包的结果，所以服务端先返回抢红包的结果，而用户对是否即时入账并不关心，所以，把入账这个过程，放在异步队列里面做。
柔性可用在正常服务和停工之间增加一个状态：。部分可用当压力上来的时候，可以停止某些非必要服务，以保证必要服务可以正常运行又例如遇到错误的时候，短时间内不能立刻修复，而且出错误的业务又是非必要业务，可以先停止错误的业务，当然，这些要事先跟产品方商量好。
快速拒绝（过载保护）。检查当前系统的负载请求，如果负载过高，立刻返回等待提示，例如：
系统繁忙，请稍后再试。否则，用户会不断重试，让已经负载很高的系统雪上加霜。重试的频率，例如30秒后才能重试，或者没有收到服务端的返回前，不能再次提交请求。也可以在Nginx的层加入限制，同一IP1秒内不能发送多于ñ个请求，多于的就快速拒绝，防止被攻击。
3.验证高可用
当我们采用了各种措施来提升系统的容灾能力后，怎么测试我们的措施是否有用呢？
模拟客户端低网速。这个可以通过提琴手来模拟
模拟服务端丢包。可以使用netern和TC
使用AB进行压测。
模拟服务器宕机，可以直接断开服务器网络来模拟
三，应用
应用一般都是针对上面的机器问题导致的机器层面的灾难，因为业务层面的，一般是在代码开发阶段考虑的。
高可用可以分为两个关键点：
多节点
自动切换流量
多节点，也就是要部署多个节点，无论其他节点是挂起状态（主从），还是工作昨天（多机多工）。
当有了多节点后，还是不够的，因为当灾难来临的话，如果要人工去切换流量，必然要花费较长时间，所以需要有自动切换流量的机制。
自动切换流量的另一个功能就是，当损坏的节点恢复后，流量又会自动得切回去。
四，HTTP的应用
常用的服务端架构，一般是这样：
客户端从DNS服务器获取服务器的IP
客户端发起请求，请求先到Nginx的层
Nginx的层分发请求到服务层
如果需要，服务层会请求上游的服务层，例如向用户系统获取用户数据。一般会已通过HTTP来实现。
如果需要，服务层会访问缓存层，获取数据
如果需要，服务层会访问数据库层，获取数据
1.客户端层到Nginx层
会部署多个Nginx的层，DNS服务器中部署多个IP，这样DNS服务器会把流量均匀地分到多个Nginx的。
缺点是：
不能自动切换流量。当其中一台Nginx的不可用了，DNS服务器并不知道，所以不会自动切换流量
本机的主机配置中，可以设置一个域名对应多个IP，设置方法：
192.168.137.130 www.test.com
192.168.137.133 www.test.com
主机的解析策略是，先访问第一个IP，如果失败，才会访问第二个IP
所以没有负载均衡的功能，但是有自动流量切换的功能。
2. Nginx到服务层
Nginx可以配置多个服务层
。Nginx有监听服务层是否可用的机制（上行），所以可以实现自动切换流量
nginx的配置
upstream gunicorn_pool
{ #server 地址:端口号 weight表示权值，权值越大，被分配的几率越大;max_fails表示在fail_timeout中失败的最大次数，如果达到该次数，就不再导流量到该server
server 192.168.137.130:9098 weight=4 max_fails=2 fail_timeout=30s; server 192.168.137.133:9098 weight=4 max_fails=2 fail_timeout=30s;
}server { listen 80; server_name 127.0.0.1 www.test.com; access_log /data/logs/nginx_access.log; error_log /data/logs/nginx_error.log; location @gunicorn_proxy { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_redirect off; proxy_pass http://gunicorn_pool;
}
}配置一个上游，gunicorn_pool。里面有两个服务层（130和137）
如果两个服务层都正常，Nginx的的会把流量根据重量值，导流到两个服务器。
同一个请求中，如果nginx的的导流到server1的的，发现返回的是错误响应（例如502），nginx的的会把请求再发送服务器2，相当于重试。这时会记录server1的的的失败次数+1
如果再fail_timeout时间内，服务器1的失败次数超过max_fails，在fail_timeout时间内，nginx的的就不会再把其他请求导流到Server1上上了。
上面的机制，就可以实现自动的流量切换。当然也有负载均衡的功能，这个就是高并发的范畴了。
3.服务层到上游服务器
DNS服务器。使用DNS服务器把流量均分到上游服务层。缺点也是不能自动切换流量
RPC客户端。在服务器的机器中，部署一个RPC客户机，一般的实现方案是启动一个的Nginx的，利用的Nginx的的上游功能来分发流量，同时可以实现自动流量切换。服务层到上游服务层的请求，会先发到RPC客户端，然后再到上游服务层，相当于加了一个HTTP代理。
4.服务层到缓存层
常用的缓存有Redis的的和MongoDB中的
1.redis
主从架构
哨兵架构
集群架构
2.mongo
主从架构
副本集架构
分片
5.服务层到数据库层
常用的数据库就是Mysql的的了。
一主多从（主从复制）
二主多从（主主复制）
五，TCP的应用
1. DNS方法
配置DNS服务器，一个域名，对应多个知识产权，
缺点是不能实现流量自动切换，例如S1挂了，DNS还是会返回S1的的的iP给客户端，客户端可能要重试几次，才会拿到其他服务器的IP，才能实现连接。
2.注册-IP接口
由于TCP是长连接，所以获取IP的请求是很少的，所以可以自己写一个接口，客户端通过接口来获取TCP Server的IP地址。
这样的接口里面就可以做到自动切换流量了。已经挂了，就不会返回A机器的IP了
.TCP Server可以把自己的状态放在Redis，然后接口那边就可以获取TCP Server的状态了
也可以TCP Server提供一个http接口，返回自身的状态，供得到-IP接口那边调用。
在互联网公司面试中，架构的底层一定是面试官会问问的问题，针对面试官一般会提到的问题，我录制了一些分布式，微服务，性能优化等技术点底层原理的录像视频，加群619881427可以免费获取这些录像，里面还有些分布式，微服务，性能优化，春天设计时，MyBatis的等源码知识点的录像视频。这些视频都是 找一些资深架构师朋友一起录制出来的，这些视频帮助以下几类程序员：
1.对现在的薪资不满，想要跳槽，却对自己的技术没有信心，不知道如何面对面试官。
2.想从传统行业转行到互联网行业，但没有接触过互联网技术。
3.工作1 - 5年需要提升自己的核心竞争力，但学习没有系统化，不知道自己接下来要学什么才是正确的，踩坑后又不知道找谁，百度后依然不知所以然。
4.工作5 - 10年无法突破技术瓶颈（运用过很多技术，在公司一直写着业务代码，却依然不懂底层实现原理）
随时随地看视频
