session中间件里的sessionID（以下简称sid）的算法为24byte的全随机。sid重复的可能性比较小，但理论上还是有重复的可能。 session中间件的session维护流程为：
（一）新session的创建
（1）将option里配的sessionStore挂到req上；
（2）修改res.end函数，在原函数基础上加入req.session.save操作（就是往sessionStore里存session）；
（3）新session的接入，因为是新session，所以cookie里没有sid信息。随机一个sid，以此sid来创建session，然后将session绑到req上；然后将req和res交给下个中间件或流程处理。
（二）旧session接入
（1）同上边的第（1）步；
（2）同上边的第（2）步；
（3）cookie里有sid，根据这个sid去sessionStore里取回session信息；如果session过期就取不到session了，就像上边的（3）里那样重新创建一个session。
为了完全消除sid的重复性带来的影响，就要检查新创建的sid是否已经存在与sessionStore里了。
session中间件的结构在express的以后版本中还会修改，所以我不想动session中间件的源码。于是只能在新session创建后的我自己的逻辑流程中来处理。逻辑流程中，当http包为登陆验证包时，将session中间件给创建的session的sid拿到sessionStore里去查下是否已被使用，如果使用就干掉当前session，并通知当前客户端重试。
干掉当前session有个技巧，就是直接（req.session=null;）这样即可，因为修改后的res.end里，判断如果req.session未定义，就不会再去调用req.session.save了。当前session是一定不能让他save的，否则就拿当前用户的信息覆盖了之前用此sid的用户，造成那个用户后续逻辑混乱。