web集群中常用的session同步解决方案及对比

随着网站的功能越来越多，用户量越来越庞大，单节点模式已经严重不能支撑整个系统的正常运作，轻则用户页面访问时间越来越慢，重则就会导致整个系统瘫痪。这时候就需要优化或调整目前的架构，大部分人就会采用各种负载均衡软件例如nginx、hproxy、LVS等，也有的采用分布式的方式把系统根据功能拆分成很多系统，也有的根据地域和网络不同来实现访问不同节点部署的系统，也有的大型高流量、高负载的系统把负载均衡、分布式及根据地域、网络等这些方式都整合在一起来实现系统的正常运行。采用负载均衡软件是目前大家采取的比较多的方式。但是在采用负载均衡软件时将会面临session同步的问题。以下是解决问题的几种方式。1.客户端cookie加密的方式把session数据存放在cookie中，当请求过来时，从cookie中获取session数据。这种方式不需要任何的存储系统，也不会出现读写session数据带来的网络操作延时和不稳定性。但是有以下缺点：*Cookie有长度限制，这会影响session数据的长度。*安全性。session数据本来存储在服务端的，而这个方案是让session数据转到外部网络或客户端中，所以会有安全性问题。不过可以对写入Cookie的session数据做加密。*带宽消耗。由于加了session数据，带宽当然也会增加一点。*性能消耗。每次Http请求和响应都带有Session数据，对于Web服务器来说，在同样的处理情况下，响应的结果输出越少，支持的并发请求越。2.webserver的session复制方式大部分应用服务器都提供了session复制的功能来实现集群，tomcat、jboss、was都提供了这样的功能。session复制就是每台应用服务，都保存会话session数据。优点：靠应用容器来完成session共享，并不依赖应用，如果应用服务数量并不是很多，可以考虑；缺点：*同步session数据带来都网络开销。只要session数据变化，就需要同步到所有机器上，机器越多，网络开销越大。*由于每台服务器都保存session数据，如果集群的session数据很多，比如90万人在访问网站，每台机器用于保存session数据的内容占用很严重。3.使用关系数据库保存session用mysql、sqlserver等数据库保存session,就算服务器宕机了也没事，session照样在。缺点：*程序需要定制；*每次请求都进行数据库读写开销不小(使用内存数据库可以提高性能，宕机就会丢失数据。可供选择的内存数据库有BerkeleyDB,Mysql的内存表);4.使用nosql数据库保存session采用redis、mongodb、memcached等非关系数据库来实现session的共享。这些非关系数据库响应数据非常的快，而且支持的访问量也比较大。系统资源消耗也比较少。这也是很多系统所采用的方式。但是也有缺点：*读写session引入了网络操作，相对于本机读写session，带来了延时和不稳定性。*如Session集中服务有问题，会影响应用。5.采用SessionStick在单机情况，session保存在单机上，请求也是到这台单机上，不会有问题。变成多台后，如果能保障每次请求都到同一台服务，那就和单机一样了。这需要在负载均衡设备上修改。这就是SessionStick，这种方式也会有问题：*如果某一台服务器宕机或重启，那么这台服务器上的session数据就丢失了。如果session数据中还有登录状态信息，那么用户需要重现登录。*负载均衡要处理具体的session到服务器的映射。6.使用terracotta来保存session跟memcached类似，但是数据不需要序列化，并且是Find-GrainedChanges，性能更好。配置对原来的应用完全透明，原有程序几乎不用做任何修改。而且terracotta本身支持HA。综上所述，我个人推荐使用第4、6种方式来解决session共享的问题。