前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >一文一点 | 系统从高可用到高不可用都经历了什么

一文一点 | 系统从高可用到高不可用都经历了什么

作者头像
王新栋
发布2020-09-08 15:33:10
5860
发布2020-09-08 15:33:10
举报
文章被收录于专栏:程序架道

这是【一文一点】的第6篇文章,不拘泥于篇幅字数,用一篇文章说清一个知识点。

1、

系统的高可用定义是什么。

主要特点就是【可用】前面有个【高】字,加上了高,就是代表系统在发生故障的情况下仍然是可用的,甚至是在极端故障下依然坚挺。

比如,有人挖断了通往你一个机房的光缆,但是,你是双机房,所以用户不受影响,这就是【高】可用的体现,【高】的地方在于你有两个机房。

高可用可以量化么,可以。

计算公式如下,

可用性 = (1 - 年度不可用时间 ➗ 年度总时间)* 100%

比如你常听到的某个服务的可用性为99.99%,也就是我们常说的4个9,就是这么计算出来的,也就是相当于对系统的可用性做了一个量化显示。

那么,反过来讲,确保系统的高可用,也就是通过架构设计减少系统不可用的时间。

2、

为了达到这一的高可用我们都经常要做哪些工作呢。

让我们首先来看一个正常的互联网分层架构,如下图所示。

在这幅图里面,从客户端请求反向代理,请求web应用服务,请求业务服务,请求数据库,那么大家注意在图中用浅黄色标出来的节点,只要有多份,再加上故障转移,就能够做到高可用

大家想想看,是不是这样。

另外呢,我们还可以从地理位置上设计异地多活、还可以从系统内让系统具备容错能力,比如包括降级限流、熔断、快速失败、线程池隔离等措施。

3、

那我们要是都做了这些工作,系统还出现不可用,是怎么回事呢。

我们可以将这个问题看成是一个攻守失衡的问题,守的是上面那些措施,那么攻的就是故障,当引起故障的变量增速能力大于守的措施能力的时候,便发生了系统的不可用

比如我们说的快速失败,也就是给我们凡是调用RPC的地方都加上超时时间,当前请求的量足够大,以致于请求量的增速时间大于失败的窗口时间,快速失败措施便也无能为力了。

在同步调用模式下,请求的线程数据变化急剧增加,最终导致整个系统不可用。

那么,我们一般都有哪些故障呢,我们可以把上面那张图继续丰富,来一起看下各技术架构层所处的环境,如下图所示。

也就是我们将其分成了IAAS层、PAAS层、SAAS层,因为一个企业的IT系统组成就是由它们来组成的,从这个角度来看,就便于我们认清每层会遇到什么故障了。

(1)、IAAS层的故障

服务器宕机、断电、磁盘满、丢包等等都属于IASS层的故障。

(2)、PAAS层的故障

数据库连接池满、数据库主从延迟,另外我们所使用的一切技术中间件也属于这一次,所以还有比如缓存击穿、缓存热点、RPC配置不可读等等,都属于PAAS层的故障。

(3)、SAAS层的故障

依赖超时、OOM、幂等失效等等我们所常见的这些,都属于SAAS层的故障。

这三层对于我们业务研发人员较为熟悉的是SAAS层和PAAS层的故障,尤其是SAAS层故障距离业务研发人员会更近。

这三层任何一层发生故障都有机会让我们的系统不可用。

3、

我们再来分享一下高可用这三个字,高我们上面介绍了,可用这俩字,我认为就是一种具有包含的味道在里面了。

性能不好,对于要求高性能的系统,还能叫做可用吗,安全出了问题,对于要求安全性高的系统,还能叫做可用吗。

所以呢,我个人认为高可用是一个范畴更大的词汇,那么引起不可用的范畴也随之变大了,因为这个时候性能不达标,安全不达标都是不可用了。

4、

举一个秒杀系统的例子,你预估流量不合理,资源服务器准备不足,秒杀降临,系统不可用。

又来一次秒杀活动,流量预估重复合理,资源服务器准备充足,也使用上了队列技术,增加了基于redis排队系统的支撑,但是redis遇到了缓存热点问题。

那天只有一个SKU参与秒杀,你设计的一个SKU一个队列,正常情况下一个4c8g的分片可以8-10w用户,但上午10点瞬间来了20w用户,达到了redis单片的瓶颈上限,系统不可用。

更可怕的是,被提示不能下单的用户,正在反复的刷你的服务器,因为他们为了等待秒杀,早早的定好了闹钟,就等这一刻,不愿轻易放弃。

5、

再举一个redis缓存失效的例子,你可能会问了,为什么又拿缓存说事,因为redis缓存常常是我们抗量的“必杀器”。

那么,如果这样的“必杀器”也出了问题,高可用是不是就“崩坍”了呢。

使用缓存的时候,最常用的方法就是在set的时候设置过期时间了,这种使用方式简单、方便,但同时也带来了”纰漏“。

那就是可能会造成“缓存风暴”,怎么理解这个风暴呢,如果短时间内有大量的数据时间过期,这些数据请求就回源到了数据库。

本身我们使用redis缓存就是为了增加系统的QPS,redis本身的IOPS也要比数据库高很多,那么在这样的情况下,原本“打”在redis身上的请求,都“回击”到了DB上。

数据库怎么能抗住,本来由redis抗住的量呢,结果可想而知了。

6、

以上说的都是技术层面导致原本高可用的系统变成了不可用,当然类似那样的故障种类还有很多。

不过,最后我想跟你从故障处理流程上再来说说。

故障和问题是一回事吗,咋一听是,其实严格来讲并不是,比如ITIL对这它俩的定义,我帮你总结了下,并画在了一张PPT里面,截图如下。

现在,让我们谈一谈,出现了线上故障,你第一件事最应该做什么?找出引起故障的根源问题吗?

记住,一定是先止损。

止损的方式有很多,如果你事先有了降级策略,可以立马执行这个策略,如果可以回顾版本,你要立即回顾,如果可以增加机器你要迅速扩容。

总之,你要先止损,而不是去苦苦的钻研问题,而不解决故障,找问题可以同步安排其他人员来进行,比如隔离某台服务器,去在上面打出OOM日志。

好了,我又写完一个知识点,希望对你有一点帮助。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2020-09-01,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 程序架道 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
云数据库 Redis
腾讯云数据库 Redis(TencentDB for Redis)是腾讯云打造的兼容 Redis 协议的缓存和存储服务。丰富的数据结构能帮助您完成不同类型的业务场景开发。支持主从热备,提供自动容灾切换、数据备份、故障迁移、实例监控、在线扩容、数据回档等全套的数据库服务。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档