分布式SESSION一致性

分布式SESSION一致性

SESSION是服务器为客户端创建的一个会话，存储用户的相关信息，用以标识用户身份等。在单服务器环境下是不需要考虑会话的一致性的问题的，但是在集群环境下就会出现一些问题，假如一个用户在登录请求时负载均衡到了A服务器，A服务器为其分配了SESSION，下次请求数据时被分配到了B服务器，此时由于B服务器不存在此用户的SESSION，此用户会被重定向到登录页面，这种情况是不合理的业务逻辑，所以需要维护SESSION的一致性。

解决方案

SESSION 同步

多个服务器之间互相同步SESSION，即A服务器生成一个SESSION信息后同步传输到B、C、D等服务器，同样B、C、D服务器生成SESSION信息后也需要同步到A，这样每个服务器之间都包含全部的SESSION

优点

• 大部分应用服务器都提供了SESSION复制的功能来实现集群

缺点

• SESSION需要网络传输进行同步，其会占用带宽，并且存在一定的延迟
• 一旦某台机器的SESSION信息有所变化，必须同步更新所有服务器SESSION内容
• 每个服务器都会存储全部的用户信息，性能随着服务器增加急剧下降，而且容易引起广播风暴

SESSION 映射

通过将负载均衡服务器进行修改，通过对返回给用户的SESSION ID或者用户请求的IP地址进行标记，也就是使用第四层传输层中读取网络层的IP或者是在第七层中读取HTTP协议中某些属性来做HASH，保证对于此用户的请求全部落到同一台服务器上

优点

• 实现相对简单
• 只要分配服务器时均匀，则多台服务器是负载均衡的

缺点

• 一旦某台服务器宕机，则会影响落在此服务器请求上的全部用户
• 负载均衡服务器变为了一个有状态的节点，内存消耗会更大，容灾更麻烦

客户端存储

将数据直接存储到客户端比如Cookie或请求头中，每次请求客户端自动携带数据信息

优点

• 简单，高效
• 服务端不需要储存标记用户信息

缺点

• 安全性较差，对于敏感信息必须加密
• 每次请求可能携带大量数据，占用外网带宽
• 数据存储在客户端就会存在泄密、篡改、窃取等隐患

后端集中存储

将SESSION存储在一台单独的服务器中的数据库中，例如Mysql、Oracle、SqlServer、Redis、Mongodb等等，各SERVER服务器需要用户信息时携带SESSION ID对于集中存储服务器进行请求，进而获取用户信息

优点

• 没有安全隐患
• 可以方便的水平拓展
• SERVER服务器重启不会造成SESSION丢失

缺点

• 每次请求都增加了一次对于存储服务器的网络请求
• 会对集中存储服务器存在大量请求，数据库压力比较大

每日一题

https://github.com/WindrunnerMax/EveryDay

参考

https://www.jianshu.com/p/5caed857dc3e
https://www.cnblogs.com/study-everyday/p/7853145.html