nodejs+express的session使用

今天终于使用nodejs+redis把网页版即时聊天框架zenkim搭了起来,非常简陋,不过登录/用户管理/实时消息推送/消息缓存/用户单实例登录控制deng基本能力都有,待完成的功能包括:消息持久化及活动用户队列周期扫描/加强事务能力/消息排序/界面美化/移动版本支持。再优化一下后放到github上。

 

今天花了一下午时间,都用在了处理session上。nodejs本身不管session,因为用了express框架,express基于connect,connect中有session管理的能力。connect是插件式架构,它的插件称之为“中间件”,其中有个中间件就是叫作session。

 

使用express命令搭建应用框架时,加上-s选项,就可以添加对session的支持,之后在url映射函数中,直接使用req.session就可以访问和添加session信息。

 

问题是这样的:为了浏览器兼容,zenkim使用long polling方式实现实时消息推送。这就要求除了正常的浏览器请求链接外,还有一个后台链接用作推送消息,该链接的response对象能够长期(几秒到几分钟)保存在后台。开始时将response对象保存在了session中(当然,后来发现这么做不合适,并且有错),但发现后台链接session中的对象,在正常浏览器请求的session中看不到。不是同一个浏览器看到的session数据应该是同一份吗?为什么出现这种情况?

 

后来还是看了session这个connect中间件的代码才了解原委。session保存在称为sessionStore的数据仓库中。默认使用MemoryStore,就是所有session信息都保存在内存中。每来一个请求后,在路由分发前,首先使用cookieParser中间件将cookie中的sessionID解析出来,然后根据sessionID去sessionStore中进行查找,如果找到一份session后,就使用sessionStore中的数据构建一个新的session对象,把这个session对象放到req.session中,这就是session的由来。

 

另外,session中间件还改写了res.end方法,在将应答发送回浏览器之前,先将session数据写回sessionStore。

 

从实现过程可以看出:

1. 每个session对象都是针对某一个http请求的,每个请求的session对象相互独立,互不影响。

 

2. 在没有调用res.end之前,session对象不会回写到sessionStore中,除非主动调用了session.save方法。

 

3. session的解析依赖cookieparser,因此cookieparser中间件应该放到session之前。路由处理函数依赖session数据,因此app.router中间件应该放到session之后

 

4. 因每个请求有独立的session对象,因此对于同一个客户端有多个链接的情况,需要考虑session回写的并发问题。

 

所以在将res对象放到后台请求的session中后,同一时刻前台请求的session中是看不到这个res对象的。可以在放置了res之后,立刻调用session.save方法将信息保存回sessionStore,此时前台请求才可能看到。

 

不过这里要是调用session.save的话会报错,说session数据有循环依赖,无法保存回sessionStore。实际上是session数据如果有循环依赖的话,无法使用JSON.stringify转化为字符串,而memorystore使用字符串保存session数据,所以会出错。

 

解决办法是将res保存到内存中的一个临时数据结构中。这个res中有大量链接/socket/应用/请求信息,的确不适合保存到session中,另外res只是一个临时的链接数据,缓存在内存即可,也的确不应该放到session中。而将res放到内存中,所有请求都可以看到,这时会有并发问题。谢天谢地,node.js是单线程的,虽然一堆回调让代码不知什么时间会运行,但至少同一个函数中代码的前后顺序还是可以保证的,中间不会插入执行其他代码,函数内部保证数据访问的一致性就好了。

 

你可能感兴趣的:(session)