集群环境下session方案好还是no session方案好

Question

    集群环境下，必然需要考虑用户和会话的问题，如果不加处理的话，一旦后端IP轮询切换，session也就断了。所以就有了4种方案。先说下session的问题，tomcat在启动时就会创建一个session，当会话越多的时候，session也就越多。而session在tomcat中属于重量级对象。一个没有任何内容的空session就需要消耗1.5K的内存存储空间

  1.tomcat自带的方案，session复制，笨重低效，基本上是淘汰的方案。

  2.nginx第三方扩展的sticky粘滞，把会话和后端IP绑定，比较简单，但个人感觉不是很可靠。

  3.基于redis等nosql的session集中存储，tomcat配置也比较简单。这种最流行，但仍然存在以下问题：（1）redis有单点，并且增加了系统复杂度。(2)用来连接redis的jedis性能不稳定，高并发下很容易挂，这点看到过不少反馈。

  4.纯cookie，不使用session，天然分布式。存在的问题：（1）cookie需要加解密，性能消耗要考虑，而且不能存太多东西，序列化本身消耗也不少。(2)每次请求都会带上cookie，包括JS和CSS等请求，浪费宽带，除非部署了CDN或专用服务器。

  究竟哪种方案更好呢？

Answer 1

我现在有遇到类似的问题不过是发布订阅还有连接池相关的问题。很难排查

Answer 2

引用来自“DavidWho”的评论

我觉得在多用户量，高并发的情况下，应该少用/不用session，转用token与openid等方式验证用户。

而session的集群使用没有实践过，就不猜测了。

Answer 3

引用来自“雨翔河”的评论

高并发尽量少用，可以用redis＋缓存 来解决。楼上有人说redis挂了怎么办，我想说发电站还会停电呢，怎么破？

Answer 4

高并发尽量少用，可以用redis＋缓存 来解决。楼上有人说redis挂了怎么办，我想说发电站还会停电呢，怎么破？

Answer 5

必须
redis，redis也可以上集群哈

Answer 6

把会话数据放到cookie里不安全吧，有被用户篡改的可能性。而且用户在不同设备登录同一账号的会话数据也不能实现共享。cookie对应的数据放到数据库或Redis做集中式存储个人感觉还是有必要的。

Answer 7

个人觉得选3 , 

Answer 8

引用来自“eechen”的评论

JS和CSS以及图片等静态资源放到另一个域不就好了么?这样这些请求就不会带上cookie.

cookie用于标记用户身份,每次请求验证是必然的,验证就是一次数据库查询,并不需要加解密和序列化.用户的会话数据可以保存在MySQL内存表或者Redis中.

Answer 9

回复
redis的HA方案还是挺多的，比如codis，这些目前来说应该算是比较成熟的方案，我是建议放在redis里面保存session信息

Answer 10

看到不少人使用jedis在并发高的时候出现过不稳定的问题。jedis我用过，但都是并发不高的场景，暂时没遇到。但还是有这个担心

Answer 11

回复
codis还用了ZK，复杂度大增。当然稳定问题是解决了

Answer 12

放在redis里面比较稳妥吧，况且jedis没那么不可靠吧。。。

Answer 13

放在内存表里，怎么保证集群环境下每个用户的请求落在同一台机器呢

Answer 14

回复
我这个帖子说的方法跟具体语言无关.

Answer 15

JS和CSS以及图片等静态资源放到另一个域不就好了么?这样这些请求就不会带上cookie.

cookie用于标记用户身份,每次请求验证是必然的,验证就是一次数据库查询,并不需要加解密和序列化.用户的会话数据可以保存在MySQL内存表或者Redis中.

Answer 16

一般只有单点登录时才会使用token和openid。一般来说session是我们在服务端保持用户会话信息常用的方法，尤其是企业应用开发领域

Answer 17

回复
谢谢解答！但企业应用应该不会有高并发等问题吧？集群环境是否浪费性能了？

Answer 18

回复
企业应用同样会有高并发的场景的。其次，企业应用与互联网应用是一样的，同样需要通过集群来做高可用负载和容灾，除非用户访问量很小并且可以随意停机维护的那种不太重要的旁门应用就可以不考虑集群部署

Answer 19

回复
恩，想想也是，毕竟大公司是有需求的可能，的确是个需要架构考虑的问题。我有时候遇到不懂得事情会想着怎么逃避，是个不好的习惯，学习了。再次感谢！

Answer 20

我觉得在多用户量，高并发的情况下，应该少用/不用session，转用token与openid等方式验证用户。

而session的集群使用没有实践过，就不猜测了。

Answer 21

1，放弃使用session，就算同步策略非常优秀，但是造成的网络风暴不可避免

2，sticky粘滞会导致无法热切换，存在运维问题

3，如果是jedis的锅，是否有代替方案，因为目前redis等KV工具还是广泛使用的，如果担心单点问题，可以仿照osc的j2cache自己弄一个redis + db

4，结合业务，看下面总结

总结：结合业务

如果每次请求都需要获取当前认证用户的较多相关信息，ID哈希后查DB是一个好办法，但如果是并发高的系统，只能寻找redis等代替方案

如果只显示个名字什么的，直接双向加密存cookie，那么点数据量对于整个请求和响应来说比重并不高，至于CPU消耗，系统是NodeJS开发的？