我是靠谱客的博主 迅速星月,最近开发中收集的这篇文章主要介绍网站性能优化 - 解决大迸发访问,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

在互联网日益发展的今天,我们的程序越来越模块化,系统架构越来越完善,功能越来越强大。那么随之而来的访问量也是越来越大。
比如在勇哥我的经历中,一个发放微信红包的活动,访问量大的让服务器宕机。 导致网站的服务性极差。
所以我们要解决这个问题。

1、修改web服务软件的配置,购买更高配置及性能的服务器(服务器)
我以nginx+php 为例,因为我使用的比较习惯的是这些服务软件。当然,根据思路,其它的服务软件也能调整出来。
例如,我的服务器配置是4核4G的服务器。
那么我的nginx配置文件中 worker_processes 该属性的配置就应该是

worker_processes 4;

4核对应4个工作进程。
这里我只讲主要的配置 详细的nginx 配置看下我的这篇博文。
nginx配置详解
然后算一下,你服务器的网速是否足够,别机器的运算速度足够,而网速不够,那就有点尴尬了哦。这个是要根据的业务来的,比如用户请求某个地址后,他需要下载的html文件大小是多大,解析后如果解析的文件地址需要在主服上下载。那么需要下载的文件是多大。

keepalive_timeout 60

这个属性的内容是维护长连接的时间,当用户打开一个网址后,服务器处理完成后,不会立即释放这个连接,而是等待该属性设置的时间(单位s) 的时间内如果用户没有与服务器进行任何的交互(打开网页,进行ajax请求,文件下载等等等),就释放这个连接(好处是用户不用每次访问都与服务器握手建立连接,在有效时间内访问会复用以前建立的连接,缺点是在大迸发中,如果瞬时迸发过高,服务器需要的维护的连接过多,占用系统资源。所以这个属性的值要仔细斟酌,根据你的情况取一个合理的值)

keepalive_requests 10000

这个参数的真实含义,是指一个keep alive建立之后,nginx就会为这个连接设置一个计数器,记录这个keep alive的长连接上已经接收并处理的客户端请求的数量。如果达到这个参数设置的最大值时,则nginx会强行关闭这个长连接,逼迫客户端不得不重新建立新的长连接。如果在大迸发访问情况下,如果这个值设置的很低,那么就会发现有大量的TIME_WAIT的socket连接(即使此时keep alive已经在client和nginx之间生效),因为迸发数太大,一个keep alive早早的就被耗尽了请求资源,就被nginx给释放了,此时就会反复的重新建立新的keep alive。

2、文件离出主服,另放一台服务器。(文件存储服务)
为什么要这么做?
当用户请求一个网址,目标服务器生成该网址的html供浏览器下载并解析和渲染该html文件里面的内容。而在解析到该js 文件,css 文件,图片等文件时会对该文指定的下载地址下载,一般大家都是将这些文件存储在主服上,其实,除开图片以外其它文件最好不要放在主服上,如果你的前端解析程序不涉及跨域,那么js和css我也建议你不要放在主服。因为,html解析到这些文件后如果你的文件是放在主服的,那么浏览器又会去目标服务器下载该文件,这样占用了服务器的带宽和需要维护这个下载连接的线程资源。 所以,我建议将文件离出去,放在其它的服务器上。(像市面上比较牛的文件存储服务商七牛,阿里云OSS等都是价格实惠的,推荐你去看哈。如果你只是在一段时间会有大迸发,那么我推荐你使用按量付费。这些文件存储服务都给你提供了三方开发包,让你可以本地文件通过三方接口将文件上传至你程序设置指定的位置,如果是OSS服务,且你对网站的文件下载有更高的要求,那么看下我的这篇博文OSS cdn 服务)这样浏览器解析到js、css、图片文件就不会去主服上下载 而是在我们预定好的文件存储服务器上下载。所以在大迸发访问下,文件离出去的好处就是所有的浏览器针对css、js、图片等文件不会再去主服上下载消耗主服紧张的系统资源,且下载这些静态文件的时候也会消耗机器的I/O资源。I/O资源我在下面有解释。

3、将数据库(如mysql)从主服离出去。(数据存储服务)
先讲解个名词什么是I/O。
I/O 就是机器对存储在硬盘读写能力。 如我们常在市面上看到的,这个硬盘是5400转速的,那个硬盘是8000+多的转速的。都知道硬盘就是存储数据的嘛,那么转速就是对这些数据查询能力的一个解释。转速越大就说明机器的读写能力越强。当然一台机器的读写能力也是有极限的。后面我会解释。
为什么要将数据库从主服务器上迁移出去?
大家可以上网查查资料,其实数据库在进行数据存取的时候是在耗费机器的I/O的,而我们在大迸发访问下web服务软件(apache、nginx、tomcat等)由于需要给浏览器响应html文件,所以也会占用一部分机器的I/O资源。web服务软件在占用I/O,数据库服务也在占用I/O。一般来说,数据库消耗的I/O比web服务软件消耗的I/O要大。且如果你的业务逻辑不能数据库的数据缓存的话那就更恼火了,数据库的消耗的I/O还会更大。 这时候我想就明白问题的所在了。在高迸发下。机器是否能支撑住这么高的I/O , 那就是个问题了哟。
所以,我建议如果你的网站访问量大,那么就将数据库移出主服,单独存放在一台服务器上,或者是购买专业的数据库服务(如阿里云的RDS 我用了许久价格也很便宜,别说我打广告,我不是阿里云官方的人,我只是给大家推荐一下我的使用心得:RDS牛逼的随时升级配置,增强处理性能。且能动态开启读写分离,数据库服务器集群。容灾实例的支持。)。给主服减减压力。

4、负载均衡。
可能大家也在网络上搜集过相关的负载均衡知识。只是感觉负载均衡好高大上,好难呀。小白看不懂啊! 其实不然,你知道清楚了原理就知道该怎么干了。
我个人将负载均衡 分为一级负载均衡 和 二级负载均衡 和 三级负载。

一级负载均衡
在说这个之前,请大家熟悉一下windows 中的cmd 命令服务 的 ping 命令。ping 可以解析出目标域名地址的ip地址
我是手写的示例。大家也可以在自己的电脑上测试。

ping www.baidu.com
写好后按下回车

响应内容如下
来自 61.135.169.125 的回复: 字节=32 时间=38ms ttl=53

它解析的其它内容我们不管,我们只看它解析出来的ip地址61.135.169.125。这是我电脑上解析出来的ip地址。
我在重庆,那么同样一个网址在其它地方解析出来的ip是多少呢?
我这里以我的家乡,万州地区为例。

ping www.baidu.com
写好后按下回车

响应内容如下
来自 61.135.169.110 的回复: 字节=32 时间=38ms ttl=53

解析出来的ip地址不同了。

重庆 : 61.135.169.125
万州 : 61.135.169.110

怎么会这样呢。这是在DNS域名解析层级上做了手脚了。
比如
让第一个用户解析到了服务器A,由服务器A(以后就叫A)为该用户提供服务。
让第二个用户解析到了服务器B,由服务器B(以后就叫B)为该用户提供服务。

那么,你可能又会怀疑。既然是不同的服务器,那么怎么让他们都实现相同的功能的。
让A,B两台服务器上的业务代码一模一样不就行了。实现相同的逻辑处理。相同的功能。

两台服务器的数据是同步的吗?不能是我在A这边进行了一些操作,到B的时候没有了吧。
这个问题很好解决。
第一,你的数据不要采用文件的形式存储,所有的数据都存放到第三方的数据库(就是篇幅-3 数据库离出去那个)。
第二,两台服务器用一个数据库不就行了。这个问题就解决了呀。

那么,你可能又会怀疑。session 怎么办呢?比如我第一次打开网址解析到了A,A存储了我的session,第二次打开网址解析到了B,可B没有存储的嘛。
找到问题就得解决问题。
这种问题的处理方式我只会php和java两种,如果你是学其它语言开发的也可以看下思路,思路相同的。

php 将session 存储进数据库
如果你是用php 开发的后台。可以将session数据存储到数据库,每次session都是从数据库中读取出来的,而不是从本地读取。这样不管你解析到了那台服务器,都能将你的session读取出来的。而且你放心,哪怕是解析到了不同的服务器,只要域名相同,浏览器始终会将对该域名的cookie带起来的。php session存储进数据库,这方面的知识,网上有很多,我这里就不教怎么做了。度妈一搜,一堆一堆的源码给你。

java 将session 存储进memcahed 服务
如果你是用java 开发的后台。那么就将session 存储进 memcached ,每次读取的时候从memcached 中去读取该数据信息。和前面的php 将session 存储进数据库有点类似哈,只是一个是数据库,一个是memcached。

还有个问题,既然这样的话,那么我上传的文件,是从A这边上传的,怎么解析到B后也能访问到这个图片呢?
如果你打开调试模式,你会发现,你图片的地址根本就不是www.baidu.com这个了,而是https://xxxx.baidu.com 这种地址了。怎么回事? 那是因为你上传的文件已经上传到了baidu自己的文件服务器集群上了。 你访问的其实就是这个文件服务器的集群。

看了上面的讲解,我想你也应该有个了解了吧。知道是怎么做的了吧。当然百度的负载均衡,肯定不会这么简单的。

那么,我们怎么去做上面的一级负载呢。

步骤1、将数据库离出主服,文件也离出去至OSS、七牛等这些服务,上传的文件也反转上传至OSS、七牛等这些服务(上传成功后接口包会返回该文件的http访问地址的)。

步骤2、给主服做镜像处理生成n+1<=9个镜像(也就是将主服上的程序全部拷贝下来,把这些程序上传至新的服务器。注意,一定要尽量保证这些服务器上的运行环境与主服相致,不要出现兼容问题,某则会出现某些稀奇古怪的错误。),为什么最多只要9台服务器,因为域名提供商,最多给我们同一个域名下的解析10个解析记录,9+1=10嘛。 这些做完后,我们就将这些新服务器的IP地址添加至域名解析。如下
以www.qwe.com 为例
域名解析 记录 A … www.qwe.com 192.168.0.1
域名解析 记录 A … www.qwe.com 192.168.0.2
域名解析 记录 A … www.qwe.com 192.168.0.3
域名解析 记录 A … www.qwe.com 192.168.0.4
.
.
.
我是手写,知道大概的意思就行了。这些解析弄好了后,我们就打开域名提供商提供的平台并开启负载均衡服务(一般都是有的,如果没有你就仔细找哈)。打开后,你会看到针对www.qwe.com这个域名下所有的ip地址后面紧接着了一个 权重 选项。这个选项很重要。我解释下。

www.qwe.com 192.168.0.1 权重 : 2
www.qwe.com 192.168.0.2 权重 : 1
www.qwe.com 192.168.0.3 权重 : 3

这垃圾平台 上传不起本地图片,气的死人。手写的,理解下。

用户A 打开该网站 解析到 192.168.0.1
用户B 打开该网站 解析到 192.168.0.1
用户C 打开该网站 解析到 192.168.0.2
用户D 打开该网站 解析到 192.168.0.3
用户E 打开该网站 解析到 192.168.0.3
用户F 打开该网站 解析到 192.168.0.3

这就是权重的意思。 轮询解析。
根据你自己的情况,设置解析的权重吧。如果所有服务器的配置一样那么权重就分配一样的,如果所有服务器的配置有高有低,高的权重分配高点,低的权重分配少点。

步骤3、所有服务器的数据库配置,让它们都指向同一台数据库,或者是数据库集群。

步骤4、可以等待测试了。

二级负载
前面讲了一级负载。那么二级负载是在一级负载的基础上继续调整的。
比如说 一级负载最多支持的10台服务器已经不能满足我们的要求了,要继续增加服务器,怎么办呢?域名提供商针对一个域名最多让我们添加10条解析记录。
用反向代理。
关于反向代理的解释。大家可以找度妈。他解释的肯定比我专业。
我说下怎么用
1、我们在域名解析下的10条解析记录的IP全部换成反向代理服务器的IP地址。
2、我们在反向代理服务器中添加我们实际的业务服务器IP地址。当然也得根据配置来嘛,如果反向代理服务器的配置高,那么我们就给这台反向代理服务器多添加几条业务服务器的IP地址嘛,能者多劳。反之亦然。

然后我们就可以测试了,通过域名解析我们的请求被解析到了反向代理服务器,反向代理服务器收到请求后又将请求转发给业务服务器,业务服务器处理完成后,将处理结果返回给反向代理服务器,反向代理服务器再将结果返回给客户端
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8CzoyFL7-1650783580083)(https://gss0.bdstatic.com/94o3dSag_xI4khGkpoWK1HF6hhy/baike/c0=baike80,5,5,80,26/sign=bfbbb4d57b310a55d029d6a6d62c28cc/5243fbf2b2119313f8f3d19667380cd791238d67.jpg)]
这是网上找的结构图,其中文件服务器,也是可以做反向代理的。这里我主要看web服务器和反向代理服务器。

三级负载
需要这个级别的负载就是你的客户是个神经病了。这个级别就是将你的请求分发到离你最近的那台服务器。如果你们客户有钱,在全国各个省份,都有他们的服务器集群。 牛逼。 这个级别不用你主动去调整,dns 解析自动的就帮我们办好了。dns 解析本来就是主动解析到离你最近的那台服务解析。查了下资料,这个叫做智能解析。

看了前面的内容,我想你也有个了解了。但是可能在实际应用环境中,发现服务器是撑住了,数据库还是没撑住怎么办?

数据库集群,其实,网站打不开不能提供服务后,我们首先要检查的就是数据库崩溃没有,数据库是否支撑不住了。支撑不住了就给硬件升升级,如果升不上去了,做读写分离吧。最好是找个第三方的数据库服务平台,且最好是在你的服务器提供商那里买,可以支持内网服务,内网连接总比外网连接数据库的速度快吧。而且安全性也比外网好。

最后

以上就是迅速星月为你收集整理的网站性能优化 - 解决大迸发访问的全部内容,希望文章能够帮你解决网站性能优化 - 解决大迸发访问所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(36)

评论列表共有 0 条评论

立即
投稿
返回
顶部