cas入门之二十九:cas 集群简介

cas的集群主要分为两部分，一是session的集群，二是登录之后产生的ticket的集群。
对于登录之后产生的ticket的集群，则相对容易，根据我前几篇文章可以找到答案，这两部分可以通过组合完成，达成相应的目的。
对于cas ticket集群，目前测试通过的有三种方式
1.jpa ticket repository 参看  cas 入门之十五：ticket 存储方案-jpa ticket存储
2.echcache ticket repository　参看  cas 入门之十六：ticket 存储方案之ehcache ticket存储

3.memcached ticket  repository　参看 cas 入门之十七：ticket 存储方案-memcached ticket 存储，

我应用的服务器是tomcat，对于tomcat的session复制及会话粘性的方法有如下方案：

a.udp session 复制(组播方式multicast)，
b. memcached-session-mamanger 方式
c.会话粘性利用nginx-upstream-jvmroute,当然这个用到nginx(我测试了一下，只能应用nginx-upstream-jvm-route-0.1.tar.gz及nginx-1.2.9.tar.gz)。
那么如何进行cas 集群，则可以通过这两部分进行任意组合。初始的时候，我个人认为，只需要将ticket进行外部存储就可以了，没有必要进行tomcat的session复制，但是这个是错误的，下面我给大家分析一下为什么是错误的。
tomcat1:192.168.1.100:8080　　
tomcat2:192.168.1.100:8070
nginx 192.168.1.100:80 进行负载均衡tomcat1,tomcat2
数据库oracle 10g,通过jpa的方式将ticket进行外部存储，而两个tomcat并没有session复制
测试，步骤１，登录 http://192.168.1.100:8080/cas　再登录http://192.168.100:8070/cas直接进去了，这说明什么了呢？这说明ticket已经共享了，而且8070服务器能够读取
8080服务器产生的cookie。为什么？
测试，步骤２，登录　http://192.168.1.100/cas   输入正确的用户名密码，则一直出现登录页面，而并没有登录成功，为什么呢？因为cas 登录上下文是有内容的，而不是无状态，比如login ticket,所以需要进行tomcat1,tomcat2的session复制。当然有些时候，对于多应用连接cas，也不一定需要集群，比如可以将一部分应用连接到tomcat１上，另一部分应用连接tomcat2上，并且tomcat1,tomcat2有相同的顶级域名，ticket通过外部存储共享，这也能达到应用的性能提升。但这并不是完美的解决方案，因为每个cas服务器仍然是单点。