分布式session的几个问题

[lee1473336489]

1. 如何保证一个sessionID是唯一的，用uuid已经被否定了。

2.把session的信息保存在缓存里面，如何准时的清楚过期的session信息。

[道秋adol]

[secondfirstlife]

session不是有时间的么，一般默认是半小时，不过可以配置，不管你放在哪里，session过期了，就会删除的，再访问的话就会创建新的session，除非你把session在用户登录的时候保存在数据库里边，然后再获取session，当然也是在session还存活的状态下，你说可能是你把创建的session保存下来，但怎么保证他不过期，还有一种方式吧session保存在cookie里边，我只是知道关闭浏览器，在此打开网页就不能获取到原来的session了，除非用上边的两种方式保存过sessionId

[lee1473336489]

引用 4 楼 secondfirstlife 的回复:

session不是有时间的么，一般默认是半小时，不过可以配置，不管你放在哪里，session过期了，就会删除的，再访问的话就会创建新的session，除非你把session在用户登录的时候保存在数据库里边，然后再获取session，当然也是在session还存活的状态下，你说可能是你把创建的session保存下来，但怎么保证他不过期，还有一种方式吧session保存在cookie里边，我只是知道关闭浏览器，在此打开网页就不能获取到原来的session了，除非用上边的两种方式保存过sessionId

把session信息保存在cookie里面，安全吗？

[lasereyes]

用数据库来存session，　将自增ID做session id

[secondfirstlife]

只保存sessionID

[lee1473336489]

引用 7 楼 lasereyes 的回复:

用数据库来存session，　将自增ID做session id

读硬盘太慢了，高并发有瓶颈... 自增的id不安全，容易被session攻击

[jakey188]

楼主可以试试MemcachedProviders

[lee1473336489]

引用 9 楼 kittying 的回复:

楼主可以试试MemcachedProviders

对，就是用的memcache。。。它的客户端提供了控制过期的API。。

[翱翔的苍鹰]

我觉还是用cookie吧，通过cookie可以保存session，你可以设置cookie的时间。

[jakey188]

引用 10 楼 lee1473336489 的回复:

[quote=引用 9 楼 kittying 的回复:] 楼主可以试试MemcachedProviders

对，就是用的memcache。。。它的客户端提供了控制过期的API。。[/quote] memcache客户端的实现有好几种，memcacheddotnet这个太久没更新不过提供的api是最全的,EnyimMemcached是memcacheddotnet的强化版本优化了算法,建议分布式缓存采用这个,共享session就用MemcachedProviders 用起来都比较简单

[lee1473336489]

引用 13 楼 pkudzy 的回复:

引用

把session信息保存在cookie里面，安全吗？

cookie中只保存session ID。这个session ID可以用算法产生，比如GUID就够用了，不放心的话，可以用自己的算法算出一个具长的Base64字符串（比如256个字符），不过也别太长，超过cookie的长度限制就挂了。 在TLS算法的HTTPS的支持下，cookie是安全的。 服务器端，可以把session ID和其他session数据保存在数据库中或者分布式缓存如memcached中。如果保存在数据库中，自己可以做一个background进程来监控session是否过期，如果过期，就从数据库中删除。如果保存在memcached中就简单了，直接给session记录设置一个过期时间。当然，用户如果在session过期之前有动作，就重置过期时间。

高，你说的和支付宝的分布式session一模一样。session是解决了，但是memcached还有很多问题，你知道如何保证在动态添加缓存节点的情况下，命中率达到百分之百吗？

[lee1473336489]

引用 14 楼 ldh911 的回复:

[quote=引用 楼主 lee1473336489 的回复:] 1. 如何保证一个sessionID是唯一的，用uuid已经被否定了。 2.把session的信息保存在缓存里面，如何准时的清楚过期的session信息。

这两个问题如果你使用支持集群的应用中间件，比如Tomcat或Weblogic等，只要正确配置了集群，都会被自动解决掉。所以，楼主先简单说说为啥要需要这么干？有什么特殊场景？这样才好针对性给出建议。[/quote] 访问服务器是非阻塞的，所以每次访问的服务器可能不一样，需要把session的信息存到缓存里面，所有需要一个sessionId来标识

[MiceRice]

引用 16 楼 lee1473336489 的回复:

访问服务器是非阻塞的，所以每次访问的服务器可能不一样，需要把session的信息存到缓存里面，所有需要一个sessionId来标识

那么我理解你的意思是：基于某种考虑，不想使用中间件自身所支持的集群能力。 那么另一个问题是负载均衡分发是否打算做“会话粘着”，不过看你的意思似乎也不打算做。 也就是总的来说，整个集群环境希望能做到彻底的云化。 那么刨开SessionID不说，因为这个总归有策略生成，无非是你是否打算在SessionID中包含一些语义。 你主要需要解决的问题是会话信息怎么管理，几个建议： 1、尽量减少会话信息规模，最精简的就是只剩 SessionID + UserID； 2、会话信息严禁存储业务过程状态，也就是仅仅是为了两个界面之间的数据衔接就用Sesion去存； 3、支持集群的缓存用于存储SessionID，这个成熟组件也不少，可以用MemCache或者有钱直接用内存数据库。 4、容错，缓存之所以叫做缓存，就是它可能把信息丢掉（甚至因为其中某节点故障）；所以要有机制可以只凭借SessionID，就能把会话中的状态信息恢复过来；如果还觉得蒙的话，想想单点登录中的自动登录过程。

[lee1473336489]

引用 17 楼 ldh911 的回复:

[quote=引用 16 楼 lee1473336489 的回复:] 访问服务器是非阻塞的，所以每次访问的服务器可能不一样，需要把session的信息存到缓存里面，所有需要一个sessionId来标识

那么我理解你的意思是：基于某种考虑，不想使用中间件自身所支持的集群能力。 那么另一个问题是负载均衡分发是否打算做“会话粘着”，不过看你的意思似乎也不打算做。 也就是总的来说，整个集群环境希望能做到彻底的云化。 那么刨开SessionID不说，因为这个总归有策略生成，无非是你是否打算在SessionID中包含一些语义。 你主要需要解决的问题是会话信息怎么管理，几个建议： 1、尽量减少会话信息规模，最精简的就是只剩 SessionID + UserID； 2、会话信息严禁存储业务过程状态，也就是仅仅是为了两个界面之间的数据衔接就用Sesion去存； 3、支持集群的缓存用于存储SessionID，这个成熟组件也不少，可以用MemCache或者有钱直接用内存数据库。 4、容错，缓存之所以叫做缓存，就是它可能把信息丢掉（甚至因为其中某节点故障）；所以要有机制可以只凭借SessionID，就能把会话中的状态信息恢复过来；如果还觉得蒙的话，想想单点登录中的自动登录过程。[/quote] 单点登录是用验证服务器吧，和我这不一样。。。。 是用的MemCache，但是问题不少，容错是这样的，MemCache+数据库，如何MemCache节点宕机了，就去数据库里面查。。不过还是问题很多的，做不到动态增删MemCache节点。

[MiceRice]

单点登录自身只是解决身份验证，但使用了单点登录服务的应用服务器，要能自动初始化所有Session信息。 MemCache本身是支持动态增删点的，但是显然一般不会选择业务高峰期来动态增删节点（除非是宕机了），否则会面临缓存失效问题。 不知道你说的去数据库查是指什么意思，如果是指重新初始化Session的话，基本上这个是标准做法了。比如Session中原来存储了 用户姓名、权限之类的数据，如果Cache中没有，就重新执行登录过程中初始化Session的那个函数以重建这个Cache。

[lee1473336489]

引用 19 楼 ldh911 的回复:

单点登录自身只是解决身份验证，但使用了单点登录服务的应用服务器，要能自动初始化所有Session信息。 MemCache本身是支持动态增删点的，但是显然一般不会选择业务高峰期来动态增删节点（除非是宕机了），否则会面临缓存失效问题。 不知道你说的去数据库查是指什么意思，如果是指重新初始化Session的话，基本上这个是标准做法了。比如Session中原来存储了 用户姓名、权限之类的数据，如果Cache中没有，就重新执行登录过程中初始化Session的那个函数以重建这个Cache。

单点登录还没开始做，马上会做的吧。。 MemCache集群使用的一致性hash算法，如何支持呢？你以前做过吗?现在这个问题很头痛。。 每次向缓存里丢东西，都会做持久化，也算是重新初始化Session吧。

[MiceRice]

一致性Hash算法，只能尽量减少cache集群中的机器数量增减的时候，cache的数据能进行最少重建。 但其实只要cache集群的server数量有变化，必然产生数据命中的问题（也就是部分缓存访问不到了） 这里： http://www.gosoa.com.cn/%E5%85%B3%E4%BA%8Ememcache%E5%88%86%E5%B8%83%E5%BC%8F%E4%B8%80%E8%87%B4%E6%80%A7hash 公司有项目做过，但我没有实际去配置。 “每次向缓存里丢东西，都会做持久化，也算是重新初始化Session吧。” —— 这个看起来不合理，每次写缓存都做持久化，降低了性能。不过如果更新频度极低的话，倒也可以接受。

[lee1473336489]

引用 21 楼 ldh911 的回复:

一致性Hash算法，只能尽量减少cache集群中的机器数量增减的时候，cache的数据能进行最少重建。 但其实只要cache集群的server数量有变化，必然产生数据命中的问题（也就是部分缓存访问不到了） 这里： http://www.gosoa.com.cn/%E5%85%B3%E4%BA%8Ememcache%E5%88%86%E5%B8%83%E5%BC%8F%E4%B8%80%E8%87%B4%E6%80%A7hash 公司有项目做过，但我没有实际去配置。 “每次向缓存里丢东西，都会做持久化，也算是重新初始化Session吧。” —— 这个看起来不合理，每次写缓存都做持久化，降低了性能。不过如果更新频度极低的话，倒也可以接受。

差不多，命中率最高达百分之92。。真的达不到百分之百。 因为是做钱支付的，所以信息丢不得。

[MiceRice]

引用 楼主 lee1473336489 的回复:

1. 如何保证一个sessionID是唯一的，用uuid已经被否定了。 2.把session的信息保存在缓存里面，如何准时的清楚过期的session信息。

这两个问题如果你使用支持集群的应用中间件，比如Tomcat或Weblogic等，只要正确配置了集群，都会被自动解决掉。所以，楼主先简单说说为啥要需要这么干？有什么特殊场景？这样才好针对性给出建议。

[闲云之然]

引用

把session信息保存在cookie里面，安全吗？

cookie中只保存session ID。这个session ID可以用算法产生，比如GUID就够用了，不放心的话，可以用自己的算法算出一个具长的Base64字符串（比如256个字符），不过也别太长，超过cookie的长度限制就挂了。 在TLS算法的HTTPS的支持下，cookie是安全的。 服务器端，可以把session ID和其他session数据保存在数据库中或者分布式缓存如memcached中。如果保存在数据库中，自己可以做一个background进程来监控session是否过期，如果过期，就从数据库中删除。如果保存在memcached中就简单了，直接给session记录设置一个过期时间。当然，用户如果在session过期之前有动作，就重置过期时间。