最近学到的知识有些多啊，小脑袋都快有些不够用了。先把自己的一些感悟写在这里，等回来再细细品味，哈哈哈
| 在开始了解session共享机制之前，先来看看cookie机制与session机制： |
HTTP 协议本身是无状态的，这与HTTP协议本来的目的是相符的，客户端只需要简单的向服务器请求下载某些文件，无论是客户端还是服务器都没有必要纪录彼此过去的行为，每一次请求之间都是独立的，好比一个顾客和一个自动售货机或者一个普通的（非会员制）大卖场之间的关系一样。
session是服务器用来跟踪用户的一种手段，每个Session都有一个唯一标识：session ID。当服务器创建了Session时，给客户端发送的响应报文包含了Set-cookie字段，其中有一个名为sid的键值对，这个键值Session ID。客户端收到后就把Cookie保存浏览器，并且之后发送的请求报表都包含SessionID。HTTP就是通过Session和Cookie这两个发送一起合作来实现跟踪用户状态。
也就是说 cookie的作用就是为了解决HTTP协议无状态的缺陷。至于后来出现的session机制则是又一种在客户端与服务器之间保持状态的解决方案。同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制来达到保存标识的目的，但实际上它还有其他选择。
1、该店的店员很厉害，能记住每位顾客的消费数量，只要顾客一走进咖啡店，店员就知道该怎么对待了。这种做法就是协议本身支持状态。
2、发给顾客一张卡片，上面记录着消费的数量，一般还有个有效期限。每次消费时，如果顾客出示这张卡片，则此次消费就会与以前或以后的消费相联系起来。这种做法就是在客户端保持状态。（Cookie原理）
3、发给顾客一张会员卡，除了卡号之外什么信息也不纪录，每次消费时，如果顾客出示该卡片，则店员在店里的纪录本上找到这个卡号对应的纪录添加一些消费信息。这种做法就是在服务器端保持状态。(Session原理)
所以，session相对cookie更加安全，因为用户拿到的仅仅只是一个sessionID，和实际记录的状态值没有任何关系，这就意味着用户没有办法通过sessionID去推测服务器是通过什么样的值，什么样的逻辑来实现状态的判断，也就没有办法去破解服务器的状态验证机制
| 为什么要实现Session共享： |
咱们做的考试系统，学生答题的时候是将学生的答题记录存到了不同的服务器上面。有可能这一道题的记录存到了12服务器，服务器返回给用户一个sessionid，另一道题则存在了13服务器，服务器也返回给用户一个sessionid，如果两台服务器没有做session共享，那么返回给用户的sessionid就是不一样的。如果网络出现了问题，或者学生在答题过程中不小心退出了系统，重新登录时，就会没有答题记录。（这个机制有点儿复杂，感觉一两句话写不清楚，如果感兴趣，可以拉着我给你讲讲~），大概就是这样的意思吧。
所以，为了防止学生二次登录时，没有答题记录，我们要做session共享。
| 集群下实现Session共享的几种方案 |
1.请求精确定位：基于IP地址的Hash策略，将同一用户的请求都集中在一台服务器上，这台服务器上保存了该用户的Session信息。缺点：单点部署发生宕机时，Session丢失。
2.Session复制共享：比如可以用Tomcat自带的插件进行Session同步，使得多台应用服务器之间自动同步Session，保持一致。如果一台发生故障，负载均衡会遍历寻找可用节点，Session也不会丢失。缺点：必须是Tomcat和Tomcat之间，Session的复制也会消耗系统 的性能，使得同步给成员时容易造成内网流量瓶颈。（目前咱们采用的是这种方案）
3.基于cache DB缓存的Session共享（推荐，Spring-Session也是同样的原理，同自定义的JRedis一起配置可以实现目的）:使用Redis存取Session信息，应用服务器发生故障时，当Session不在内存中时就会去CacheDB中查找（要求Redis支持持久化），找到则复制到本机，实现Session共享和高可用。
分布式Session配置原理图：
感觉这些知识也不少了，慢慢消化吧~