当前位置:首页 > 架构 > 正文内容

如何应对网站流量暴增

phpmianshi2年前 (2019-04-10)架构289

按照经验大概出问题地方是DB,磁盘io、CPU、带宽、连接数、内存其中的一个或几个。不同的业务,不同的系统设计,出问题的地方会有所不同。如果流量增大数倍,势必某个资源会在瞬间被榨干,然后所有的服务都会“开小差”,引起用户的抱怨。而解决问题的关键,是在问题发生时,尽量减少出问题的资源被访问。

1、流量暴涨的原因

    一般情况下,引起网站流量暴增大致为以下两种情况
  1、不可预测流量(网站被恶意刷量;CDN回源抓取数据;合作业务平台调取平台数据等)
  2、可预测流量(突然爆发的社会热点,营销活动的宣传;)

         不管是可预测流量还是不可预测流量都会表现在带宽和网站整体架构的应对方案上

         如果由于带宽原因引起,由于网站的并发量太高,达到服务器的吞吐极限,导致服务器宕机,这时需要做临时申请加大带宽,然后负载均衡分流。
         如果由于外网请求数据库,导致数据库频繁读写,数据库处理能力低,导致大量请求积压;如果是这种情况,就需要优化SQL,存储过程等,如果是请求过大,就要考虑做集群等。
        可预测流量的暴增也会拖慢网页的打开速度,甚至导致网站服务器宕机。要应对正常流量暴增,在流量高峰期到来之前就可以适当的调整,一般针对应用服务器的调整可以防止单点,负载均衡,高可用,增加后端web应用服务器数量,数据库读写分离,拆库拆表等,防止流量暴增导致服务器挂掉,下面具体说明:

2、预案

2.1 流量估算

      作为一个经验充足的老运维,可以把设计流量*3作为系统压力的下限,即实现完了要压测,压测得到的结果要达到设计流量 * 3( * 4, * 5都可以),比如服务器在IDC机房,在签合同之前就可以说明当流量异常的时候,提供一定的缓冲带宽,如果是云服务器,可以临时加带宽。

      关键是要给系统留些缓冲。一旦发生了什么,不至于挂的太惨。此时,一般会得到一个带缓存的业务服务系统。考虑到缓存高于后台服务2~3个数量级的性能优势,多撑几倍流量一般不成问题。

2.2 降级方案

      降级总得是用户可以买账的方式才行,不能瞎降。能降级成什么样,显示成什么样子,都得预先设计好。UI上有的要配图,有的要出警告语提示。而作为后台服务器,需要有对应的实时开关,一旦设置,立刻进入降级方案。

     但是,如果核心服务就是热点本身,就没得降级,比如,电商的双十一,用户的购买,下单等行为,下单就是下单,不能下一半,不能砍掉支付,不能随机性有的能买有的不能买,是涉及到大量写操作,而且是核心链路,无法降级的,这个时候,限流就比较重要了。

2.3限流方案

限流的常用方式

限流的常用处理手段有:计数器、滑动窗口、漏桶、令牌。

 计数器

image.png

计数器是一种比较简单的限流算法,用途比较广泛,在接口层面,很多地方使用这种方式限流。在一段时间内,进行计数,与阀值进行比较,到了时间临界点,将计数器清0。

 局限性:

这里需要注意的是,存在一个时间临界点的问题。举个栗子,在12:01:00到12:01:58这段时间内没有用户请求,然后在12:01:59这一瞬时发出100个请求,OK,然后在12:02:00这一瞬时又发出了100个请求。这里你应该能感受到,在这个临界点可能会承受恶意用户的大量请求,甚至超出系统预期的承受。

滑动窗口

由于计数器存在临界点缺陷,后来出现了滑动窗口算法来解决。

局限性:

滑动窗口的意思是说把固定时间片,进行划分,并且随着时间的流逝,进行移动,这样就巧妙的避开了计数器的临界点问题。也就是说这些固定数量的可以移动的格子,
将会进行计数判断阀值,因此格子的数量影响着滑动窗口算法的精度。

漏桶

虽然滑动窗口有效避免了时间临界点的问题,但是依然有时间片的概念,而漏桶算法在这方面比滑动窗口而言,更加先进。

有一个固定的桶,进水的速率是不确定的,但是出水的速率是恒定的,当水满的时候是会溢出的。

令牌桶

注意到,漏桶的出水速度是恒定的,那么意味着如果瞬时大流量的话,将有大部分请求被丢弃掉(也就是所谓的溢出)。为了解决这个问题,令牌桶进行了算法改进。

局限性:

生成令牌的速度是恒定的,而请求去拿令牌是没有速度限制的。这意味,面对瞬时大流量,该算法可以在短时间内请求拿到大量令牌,而且拿令牌的过程并不是消耗很大的事情。(有一点生产令牌,消费令牌的意味)

不论是对于令牌桶拿不到令牌被拒绝,还是漏桶的水满了溢出,都是为了保证大部分流量的正常使用,而牺牲掉了少部分流量,这是合理的,如果因为极少部分流量需要保证的话,那么就可能导致系统达到极限而挂掉,得不偿失。
版权声明:本文由PHP面试资料网发布,如需转载请注明出处。
分享给朋友:

相关文章

秒杀如何设计

秒杀难点:1、突发流量、数据热点2、数据一致性、短暂混沌态如果采用传统的数据库进行数据存储,对同一资源的争抢,就会面临严重的锁冲突问题。一般是通过一个前置的,速度更快的存储顶在前面,这就涉及到源库和目...

基于rebase的Git工作流

使用Git在多人协作的过程中,我们也会面临如何运用好Git的问题。这种情况下,就出现了各种各样的Git Workflow,而本文将介绍一种基于rebase的工作流,这种工作流也是目前开源社区所比较推崇...

如何使用sentry进行异常监控

系统架构中应用程序的监控非常重要。比如你是否遇到过这种问题:当用户向你抛出一个bug(或者说异常),而你却找不到异常出现的原因和时机,也很难去重现这种奇葩的事件,此时你有一种众里寻他千百度,那bug却...

如何实现分布式事务

事务定义简单地说,事务提供一种“要么什么都不做,要么做全套(All or Nothing)”机制。数据库本地事务数据库事务中的四大特性 ACIDA:原子性(Atomicity),一个事务(transa...

系统架构的演进之路-单体到SOA到微服务

单体系统的困难在微服务出现之前,互联网应用系统主要是单体系统,也就是说一个网站的整个系统由一个应用构成。如果是 Java,就打包成一个 war 包,一个 war 包包含整个应用系统,系统更新的时候,即...

互联网应用可用性的度量

概念业界通常用多少个 9 来说明互联网应用的可用性。示例比如说 QQ 的可用性是 4 个 9,就是说 QQ 的服务 99.99% 可用,这句话的意思是 QQ 的服务要保证在其所有的运行时间里只有 0....

发表评论

访客

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。