几个负载均衡器的小结

 之前负责过公司webcdn相关的设计和维护工作，同时做了些应用运维方面的工作,简单谈几个我对接触过的几款负载均衡器的了解:

1.keepalived

 使用vrrp实现高可用，可以理解成是IP层的高可用，虚拟出一个vip来实现高可用的功能。

实际应用时主要是两两组合，提供两个vip，在一台挂掉后可以自动转移至另一台服务。

比较常见的问题是脑裂问题和ip转移后的arp问题，第一种问题可以通过tcpdump快速定位rc(要抓vrrp协议),第二种情况可以使用arping的脚本解决(keepalived 的notify_master设置)。

 基本上没有性能上的问题。

2.lvs

 线上用的比较多的一种负载均衡器，内核态转发型的高可用工具，可以看做是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以上的内核配合多队列(必须)来解决。

3.nginx

 现在主流的反向代理软件，可以通过代理的功能实现负载均衡的功能，本身功能比较完善，既可以做静态站点，缓存又可以做负载均衡器，配置上可以优化的地方很多，有端口检测和url的检测，但是检测的方式是被动式的，会对用户的访问造成一定的影响。

 以java类应用来说，常见的使用方式是lvs+nginx+tomcat/resin，比较完善的日志，可以通过分析nginx日志的状态码，响应时间(response time)和后端响应时间(upstream time)来跟踪qos，定位问题。

 性能上问题不大，比较常见的问题是buffer导致的io问题和日志本地切割导致的nginx慢速响应的问题

第一个问题可以尝试内存换io或者干脆关掉buffer试试，第二个问题可以把日志通过网络写入远端处理（不过貌似目前nginx不支持）。

4.tengine

 nginx的变种，在url check上做了改进，支持主动的检查，减少了对用户的影响，同时可以支持多种方式的日志处理(通过网络写入远端处理等)，还支持各种自定义的插件，灵活性比较高。在webcdn的结构设计中我就是用了lvs+tengine+squid/trafficserver的结构。

5.squid/trafficserver/varnish

反向代理软件，个人觉得还是做缓存会比较有优势。没有用来做过负载均衡器，这里就不妄加评论了。。

6.haproxy

个人感觉和nginx差不多，比nginx要轻量级。

一般都是lvs + haproxy来做高可用，比如淘宝的cdn结构就是lvs+haproxy+trafficserver

这个个人用的也比较少。。

7.f5设备类

高大上的设备，没接触过，不过有界面一切都好说。

一句话：用好一个软件比用一个好软件更重要。

本文出自 “菜光光的博客” 博客，转载请与作者联系！