负载均衡在很多人眼里可能是集群架设的基础，可能会有人觉得负载均衡后端的真实服务器越多处理速度越快，当然这种想法是正确的，但是这是建立在不考虑LB服务器的负载模式和挂在负载均衡服务器后面的数据库服务器处理速度的前提下的，下面我介绍一个我自己的经历吧：

       我们的一个业务之前一直是由一个tomcat再运行，基本上没什么架构可谈，简单的client----tomcat----oracle这样的一个顺序。直到有一天，我们的tomcat频繁的当机，用netstat命令查看链接数处于ESTABLISHED状态的有1000~2000个！好吧！我这里吐槽一下，我来这里之前这里的16G内存的Linux服务器居然用的是32位的OS！！

       我调过了tomcat和JVM的基本设置，但是受限于32位OS的内存和句柄限制，对于业务也没有什么明显的缓解，于是开始着手搭建负载均衡（PS当时没有空闲的服务器进行替换）。

       一上来由于没有其它的服务器能够立刻上线，又因为32位的操作系统浪费了大量的内存，所以我就用了一个奇葩的单机多实例- -（请不要学我，这里对于单点故障完全没有任何益处）我在服务器上同时运行了4个tomcat（因为在32位的OS上一个JVM最大只能占用2G的内存，开启多个JVM可以适当的提升内存的利用率）和1个负载均衡的程序，这里我试验过varnish、nginx和现在正在使用的haproxy（最后因为开发要求获取一个数据所以又换回了nginx）。

       一开始虽然运行了4个tomcat但是OS的限制依旧很明显，但是处理队列的增加明显的减少了运行队列的等待情况，链接数也有原来的6000+变到了2000附近，处于ESTABLISHED状态的链接更是减少到了400附近。

       就这样又平稳的运行了一个多月，终于新的服务器到位了，OS也换成了64位的了。于是我把之前的4个tomcat迁移到了新的服务器上，于是乎新的问题出现了。由于新服务器（应该和64位的OS有关系）处理能力的提升，虽然处理速度变快了，但是后面的数据库却出现了明显的压力。

       通过观察和测试，平均我每启动一个tomcat，数据库服务器的负载压力立刻就会提升10（load average），用vmstat命令看R的增长也在10左右。于是原来的4个tomcat直接就把负载在10以内的数据库服务器压到了40，这还是非高峰期！

       鉴于这种情况再DBA的协助调整下（这里不得不再说一下这个悲剧一样的数据库设计，各种大表连锁查询），一方面对于数据库做了些优化，但是效果不明显，所以我把tomcat的数量削减到了2个，就这样到现在运行了1周的时间里面访问速度不但比之前的4个tomcat负载还要好，服务器也几乎没有出现过程序故障（这里再吐槽一下DELL R710的网卡驱动太和谐了）。

       到这里这个问题也就基本上解决了，负载均衡虽然可以增加处理队列，增加对请求的处理速度，但是再搭建的同时也要考虑一下应用对数据库的负载压力。只有找到一个良好的平衡点才能让业务运行又快又平稳！

以上！