这个话题可能铺开来谈有许多方向可以研究，所以面试会经常遇到这样的问题，用来考察一个人的知识广度，除此之外多看看也有助于我们平时设计系统时考虑问题更全面。
高可用描述的是一个系统在大部分时间都是可用的，可以为我们提供服务。高可用代表系统及时在发生硬件故障或者系统升级的时候，服务仍然是可用的。
一般情况下，使用多少个9来评判一个系统的可用性，比如99.9999%就是代表该系统在所有的运行时间中只有0.0001%的时间是不可用的，这样的系统就是非常非常非常高可用的了！当然，也会有系统如果可用性不太好的话，可能连9都上不了。
1.注重代码质量，测试严格把关
代码质量是最重要的，代码质量问题比较常见的有内存泄漏、循环依赖都是对系统可用性的极大损害。大家都喜欢谈限流、降级、熔断，但是我觉得从代码质量这个源头把关是首先要做好的一件很重要的事情。如何提高代码质量？比较实际可用的就是CodeReview，不要在乎每天多花的那1个小时左右的时间，作用很大，值得认真去review。
另外，安利这个提高代码质量有实际效果的宝贝：
2.使用集群，减少单点故障
例如redis，如何保证我们的Redis缓存高可用？答案就是使用集群，避免单点故障。当我们使用一个Redis实例作为缓存的时候，这个Redis实例挂了之后，整个缓存服务可能就挂了。使用了集群之后，即使一台Redis实例，不到一秒就会有另外一台Redis实例顶上。
3. 限流
流量控制，原理是监控应用流量的QPS或并发线程数等指标，当达到指定的阈值时对流量进行控制，以避免被瞬时的流量高峰冲垮，从而保障应用的高可用性。
4.超时和重试机制设置
一旦用户请求超过某个时间得不到响应，就抛出异常。这个很重要，很多系统的线上故障就是因为没有进行超时设置或者超市设置方式不对导致的。我们再读取第三方服务的时候，尤其适合设置超时和重试机制。一般我们使用一些RPC框架的时候，这些框架都自带的超时重试的配置。如果不进行超时设置可能会导致请求响应速度慢，甚至导致请求堆积进而让系统无法在处理请求。重试的次数一般为3次，再多的重试也没有好处，反而会增加服务器的压力（部分场景使用失败重试机制不太合适）。
5.熔断机制
超时和重试机制设置之外，还有熔断也很重要。熔断机制说的是系统自动收集所依赖服务的资源使用情况和性能指标，当所以来的服务恶化或者调用失败次数达到某个阈值的时候就迅速失败，让当前系统立即切换依赖其他备用服务。比较常用的是流量控制和熔断降级框架是Netflix的Hystrix和Alibaba的Sentinel。
6.异步调用
异步调用的话我们不需要关心最后的结果，这样就可以在用户请求完立即返回结果，具体处理我们可以后续再做，秒杀场景用这个还是蛮多的。但是，使用异步之后我们可能需要适当修改业务流程进行配合，比如用户在提交订单之后，不能立即返回订单提交成功，需要在消息队列的订单消费进程真正处理完该订单之后，甚至出库之后，再通过电子邮件或者短信通知用户订单成功。出了可以在程序中实现异步之外，常常还使用消息队列，消息队列可以通过异步处理提高系统性能（削峰、减少响应时间所需时间）并且可以降低系统耦合性。
7.使用缓存
如果我们的系统属于并发量比较高的话，如果单纯使用数据库的话，当大量请求直接落到数据库可能数据库就会直接挂掉。使用系统缓存热点数据，因为缓存存储在内存中，所以速度相当的快！
8.其他
参考资料：https://dunwu.github.io/design/pages/9a462f/#%E9%AB%98%E5%8F%AF%E7%94%A8%E6%9E%B6%E6%9E%84%E7%AE%80%E4%BB%8B