解决方案
1.负载均衡器
每个机器只放自己的session。
基于负载均衡器的hash映射，每次同一个用户的请求(ip相同)，映射到同一个服务器。
2.集中式
每个机器放所有的session。
基于缓存中间件或数据库实现。
工作使用
支付系统
基于负载均衡器nginx
即时通信
基于redis或者直接http session
负载均衡器
集中式
需要组件
1.操作数据
session框架，比如spring-session框架
2.存储数据
缓存中间件redis
参考 segmentfault.com/a/119000001…
最佳实践
一线互联网公司一般使用集中式解决方案。
后端统一集中存储
思路：将session存储在web-server后端的存储层，数据库或者缓存
优点：没有安全隐患
可以水平扩展，数据库/缓存水平切分即可
web-server重启或者扩容都不会有session丢失
不足：增加了一次网络调用，并且需要修改应用代码
对于db存储还是cache，个人推荐后者：session读取的频率会很高，数据库压力会比较大。如果有session高可用需求，cache可以做高可用，但大部分情况下session可以丢失，一般也不需要考虑高可用。
总结
保证session一致性的架构设计常见方法：
session同步法：多台web-server相互同步数据
客户端存储法：一个用户只存储自己的数据
反向代理hash一致性：四层hash和七层hash都可以做，保证一个用户的请求落在一台web-server上
后端统一存储：web-server重启和扩容，session也不会丢失
对于方案3和方案4，个人建议推荐后者：
web层、service层无状态是大规模分布式系统设计原则之一，session属于状态，不宜放在web层
让专业的软件做专业的事情，web-server存session？还是让cache去做这样的事情吧。
参考
www.primeton.com/read.php?id… //写的超级好，一文看懂发展历史：1.单体：基于tomcat会话 2.分布式：基于负载均衡器——映射ip到同一个tomcat 3.分布式服务：基于集中式解决方案
www.cnblogs.com/study-every… //非常好，有说原因
