web集群中经常使用的session同步解决方式及对照

Posted 2020-09-23 brucemengbm

  随着站点的功能越来越多，用户量越来越庞大，单节点模式已经严重不能支撑整个系统的正常运作，轻则用户页面訪问时间越来越慢。重则就会导致整个系统瘫痪。这时候

就须要优化或调整眼下的架构，大部分人就会採用各种负载均衡软件比如nginx、hproxy、LVS等，也有的採用分布式的方式把系统依据功能拆分成非常多系统，也有的依据地域

和网络不同来实现訪问不同节点部署的系统。也有的大型高流量、高负载的系统把负载均衡、分布式及依据地域、网络等这些方式都整合在一起来实现系统的正常执行。

採用负载均衡软件是眼下大家採取的比較多的方式。可是在採用负载均衡软件时将会面临session同步的问题。

下面是解决这个问题的几种方式。

1. clientcookie加密的方式

把session数据存放在cookie中，当请求过来时。从cookie中获取session数据。这样的方式不须要不论什么的存储系统。也不会出现读写session数据带来的网络操作延时和不稳定性。

可是有下面缺点：

* Cookie有长度限制，这会影响session数据的长度。

* 安全性。

session数据本来存储在服务端的，而这个方法是让session数据转到外部网络或client中。所以会有安全性问题。只是能够对写入Cookie的session 数据做加密。

* 带宽消耗。因为加了session数据。带宽当然也会添加一点。
* 性能消耗。每次Http请求和响应都带有Session数据。对于Webserver来说，在相同的处理情况下，响应的结果输出越少，支持的并发请求越。

2. web server的session复制方式

大部分应用server都提供了session复制的功能来实现集群。tomcat、jboss、was都提供了这种功能。session复制就是每台应用服务。都保存会话session数据。

长处：

靠应用容器来完毕session共享，并不依赖应用。假设应用服务数量并非非常多，能够考虑。

缺点：

  * 同步session数据带来都网络开销。

仅仅要session数据变化，就须要同步到全部机器上，机器越多，网络开销越大。
  * 因为每台server都保存session数据，假设集群的session数据非常多。比方90万人在訪问站点。每台机器用于保存session数据的内容占用非常严重。

3. 使用关系数据库保存session     

用mysql、sqlserver等数据库保存session,就算服务器宕机了也没事，session照样在。

缺点：

*程序须要定制。
  *每次请求都进行数据库读写开销不小(使用内存数据库能够提高性能，宕机就会丢失数据。

可供选择的内存数据库有BerkeleyDB,Mysql的内存表);

4.使用nosql数据库保存session

採用redis、mongodb、memcached等非关系数据库来实现session的共享。这些非关系数据库响应数据非常的快，并且支持的訪问量也比較大。系统资源消耗也比較少。这也是非常多系统所採用的方式。

可是也有缺点：

* 读写session引入了网络操作。相对于本机读写session，带来了延时和不稳定性。

* 如Session集中服务有问题，会影响应用。

5.採用Session Stick

在单机情况。session保存在单机上，请求也是到这台单机上，不会有问题。变成多台后，假设能保障每次请求都到同一台服务。那就和单机一样了。 这须要在负载均衡设备上改动。这就是Session Stick。这样的方式也会有问题：

* 假设某一台server宕机或重新启动。那么这台server上的session数据就丢失了。假设session数据中还有登录状态信息。那么用户须要重现登录。

* 负载均衡要处理详细的session到server的映射。

6.使用terracotta来保存session

跟memcached类似，可是数据不须要序列化。并且是Find-Grained Changes。性能更好。

配置对原来的应用全然透明，原有程序差点儿不用做不论什么改动。并且terracotta本身支持HA。

综上所述。我个人推荐使用第4、6种方式来解决session共享的问题。