轮询情况下如果分发到服务器A上面的连接有部分长连接,分发到服务器B上面可能为短连接,这就会导致看到服务器A上面的连接数比服务器B的连接数较高。
可以采用最小连接数方式做负载,比如服务器A上面有100个连接,服务器B上面有80个连接,这是负载设备会把后续的20个连接分发到服务器B,等到服务器B与服务器A连接数一致时按随机或轮询来分发到其中一台。
最小连接数一般是看4层的连接来负载的。
选择何种方式的负载算法还需要根据应用来决定,可以测试几种不同的方式以达到最佳的负载方式。
可以的。如果有多台服务器的话,可以做成集群,WEBLOGIC等都有集群功能,一台主机由于性能问题挂了,请求自动转发到另一台主机上,在平时也可以实现负载均衡以提高性能。同意楼上的,受DDOS攻击和性能问题是不同的,受攻击的解决方案我不太清楚,不过一般都是在路由器和防火墙上做功夫,好一点的路由器都有防止DDOS的功能还有配置好防火墙。至于你的设想中出现的问题,集群是这样解决的,集群实际上是三个服务器,一个在公网有IP负责接收和转发请求,另外两个服务器类似于原来的服务器处理请求,服务器1在接收请求,通过判断将请求转发给服务器2或3,处理完再发回给1,由1返回给用户。不需要解析到2个公网。
既然是微信,最佳的是做socket连接,不过需要你们服务端改造下,这样前端比较省心,服务端推送就好了其次的方案是参考comet模式,发一个ajax请求出去后,服务器如果没有新消息,不要反回,hold住这个连接,直到有数据;
前端要做三个事情:
第一个事情是由于http是短连接,一般浏览器都会设置一个超时时间,所以前端这个连接如果超过一定时间没有返回,需要abort掉,重新发起,推荐30秒
第二个事情是每次服务器有数据返回后,这个请求就结束了,你需要发起一个新的请求做监听;
第三个事情是多页面请求冲突问题,比较麻烦,不过如果你们是小游戏,应该是单页面应用就不用处理了,一般多页面应用或者WEB网站这类的,是通过localstorage来共享信息避免重发请求,也可以关掉前一个请求,在当前页面重新发起一个请求
不管哪种方案都要服务器端做改造,这不仅仅是前端自己的事,因为如果每一个连接都开一个线程,很快就会内存不够挂掉的。
欢迎分享,转载请注明来源:夏雨云
评论列表(0条)