shiro 采用redis共享session，出现反序列化错误的排查过程

这是一个老系统改造的过程，该老系统采用的框架是#jfinal# shiro redis,采用outh2协议的方式，对多个子系统之间进行单点登录，以实现系统之间的session，由于速度方面的影响，现在要改造成多个系统之间共享session，并采用redis集群的方式。

        说明一下当前项目的整体运行环境，此项目的多个子系统都在同一个域名下，通过上下文不同来区分子系统。

        以下将记录整个改造过程，采用jfinal+shiro+redis集群方式，集群采用redis官方的redis cluster方式来进行部署集群，该方式需要改造java客户端连接方式。

       以下简单记录整个集成过程中出现的几个坑，共享session中，shiro+redis的实现思路，继承EnterpriseCacheSessionDao类，重写doCreate，doDelete,doUpdate,doReadSession方法，将SimpleSession通过序列化的方式，放入redis中，然后在另一个系统中进行反序列化该对象，以此来完成共享session。但是在反序列化的过程中出现反序列化错误，unable to find class for code 105.等奇奇怪怪的错误，这是由于一个子系统放入session中的对象，在另一个系统中不存在该对象，或是存在该对象，对象中的字段不同导致，反序列化错误很难排查，因为在redis中存入的是二进制方式，如果要排查的话，需要将redis中存储的key通过单独运行反序列化程序来还原对象，来对比两个系统之间对象字段中的差异，而且需要在两个子系统中运行，但不能交叉运行。A系统放入session到redis中，B系统访问时报了反序列化错误，然后导致整个系统都瘫痪，都报了反序列化错误，为什么一个子系统出现反序列化错误导致整个系统出现反序列化错误的原因还没有找到，总之是共享session反序列化中对象字段不一致导致的，简单的说就是A,B两个子系统放入的session里的字段，对象不同，A系统有，而B系统有该对象但和A系统的字段不同，导致在反序列化时出现该问题。排查该问题需要仔细核对子系统中每个放入到session中的对象是不是和另一个子系统中的相同即可。