高可用系统设计

微信扫一扫,分享到朋友圈

高可用系统设计

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

冗余

比如我们旅游拍了很多照片,放在手机里怕丢怎么办啊,我们会上传到百度网盘,这个就是冗余。

冗余是最简单的办法,同时也要做到故障转移,比如为了保证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内存情况。

布鲁斯·威利斯R级太空打怪片《异星危机》曝预告

上一篇

专家辟谣:不存在“全球首颗6G卫星”但候选技术有了新突破

下一篇

你也可能喜欢

高可用系统设计

长按储存图像,分享给朋友