负载很大的服务器适合采用轮询控制方式么?

负载很大的话需要看业务的类型了

轮询情况下如果分发到服务器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来共享信息避免重发请求，也可以关掉前一个请求，在当前页面重新发起一个请求

不管哪种方案都要服务器端做改造，这不仅仅是前端自己的事，因为如果每一个连接都开一个线程，很快就会内存不够挂掉的。

---