上篇博客已经说了单点退出是怎么实现的，同时也留下了隐患，就是在集群下的客户端可能出现退出概率有效。而导致这个结果的就是因为我们客户端无法根据服务端传过来的st来找到相应的session，所以就无法清空。在最早之前，我们没有考虑到集群和分布式的时候，我们是这样来使用cas和客户端的交互 
我们通过cas提供的客户端核心包来进行cas服务器和cas客户端的通信。而在一系列的校验通过后，cas会为客户端生成session，而这个session也是保留在客户端的内存中，这就是最早期的结构，对于这种方式下的cas是不会出现退出失败的，因为你的session和st是唯一的，也只有一个客户端，所以只要客户端能收到服务端退出的消息，就能退出成功。
但是当我们系统的流量越来越多的时候，我们发现一个服务器顶不住流量的压力的时候，我们应该怎么办呢，这时候我们一定是要进行集群。
既然说到集群，那么我就简单的介绍下集群和分布式的区别：
集群：同一个业务，部署在多个服务器上（是不是很简单）。
分布式：一个业务分拆多个子业务，部署在不同的服务器上。
而我们针对上面的来说就是要进行集群化了，尤其是针对微服务系列，你可以根据哪些服务访问的流量大，而相应的增加微服务的集群数量。而集群和分布式都要考虑的问题就是session的共享问题，这个可是很头疼的问题？不过好歹现在市面上有好多方法解决这个问题，用的最多的就是redis来共享session，就是将session存到redis中，不同的集群下带来的sessionid是相同的，通过sessionid去redis判断是否存在这个session，通过这种方式来达到集群的session共享。同时我们的交互方式就演变成这样了。
这样就可以达到我们服务集群的部署，同时也可以有效的减轻单个服务器的压力。
说了这么多好像没有讲关于集群退出的方式（马上就开始讲）。
上面已经说了对于集群方式来说我们是使用redis来共享session的，所以这个时候对于我们单点退出的服务器来说，cas客户端的session是存在redis中的，所以我们销毁他直接可以通过设置redis的sessison的某个参数来销毁他。
如果在自己的页面传进来进行退出的话就好办，好办在与你能拿取到sessionid，然后在去销毁他，但是单点退出的原理我上篇博客已经说了，他并不是你一一操作每个客户端进行退出的，那么不是这样的话，就无法带着sessionid来进行session的销毁。我们的单点退出是通过cas服务端的logout来触发客户端的退出（下节讲解下cas服务端退出的源码），而服务端是不知道你每一个sessionId的，可能有的人说，那么我们可以在cas服务端存储每一个客户端的id，但是你想过没有，cas客户端的session生成的时候是在什么时候？你如果知道这个过程你就不会想这个方法。
我们知道服务端在退出的时候，是发出如下格式的请求 
上面的格式中有个叫sessionindex的东西，而这个东西就是st，服务端会将每一个登录成功后的客户端的st票据给缓存下来，然后退出的时候会将st发送到客户端。客户端根据这个票据来寻找相应的session来进行退出。而我们客户端在保存session的时候会将st和session保存到map中，st做为key，session做为value，然后退出的时候可以根据服务端传过来的key来找value并进行销毁。通过上面的流程我们可以在st做文章，这个时候我们可以修改cas提供的客户端核心包，我们自己手动将st和sessionid存到redis中。
在普通的java程序下，我们也可以不这样搞，通过集群的广播，什么意思呢？就是在web.xml中我们配置客户端集群的服务器地址，然后在cas服务器退出的请求，判断传过来的st票据能否找到对应的session，如果找不到的话，那么一定不再这个客户端中，那么就进行广播，知道找到这个st的value为止，然后取销毁他，这种确实是一种方法。网上也有这种方式，但是我还没试验过这种方式，但是理论上是可以的。还有一种方式就是使用nginx中的iphash，将相同的ip路由到同一个服务器，这个也能达到要求。不过不建议这样搞
我的方式是将st和sessionid存到redis中（修改源码的），然后在退出的时候，我会根据st去map中查找，如果没有找到的话，那么就不在这个客户端中，那么我就通过redis来查找这个sessionid并取出，然后在进行销毁，同时删除缓存的st来达到集群的单点退出。
可能这篇文章没有给你们代码事例，这篇文章主要是给大家一个解决方案的思路，而我们的代码是需要在源码里面修改的，所以可以查看下一节的源码讲解，下一节会贴上解决的代码