服务端Session管理

为什么80%的码农都做不了架构师？>>>   

之前的移动产品服务端，要求用户单点登录，自行管理会话。

客户端和服务端采用http post通信。

会话对象的内容包括openId，userId，tokenKey，timeOut

userId为系统内用户唯一编号

openId为userId在接入方映射出的唯一编号

tokenKey为会话密钥

timeOut为会话失效时间

用户登录成功后，Session对象同时写入DB和Cache（以openId做Key）,openId及tokenKey安全传递给客户端。

用户"关键"请求，需要在报文头传入openId和tokenSign（使用tokenKey加上流水及包体密文的摘要 共同计算出的一个摘要签名）。

服务端收到请求后，从Cache取Session对象，进行签名验证。

----------

多点登陆时，会更新DB及Cache中的tokenKey，旧的会话自动失效(签名无法通过)。

------------------

前期设计时，是使用sessionId，sessionKey,userId,timeOut共同组成Session对象，用户登陆后，sessionId和sessionKey都是随机生成，要实现单点登录，会带来一个问题：Cache中除了要存储一个userId为key的Session对象，还以存储一个以sessionId为key，userId为value的映射关系，每次验证单点登录，要进行两次Cache读，才能验证用户是否为单点登录。

因为不想将内部userId暴露给外部，所以，直接将sessionId变为openId，直接持久化，对不同的接入平台映射出不同的openId，这样在验证单点登录时，只需要一次Cache读即可。

转载于:https://my.oschina.net/kaster/blog/130861