基于数据库连接的负载均衡:例如总共有100个数据库连接,50个连接登录到数据库机器A,另外50个连接登录到数据库机器B,这样每个连接中接下来的所有请求全都是发往同一台数据库机器的
这种数据库负载均衡的思路模拟了WEB上的负载均衡方法,但是由于WEB连接是短时间连接(连接建立后,获取需要的HTML等资源后,连接马上被关闭),而数据库连接是长时间连接(连接建立后,可长时间保持,客户可不停向数据库发送SQL请求,数据库做出回答,如此不断循环直到连接被人为或因错而断开为止),因此这种数据库负载均衡思路存在着明显的缺点:有可能会发生绝大部分的请求压力都集中到某台数据库机器上去,从而使得负载均衡效果失效
2
基于批处理请求的负载均衡:在建立数据库连接的时候,会同时与每台数据库服务器建立连接,之后针对客户端的每次请求,都会根据负载均衡算法,独立地选出某个数据库节点来执行这个请求
此种思路符合数据库长时间连接的特征,不存在上面所述的基于连接的负载均衡方法的缺点
市面上的负载均衡厂商,既有基于连接的,也有基于批处理请求的,用户需仔细辨别才能找到自己想要的合适产品
哥们的描述很模糊哦,在线访问,说明应该有可视化界面,可以使用loadrunner工具去录制界面 *** 作然后跑并发即可,设置Vuser数,Vuser数一定条件下可以理解为你的在线用户数。将这个值一直往上加,压到你的服务器CPU,MEN,IO等还剩下20%左右的时候得出最大活跃用户数,然后再反推在线用户数。
PS:
用户在线对服务器的压力不大,登陆后未必会 *** 作, *** 作的话也未必会同时 *** 作,压力点在于活跃用户数,比如1000个在线,有100个用户处于活跃状态,其他900个非活跃状态。那么就是1:9
至于我说得方法合不合适,还得根据你服务器的实际情况而论。
Windows服务器中自带的性能监控工具叫做Performance Monitor;
在开始-运行中输入‘perfmon’,然后回车即可运行。
Monitor本身也是一个进程,运行起来也要占用一定的系统资源。所以你看到的资源的使用量应该比实际的要稍微高一点。这个工具在帮助管理员判断系统性能瓶颈时非常有用;
举个列子来说,今天有个用户抱怨说他们项目组的服务器(这是一台虚拟机)运行起来非常慢,但也不知道具体问题出在什么地方。任务管理器里显示CPU和内存的使用量都不算高,但服务器的相应就是非常慢;
Monitor,让其运行一段时间后(因为参考平均值会比较准确),发现average disk queue的值比较高,这就说明物理服务器的硬盘负荷太重,I/O *** 作的速度跟不上系统的要求。关掉虚拟机,将其转移到另一台硬盘负载比较小的主机上,再打开虚拟机。
分析性能情况
1、内存泄露判断
虚拟内存字节数(VirtualBytes)应该远大于工作集字节数(Workingset),如果两者变化规律相反,比如说工作集增长较快,虚拟内存增长较少,则可能说明出现了内存泄露的情况。
对于Workingset、Private Bytes、Available bytes这些计数器,如果在测试期间内数值持续增长,而且测试停止后位置在高水平,则也说明存在内存泄露。
Windows资源监控中,如果Process\PrivateBytes计数器和Process\WorkingSet计数器的值在长时间内持续升高,同时Memory\Available
bytes计数器的值持续降低,则很可能存在内存泄漏。
2、CPU使用情况
一般平均不要超过70%,最大不要超过90%(好:70% 、坏:85%、 很差:90%)。
3、tps(每秒处理事务的数量,在SOAPUI中进行统计)
一般在10-100,不同应用程序具体值不同。
理解负载均衡,必须先搞清楚正向代理和反向代理。注:
正向代理,代理的是用户。
反向代理,代理的是服务器
什么是负载均衡
当一台服务器的单位时间内的访问量越大时,服务器压力就越大,大到超过自身承受能力时,服务器就会崩溃。为了避免服务器崩溃,让用户有更好的体验,我们通过负载均衡的方式来分担服务器压力。
我们可以建立很多很多服务器,组成一个服务器集群,当用户访问网站时,先访问一个中间服务器,在让这个中间服务器在服务器集群中选择一个压力较小的服务器,然后将该访问请求引入该服务器。如此以来,用户的每次访问,都会保证服务器集群中的每个服务器压力趋于平衡,分担了服务器压力,避免了服务器崩溃的情况。
负载均衡是用反向代理的原理实现的。
1、轮询(默认)
每个请求 按时间顺序逐一分配 到不同的后端服务器,如果后端服务器down掉,能自动剔除。
upstreambackserver {server192168014;server192168015;}
2、weight
指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的
情况。
upstreambackserver {server192168014weight=3;server192168015weight=7;}
权重越高,在被访问的概率越大,如上例,分别是30%,70%。
3、上述方式存在一个问题就是说,在负载均衡系统中,假如用户在某台服务器上登录了,那么该用户第二次请求的时候,因为我们是负载均衡系统,每次请求都会重新定位到服务器集群中的某一个,那么已经登录某一个服务器的用户再重新定位到另一个服务器,其登录信息将会丢失,这样显然是不妥的。
我们可以采用ip_hash指令解决这个问题,如果客户已经访问了某个服务器,当用户再次访问时,会将该请求通过哈希算法,自动定位到该服务器。
每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。
upstreambackserver{ip_hash;server192168014:88;server192168015:80;}
4、fair(第三方)
按后端服务器的响应时间来分配请求,响应时间短的优先分配。
upstreambackserver {serverserver1;serverserver2;fair;}
5、url_hash(第三方)
按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器,后端服务器为缓存时比较有效。
upstream backserver { server squid1:3128; server squid2:3128; hash$request_uri; hash_method crc32;}123456
每个设备的状态设置为:
down 表示单前的server暂时不参与负载
weight 默认为1weight越大,负载的权重就越大。
max_fails:允许请求失败的次数默认为1当超过最大次数时,返回 proxy_next_upstream模块定义的错误
fail_timeout:max_fails次失败后,暂停的时间。
backup: 其它所有的非backup机器down或者忙的时候,请求backup机器。所以这台机器压力会最轻。
配置实例:
#user nobody;worker_processes4;events {# 最大并发数worker_connections1024;}>负载均衡有分硬件负载和软件。
1
硬件方面,可以用F5做负载,内置几十种算法。
2
软件方面,可以使用反向代理服务器,例如apache,Nginx等高可用反向代理服务器。
利用DNSPOD智能解析的功能,就可以实现多台机器负载均衡
首先你用一台高配置的机器来当数据库服务器然后把网站的前端页面复制成多份,分别放在其他的几台机器上面再用DNSPOD做智能解析,把域名解析指向多个服务器的IP,DNSPOD默认就有智能分流的作用,也就是说当有一台机器的资源不够用时会自动引导用户访问其他机器上这是相对来讲比较简单的实现负载均衡的方法
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)