高可用系统设计

在系统运行期间，有可能硬件的损坏、软件运行中流量激增致使宕机等，致使系统不能正常运行。为了解决这些异常，咱们能够从如下几个来考虑。

冗余

好比咱们旅游拍了不少照片，放在手机里怕丢怎么办啊，咱们会上传到百度网盘，这个就是冗余。
冗余是最简单的办法，同时也要作到故障转移，好比为了保证nginx的高可用，咱们会启动两个nginx，一个是主一个是备，还要再弄一个Keepalive，当主挂了，Keepalive会自动切换到备份的nginx。
好比mysql数据库，咱们会作主从，slave经过binlog同步master的数据，当master挂了，会切换到slave（因为数据的同步是异步的，此时可能会丢失数据）。
好比redis，咱们采用哨兵或者集群的形式，当master挂了自动检测并切换到slave。
好比消息队列，好比hadoop，好比kafka，好比elasticsearch等等，都是经过冗余来保证系统或者副本的高可用性。
若是条件容许，还须要作到多地多活。否则备份同一个机房，机房发生火灾，数据所有丢失，备份同一个地点，发生地震洪水等天然灾害，数据所有丢失。

超时重试

当咱们调用第三方接口的时候，或者网关层调用业务逻辑层等，因为网络或者其余问题，致使咱们的请求没有获得响应或者好久才获得响应，为了保证咱们的服务是高可用的，咱们一般会设置重试的次数和超时的时间。
重试的次数不能太大，这样很容易请求流量翻了不少倍，形成被请求服务的雪崩。
超时的时间不能设置的太长，这样很容易让本身一直等待，积压了不少请求，致使本身服务雪崩。也不能过短，还没响应就直接取消了，形成请求成功率降低。
若是A调用B，B调用C，此时A的超时时间应该要长与B调用C的超时时间。好比A->B是100毫秒，B->C是200毫秒，B在150毫秒拿了C的响应，可是A已通过期了，而后A又开始了重试，请求流量又涨涨涨。
咱们重试的机制，必需要肯定被调用方的接口是幂等性的，否则会形成数据的错乱。

降级熔断

当咱们调用第三方接口的时候，第三方响应慢或者没响应，好比宕机或者网络不可用，不断的请求，会占用咱们的系统资源，更甚者会致使咱们系统的雪崩，因此咱们经过降级熔断来避免雪崩状况。
好比咱们原先调用第三方获取商品的信息，此时第三方不可用，咱们就调用本身的本地缓存、redis缓存或者直接返回空，这个叫降级。若是第三方一直不可用，那咱们就不调用第三方，直接本身处理，这个叫熔断。若是熔断了，须要异步调用看第三方服务是否恢复了，若是恢复了，取消熔断。
目前比较火的就是sentine以及hystrix。

幂等设计

当咱们提供接口给第三方的时候，因为第三方可能的重试，形成数据的错乱，因此咱们要保证咱们的系统是幂等的。接口幂等设计

限流

当咱们提供接口给第三方的时候，因为第三方可能大规模的调用，流量超过了咱们系统的峰值，致使咱们系统的不可用。咱们能够想直接降级来解决，返回空或者缓存数据，可是有些业务场景，好比秒杀，就不能经过降级来解决，此时就须要限流，让有限的流量进来。经常使用的限流算法有令牌桶和漏桶两个。有时候也根据计数器，来限制数据库链接池、线程池的并发数。

压测

不论是哪一种限流方式，咱们都须要知道咱们系统的峰值在哪里，因此须要压测，方便扩容和设置限流阈值。

线下压测

包括使用apache ab、apache jmeter、loadrunner、Tcpcopy 这些工具，对接口进行压测，对测试的结果进行性能优化以及确认系统的阈值。压测的时候尽可能保证硬件设施和测试数据接近线上，这样才能够保证结果的准确性。

线上压测

当服务器比较少的时候，咱们还原线上的环境须要的开销其实不太大，若是服务器不少的时候，那开销就很大了，因此要利用线上的环境来进行压测。
线上压测包括读压测、写压测、读写混合压测。写压测的时候，要注意写的数据和真是数据隔离。
好比咱们有100个服务作集群，在凌晨或者流量小的时候，逐步引流到指定的服务，好比从100到90到80，监控各个服务、数据库、第三方中间件等的cpu内存状况。