apache tomcat负载均衡总结

1  proxy、proxy_blancer和mod_jk的比较

• proxy的缺点是，当其中一台tomcat中止运行的时候，apache仍然会转发请求过去，致使502网关错误。可是只要服务器再启动就不存在这个问题。
• mod_jk方式的优势是，Apache 会自动检测到中止掉的tomcat，而后再也不发请求过去。
  缺点就是，当中止掉的tomcat服务器再次启动的时候，Apache检测不到，仍然不会转发请求过去。
  
• proxy和mod_jk的共同优势是.能够只将Apache置于公网，节省公网IP地址资源。
  能够经过设置来实现Apache专门负责处理静态网页，让Tomcat专门负责处理jsp和servlet等动态请求。
  共同缺点是：若是前置Apache代理服务器中止运行，全部集群服务将没法对外提供。
• proxy和mod_jk对静态页面请求的处理，均可以通设置来选取一个尽量优化的效果。
  mod_proxy_balancer和mod_jk都须要修改tomcat的配置文件配合
  <Engine name="Catalina" defaultHost="localhost" jvmRoute="tomcat1">
• 这三种Tomcat集群方式对实现最佳负载均衡都有必定不足，mod_proxy_balancer和mod_jk相对好些，mod_jk的设置能力更强些。lbfactor参数来分配请求任务。
• apache自带mod_proxy功能模块中目前只能够实现两种不一样的负载均衡集群实现方式，第一种是分工合做的的形式，经过各台主机负责不一样的任务而实 现任务分工。第二种是不一样的机器在担任一样的任务，某台机器出现故障主机能够自动检测到将不会影响到客户端，而第一种却不能实现但第一种实现方式的优势在 于他是主服务器负担相应没第二种大由于台只是提供跳转指路功能，形象的说他不给你带路只是告诉你有条路能够到，但到了那是否能够看到你见的人他已经不会去管你了。相比之下第二种性能要比第一种会好不少；但他们都有个共同点都是一托N形式来完成任务的因此你的主机性能必定要好

2 session同步

• 对于tomcat的集群有两种方式，这个主要是针对session而言的。一种就是sticky模式，即黏性会话模式；另一种就是session复制模式了。

   2.1 sticky模式

• 利用负载均衡器的sticky模式的方式把全部同一session的请求都发送到相同的Tomcat节点。这样不一样用户的请求就被平均分配到集群 中各个tomcat节点上，实现负载均衡的能力。这样作的缺点是没有灾难恢复的能力。一旦一个节点发生故障，这个节点上全部的session信息所有丢 失；
• 这种方式实际上是由前端balancer实现的，基本不须要webServer作任何改动（只须要修改jvmRoute="tomcat1"）
• 同一用户同一session只和一个webServer交互，一旦这个webserver发生故障，本次session将丢失，用户不能继续使用

  2.2 复制模式

• 利用Tomcat session复制的机制使得全部session在全部Tomcat节点中保持一致。当一个节点修改一个session数据的时候，该节点会把这个 session的全部内容序列化，而后广播给全部其它节点。这样当下一个用户请求被负载均衡器分配到另一个节点的时候，那个节点上有完备的 session信息能够用来服务该请求。这种作法的问题是对session哪怕有一点点修改，也要把整个sessions数据所有序列化 （serialize），还要广播给集群中全部节点，无论该节点到底需不须要这个session。这样很容易会形成大量的网络通讯，致使网络阻塞。通常采 用这种方式，当Tomcat节点超过4个时候，整个集群的吞吐量就不能再上升了；
• 此方式是经过tomcat自己提供的功能，只须要修改server.xml文件
  （1）修改Engine节点信息： <Engine name="Catalina" defaultHost="localhost" jvmRoute="tomcat1">
  （2）去掉<Cluster> <\Cluster> 的注释符
  （3）web.xml中增长 <distributable/>

   2.3 Terracotta模式

• 另外一种方式就是利用开源软件Terracotta。Terracotta的基本原理是对于集群间共享的数据，当在一个节点发生变化的时 候，Terracotta只把变化的部分发送给Terracotta服务器，而后由服务器把它转发给真正须要这个数据的节点。这样对网络的压力就很是小， 各个节点也没必要浪费CPU时间和内存进行大量的序列化操做。把这种集群间数据共享的机制应用在session同步上，至关于对tomcat第二种集群实现 机制进行了优化，既避免了对数据库的依赖，又能达到负载均衡和灾难恢复的效果。在对比测试中，采用Terracotta搭建Tomcat集群，节点达到8 个时候，整个集群的吞吐量还一直是线性增加的。

   2.4 三种模式比较

• sticky模式最大的缺点就是不支持failover，一旦某一个webServer发生故障则此节点上的session就会丢失，所以不建议使用。
• 复制模式能够保证个别节点发生故障不丢失session，可是复制时须要序列化数据这会影响到系统的性能。
  另外性能随着服务器增长急剧降低，并且容易引发广播风暴。经测试当Tomcat节点超过4个时候，整个集群的吞吐量就不能再上升了。
  须要修改server.xml和web.xml文件
• 使用第三方软件Terracotta进行session同步，配置对原来的web应用彻底透明，原有程序不用作任何修改。。
  数据不须要序列化，也不占用webServer的内存，执行效率高。
• terracotta自己支持HA，增长了系统的稳定性。
• Terracotta是开源的，而且能够集成在不少主流的开源软件中，如Jetty、Tomcat、Spring、Geronimo和EHCache等。

 以上内容都摘抄至：http://www.cnblogs.com/leader_89/archive/2011/08/01/2109181.html

下面来讲写本身的认识：

我的感受seession复制在一些小应用的范围仍是可采用的，可是当集群到必定的数据量这种方案就不可取了。当数据量大时，网络开销也会随着大，同步效率就会随之下降。

解决方案：

当集群到了必定的数量后咱们能够采用统一用cache管理Session的方式

 1，Memcached Session Manager 采用Memecached来统一管理Session，由于Memcached是分布式的，因此Memcached的量也能够随意横向拓展。（）

2，tomcat-redis-session-manager （采用Redis来维护Session，目前不清楚有哪些人用了这个方案）

3，采用Client Cookie来维护Session，目前不少网站都是采用的这种方案(oschina,iteye,tieba....)

ps:最近本身弄了一个Client Cookie维护Session的列子，准备过几天发上来和你们交流交流（最近整理好了，地址点这里）