在Apache Tomcat 7设置redis作为session store

redis已经有组件支持直接在tomcat7中设置下将redis作为tomcat默认的session存储器，下面介绍下配置过程

1.从http://redis.io/下载redis，按照redis服务端

  wget http://download.redis.io/redis-stable.tar.gz

  tar xvzf redis-stable.tar.gz

  cd redis-stable

  make

2.启动redis

  cd RedisDirectory/src

  ./redis-server --port 6379

3.从http://tomcat.apache.org/download-70.cgi下载tomcat7，按照tomcat7

4.从https://github.com/xetorthio/jedis/downloads下载jedis作为java的redis客户端，

从https://github.com/jcoleman/tomcat-redis-session-manager/downloads下载tomcat的redis session manager插件，

从http://commons.apache.org/proper/commons-pool/download_pool.cgi下载apache的common pool包，

将这几个jar包拷贝到tomcat7的lib目录下

其实这里是有坑的，不过你们比较幸运，我帮你先踩了。如果你全部下载最新版本的话，肯定启动不起来。我试了很久才匹配这些jar的版本。在附件中可以下载。声明一下我用jdk是1.7的

5.修改tomcat的conf下的context.xml文件，添加或者修改下面的配置

Java代码  

1. <Valve className="com.radiadesign.catalina.session.RedisSessionHandlerValve" />  
2. <Manager className="com.radiadesign.catalina.session.RedisSessionManager"  
3. host="localhost" <!-- optional: defaults to "localhost" -->  
4. port="6379" <!-- optional: defaults to "6379" -->  
5. database="0" <!-- optional: defaults to "0" -->  
6. maxInactiveInterval="60" <!-- optional: defaults to "60" (in seconds) --> />  

6.重启tomcat后就可以看到session存储到redis上了。

------------------------------------------------------------------------------------------------

Possible Issues

There is the possibility of a race condition that would cause seeming invisibility of the session immediately after your web application logs in a user: if the response has finished streaming and the client requests a new page before the valve has been able to complete saving the session into Redis, then the new request will not see the session.

This condition will be detected by the session manager and a java.lang.IllegalStateException with the message Race condition encountered: attempted to load session[SESSION_ID] which has been created but not yet serialized.will be thrown.

Normally this should be incredibly unlikely (insert joke about programmers and "this should never happen" statements here) since the connection to save the session into Redis is almost guaranteed to be faster than the latency between a client receiving the response, processing it, and starting a new request.

If you encounter errors, then you can force save the session early (before sending a response to the client) then you can retrieve the current session, and call currentSession.manager.save(currentSession) to synchronously eliminate the race condition. Note: this will only work directly if your application has the actual session object directly exposed. Many frameworks (and often even Tomcat) will expose the session in their own wrapper HttpSession implementing class. You may be able to dig through these layers to expose the actual underlying RedisSession instance--if so, then using that instance will allow you to implement the workaround.