前端用户请求经过随机分发之后，可能会命中后端任意的Web Server，并且 Web Server
也可能会因为各种不确定的原因宕机。在这种情况下，session 是很难在集群间同
步的，而通过将session 以sessionid 作为key，保存到后端的缓存集群中，使得不管请求如何分
配，即便是Web Server 宕机，也不会影响其他Web Server 通过sessionid 从Cache Server 中获得
session，这样既实现了集群间的session 同步，又提高了Web Server 的容错性。
这里以 Tomcat 作为Web Server 来举例，通过一个简单的工具memcached-session- manager9，
实现基于memcache 的分布式session。
memcached-session-manager 是一个开源的高可用的Tomcat session 共享解决方案，它支持
Sticky 模式和Non-Sticky 模式。Sticky 模式表示每次请求都会被映射到同一台后端Web Server，
直到该Web Server 宕机，这样session 可先存放在服务器本地，等到请求处理完成再同步到后端
memcache 服务器；而当Web Server 宕机时，请求被映射到其他Web Server，这时候，其他Web
Server 可以从后端memcache 中恢复session。对于Non-Sticky 模式来说，请求每次映射的后端
Web Server 是不确定的，当请求到来时，从memcache 中加载session；当请求处理完成时，将session 再写回到memcache。
以 Non-Sticky 模式为例，它需要给Tomcat 的$CATALINA_HOME/conf/context.xml 文件配
置SessionManager，具体配置如下：
<Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="n1:192.168.0.100:11211,n2:192.168.0.101:11211"
sticky="false"
sessionBackupAsync="false"
lockingMode="auto"
requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"
transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"
/>
其中：memcachedNodes 指定了memcache 的节点；sticky 表示是否采用Sticky 模式；
sessionBackupAsync 表示是否采用异步方式备份session；lockingMode 表示session 的锁定模式；
auto 表示对于只读请求，session 将不会被锁定，如果包含写入请求，则session 会被锁定；
requestUriIgnorePattern 表示忽略的url；transcoderFactoryClass 用来指定序列化的方式，这里采用
的是Kryo 序列化，也是memcached-session-manager 比较推荐的一种序列化方式。
memcached-session-manager 依赖于memcached-session-manager-${version}.jar，如果使用的是
tomcat6，则还需要下载memcached-session-manager-tc6-${version}.jar，并且它还依赖memcached-
${version}.jar 进行memcache 的访问。在启动Tomcat 之前，需要将这些jar 放在$CATALINA_
HOME/lib/目录下。如果使用第三方序列化方式，如Kryo，还需要在Web 工程中引入相关的第三方
库，Kryo 序列化所依赖的库，包括kryo-${version}-all.jar 、kryo-serializers-${version}.jar 和
msm-kryo-serializer. ${version}.jar。