|
昨晚发兴读了一下《构建高性能Web站点》Web负载均衡一节，好记性不如烂键盘，笔记梳理一遍。
最简单的负载均衡模式：HTTP重定向
对外入口服务器只有一台，请求到达后根据请求URL内容将该请求重定向到特定服务器。这种负载均衡方法的特点是
（1）一个请求实际会产生两次http ping pong
（2）最大带宽取决于入口服务器带宽，由于入口服务器只需要处理路由信息，所以可以处理的请求数量可以比较高。
最适合中等规模公司的负载均衡模式：DNS负载均衡
将负载均衡的压力交给了DNS系统。一个域名对应多个IP地址。这种负载均衡的特点是：
（1）当部分server故障时，只需要从DNS中将server ip移除即可。对应用透明。
（2）选择哪一个IP地址是DNS内置负载均衡策略决定的，一般DNS服务商都支持RR（轮询）策略。
（3）DNS方案淡化了主站的概念。主站被“分布式”了。
（4）如果要完全控制DNS的均衡策略，公司需要有自己的DNS服务器。bind这样的DNS服务软件可以提供丰富的DNS路由策略，例如根据IP选择最近的目标服务器IP。
（5）由于DNS缓存的存在，DNS的修改不能立即被用户感知到（TTL的限制）。服务端故障后修改DNS记录需要等一段时间后才能被用户感知。这是个比较麻烦的问题，不知线上如何解决？
一种“被误用”的负载均衡模式：反向代理负载均衡
前面讲的DNS和HTTP重定向模式实现的是请求的”转移“。反向代理要实现的是请求的”转发“。一个请求到达，反向代理会根据请求类型自主将请求转发到内部的某个服务器上，内部服务器完成任务后会把结构返回给代理服务器，代理服务器将最终结果返回给用户。不过，这种模式的确会被很多公司用到，但是用的角度不是从负载均衡出发，而是用于功能“服务化”。例如在淘宝，一个用户请求到达前端”代理服务器“后，代理服务器会去并发请求商品、库存、评论等多个服务器，将结果合并，然后返回给用户。
该模式最适用的场景是：很消耗计算资源，但结果集很小的情况。
顺便说一下的负载均衡模式：DNAT
这种模式的思路跟反向代理类似，只不过它是工作在传输层。它的性能也受制于网络出口带宽。
这才是王道：LVS
LVS有三种模式：LVS-NAT（Network Address Translation），LVS-DR（Direct Routing），LVS-TUN（Tunneling）
第一种NAT与上面的DNAT一样，没什么好说的。出口带宽是瓶颈。
LVS-DR是最适合搭建可扩展的负载均衡系统。理解LVS-DR的工作原理十分重要，否则你总会觉得这是一个魔法。
LVS-TUN也比较魔法，具体原理需要学习。
LVS-DR工作在数据链路层，它通过修改数据包目标的MAC地址，将数据包转发到实际服务器上。实际服务器处理完请求后直接把结果发送给客户端。
通过MAC找到目标服务器后，为什么目标服务器不吃惊呢？这个包的目标IP不是自己呀！为了解决这个问题，引入了IP别名的概念。每个服务器可以最多有256个IP别名。刚才这个服务器只要配置一个IP别名与网关服务器的IP一样即可。同一个网段，一个IP对应多个主机会比较混乱，不过网关服务器了解这个混乱的现状，它与这些服务器都是通过MAC通信，所以混乱对他来说不存在。
我们不妨这么理解这个过程：网关服务器收到一个数据包后，查看这个包的IP地址，然后用RARP协议问内网中的所有服务器，谁的IP地址是xxx.xxxx呢。马上有好几个服务器应答：是我！是我！应答中带着MAC地址。网关服务器从这些MAC中选出一个，填写到数据包中，然后发出去。底层硬件网络是通过MAC来寻址的，于是这个数据包顺利的流到了目标服务器。
为什么有了LVS-DR后还需要LVS-TUN呢？DR模式有一个要求：后端服务器与网管服务器必须处于同一个网段。这是基于MAC通信的基本要求。如果需要进行跨网段的负载均衡呢？这时候就需要隧道出马了。网关服务器把数据包原封不动的包装一下，利用普通的网络协议（所有linux都支持的隧道协议）把这个包发给目标网段的服务器，服务器收到包后会基于隧道协议把数据解出来，然后直接服务-----怎样才能直接服务呢？！当然了，LVS-TUN模式下的服务器也都必须支持IP别名的功能。凡是参与了服务的机器，都必须有一个与网管服务器IP一样的IP别名。
在学校的时候，大家不知是否有过这种经历：windows弹框曰：IP冲突，局域网中已经有人使用相同的IP。LVS下如何避免这个呢？需要告诉linux这个事实，遇到ARP异常的时候，just shut-up。例如：net.ipv4.conf.lo.arp_ignore = 1。具体可以参考：
http://blog./uid-24960107-id-193084.html
负载均衡的共性问题：
（1）如果需要维护连接状态，负载均衡策略需要保证同一个客户端请求总被路由到同一个服务器（或同一组共享状态的服务器）。大中型公司解决这个问题的一般方法是客户端（browser端）保留一个cookie，存储部分常用数据，服务端采用共享存储，存储部分key-value，key来自cookie。
（2）真正做到“均衡”并不容易，上面只是讲了负载均衡的基本方法，如何做到真的均衡，还有很多细节去解决。最完美的方式是能够实现反馈调节，动态均衡。
|
