软件负载均衡

      负载均衡分为传输层负载均衡和应用层负载均衡，同时，负载均衡可以更典型的分为软件负载均衡和硬件负载均衡。硬件负载均衡一般用于传输层负载均衡。一般来说，硬件负载均衡快于软件负载均衡，但它的缺点是比较昂贵。与硬件负载均衡相比，基于软件的负载均衡一般跑在操作系统和专门的负载均衡硬件节点上或者直接在应用上。

 

传输层负载均衡：
1.DNS负载均衡，通过域名解析，随机获取server的ip地址。
     缺点：dns查询频繁，如果减少查询，本地cache server地址，则如果server 不可用的时候，本地cache将继续拥有无效的地址
2.TCP/IP server负载均衡，是一种low-level负载均衡，比较流行的有LVS，LVS在TCP层做负载均衡。LVS有两种路由方式：1.NAT方式，即请求和响应都过虚拟server。2.Direct Server Return,返回不需要经过虚拟server。如果应用需要sticky，low-level的负载均衡将没法做到。一般可以通过统一的cache来移除对sticky的依赖，但对cache如果访问频繁，cache性能是一个问题，同时额外的网络开销和server延迟也是问题。
     传输层负载均衡的基本结构都类型，简单，灵活，高效，并且对客户端不需要做任何限制。这种架构一般结合统一cache来解决状态的问题。但如果cache（数据大小，访问量，响应时间）成为瓶颈的话，这种架构的弊端将暴露出来。

     如果需要sticky，则需要引入应用层负载均衡。

应用层负载均衡：

1.通过代理转发请求，代理根据http body中的某个值或者cookie中的某个值来寻找server。通过http请求转发
     缺点：需要多加节点来做代理
2.利用http的redirect来转发请求。通过设置http head中的Location，重定向的请求将不会经过负载均衡，直接请求到后面的server。
    缺点：1。由于后面server直接暴露给客户，将有安全隐患。

             2。跟第一种方式一样，如果后台server出问题了，那么这些请求还是会请求这些server。
3.通过拦截server请求在server上做负载均衡，跟方法1相同，只是不需要另外的节点，并且如果请求的是本地机器，则不需要通过http请求来转发。
    优点：减少了转发节点
    缺点：不能应用于大量server的场景。
4.不需要网络层负载均衡，直接在客户端做拦截，类似于memcached的客户端负载均衡。
    优点：这种方式非常有效，非常高效，并可以大规模扩展。
    缺点：但对浏览器方式的客户端非常不利，跟http redirect一样，会将后端直接暴露给外面。并且存在跨域问题。
5.利用jboss的smart stub来实现，利用stub实现远程服务接口。
6.利用apache的mod_proxy_balancer结合tomcat来实现。通过在JSESSIONID中增加路由信息，通过建立tomcat集群以及保存session，到共享目录来达到session信息的一致性。

 

当然除上面方法以外还可以利用硬件负载来解决。