之前负责过公司webcdn相关的设计和维护工作，同时做了些应用运维方面的工作,简单谈几个我对接触过的几款负载均衡器的了解: 使用vrrp实现高可用，可以理解成是IP层的高可用，虚拟出一个vip来实现高可用的功能。
实际应用时主要是两两组合，提供两个vip，在一台挂掉后可以自动转移至另一台服务。
比较常见的问题是脑裂问题和ip转移后的arp问题，第一种问题可以通过tcpdump快速定位rc(要抓vrrp协议),第二种情况可以使用arping的脚本解决(keepalived 的notify_master设置)。
线上用的比较多的一种负载均衡器，内核态转发型的高可用工具，可以看做是tcp层的负载均衡器,主要原理就是对tcp的报文做些更改，然后进行转发,支持的状态检测方法也比较完善，有端口检测，url检测和自定义脚本检测。
实际应用中一般是用lvs的dr模式，配合keepalived使用，keepalived提供主机的高可用，lvs提供应用的高可用，lvs采用url的检测方式（避免端口ok但是应用挂起的情况，比如java应用的gc）。
比较常见的问题是realserver被踢出的问题，可以通过在lvs部署监控并根据检测方法部署相关的检测脚本(网络检测，端口检测，url检测)来找到问题的rc。
很少能遇到性能的问题，在包量很大的情况下（几十万/s），可能会遇到网卡ring buffer和网卡中断的问题，可以通过丢包率和mpstat来定位，ring buffer问题可以尝试增加网卡的ring buffer设置解决，中断问题可以采用centos5.8以上的内核配合多队列(必须)来解决。
现在主流的反向代理软件，可以通过代理的功能实现负载均衡的功能，本身功能比较完善，既可以做静态站点，缓存又可以做负载均衡器，配置上可以优化的地方很多，有端口检测和url的检测，但是检测的方式是被动式的，会对用户的访问造成一定的影响。
以java类应用来说，常见的使用方式是lvs+nginx+tomcat/resin，比较完善的日志，可以通过分析nginx日志的状态码，响应时间(response time)和后端响应时间(upstream time)来跟踪qos，定位问题。
性能上问题不大，比较常见的问题是buffer导致的io问题和日志本地切割导致的nginx慢速响应的问题
第一个问题可以尝试内存换io或者干脆关掉buffer试试，第二个问题可以把日志通过网络写入远端处理（不过貌似目前nginx不支持）。
nginx的变种，在url check上做了改进，支持主动的检查，减少了对用户的影响，同时可以支持多种方式的日志处理(通过网络写入远端处理等)，还支持各种自定义的插件，灵活性比较高。在webcdn的结构设计中我就是用了lvs+tengine+squid/trafficserver的结构。
5.squid/trafficserver/varnish
反向代理软件，个人觉得还是做缓存会比较有优势。没有用来做过负载均衡器，这里就不妄加评论了。。
个人感觉和nginx差不多，比nginx要轻量级。
一般都是lvs + haproxy来做高可用，比如淘宝的cdn结构就是lvs+haproxy+trafficserver
高大上的设备，没接触过，不过有界面一切都好说。
一句话：用好一个软件比用一个好软件更重要。
本文转自菜菜光 51CTO博客，原文链接：http://blog.51cto.com/caiguangguang/1357638，如需转载请自行联系原作者