关于.Net Web开发中数据暂存方法的概述

2019年06月27日 浏览量:274

我们在开发中,肯定是需要用到数据交互的,我们常用的数据保存的地方正常情况下还有三个,分别是:Cookie,内存,数据库。

首先来说道Cookie,大家应该都知道,Cookie是存储在客户端的,用户是可以清除的。

所以在我看说Cookie的应用范围:存储当前会话的标识,便于在每次请求的时候服务器好识别出这次会话是由哪个客户端发出的,在经典的.NET Web Forms的开发模式中,用户只要访问了网站,服务器都会给客户端返回一个Session_ID存在Cookie中,来记录这次会话。

还有一种基于Cookie的会话认证就是JWT(json web Token),Token认证:JWT的原理跟SessionID基本类似,也是返回一个字符串存于Cookie中,然后每次访问的都会附带Token请求,可以附带在请求头或者Cookie中,然后服务器解密Token,如果有效,就接收此次会话,此方法肯定是需要建立一个Token表来维护Token的有效性,实际上Session也是这样的,只不过来验证Session是否有效的操作交给应用程序,程序员不用关心。

那两者之间的区别呢?

我认为两者之间的区别主要有以下几点(不分优劣):

1.JWT会附带一些用户不敏感的信息,这样会减少服务器内存的压力或者是数据库查询的压力;如果是Session,这样的数据要么是存在Session(内存)中,要么就是存在数据库中,都需要额外的去查询一次。

2.由于JWT是无状态的,在服务器有集群的情况下,可以很好的适用服务器故障;比如我有五台服务器做集群,在用户访问到A服务器,然后A服务器突然故障,如果是Session模式,那么用户再次访问就必须在进行一次用户认证,因为Session是存在于A服务器的内存中,除非是服务器做了Session共享。JWT就不会出现,JWT只会请求Token维护表来判断认证状态。

续集:

但是有的朋友提出来,那你的数据库服务器挂了,JWT岂不是也没意义,这种我们一般做数据库同步订阅,如果某台服务器挂了,及时切换过去,就能完成无缝的切换。为什么我不建议Session共享,是因为Session会给服务器性能压力,内存压力,一般都不会做Session共享。

本人现在也是用Sesson模式,但是我的Sesson并不是存储在内存中,而是存储在数据库中,然后数据库也是做一个同步订阅,这样既可以减轻内存的压力,也可以未雨绸缪,当主数据库挂了,马上切换到订阅数据库。这样跟JWT模式就无差别了,唯一的差别在于,需要在去查询一次数据库来读取数据。存储Session的数据库最好不要和开发数据库创建在一起,新建一台数据库服务器来专门用于管理Session。如果配上负载均衡,这种模式可应用中型项目的架构选择,如果是访问量较大的项目可扩展硬件来应用此模式,基本都能适应。

最后本人在项目中两种模式都在使用,取长补短。

至于Session怎么存在数据库中,可以参考我的这篇文章:ASP.NET中的会话状态模式详解

评论区:

昵称:
内容:
验证码: 4292