用Redis来搞会话管理其实挺方便的，支持啥功能一目了然，redis会话那些事儿

用Redis来搞会话管理其实挺方便的,支持啥功能一目了然，redis会话那些事儿

这事儿得从头说起,以前做网站，用户登录后的状态，也就是会话（Session），很多都是存在服务器自己的内存里，比如你用Tomcat，会话就默认放Tomcat自己的内存中，这么干有个挺麻烦的问题，就是如果你的网站用了多台服务器，做了负载均衡，用户第一次请求可能打到A服务器，登录了，会话存在A上；结果第二次请求，负载均衡器把他指到B服务器去了，B服务器上压根没有他的会话信息，系统就认为他没登录，这就乱套了，用户还得重新登录，体验非常差。

这时候Redis就显出好处了,Redis本身就是一个独立于所有应用服务器的、集中式的内存数据库，我们可以把所有的会话数据都存到Redis这个统一的“仓库”里，这样一来，不管用户的请求被分配到后端的哪一台服务器，这台服务器都可以去同一个Redis里查找和操作这个用户的会话数据，这就完美解决了会话在多个服务器之间共享的问题，也就是所谓的“分布式会话”问题，这可以说是用Redis管理会话最核心、最吸引人的一个好处了。

那具体怎么存呢？很简单，我们会给每个用户会话生成一个唯一的ID（比如一个很长的随机字符串），当用户登录成功后，我们把这个ID通过Cookie的方式发给用户的浏览器，浏览器之后每次访问网站，都会自动带上这个Cookie，服务器拿到这个ID，就可以把它当作Key，去Redis里查询对应的会话数据了，会话数据本身（比如用户ID、用户名、登录时间、权限列表等等）可以用Redis的Hash结构来存储，因为Hash很适合表示一个对象，简单点直接用String存个JSON字符串也行，这种Key-Value的模型，跟会话的概念天然契合，用起来非常顺手。

除了共享会话,Redis还有个杀手锏功能，就是给数据设置过期时间，会话这东西通常不是永久有效的，用户可能半小时不操作就自动退出了，如果用传统数据库存会话，还得写个定时任务，隔一段时间就去扫描清理过期的会话，又麻烦又耗资源，Redis就省事了，你在存入一个会话Key的时候，直接用一个命令，EXPIRE key seconds，给它设置一个生存时间，比如1800秒（半小时），过了这个时间，Redis会自动把这个Key（连同它里面的所有会话数据）给删除掉，这个自动过期的特性简直是给会话管理量身定做的，大大减轻了开发者的负担。

再说说性能,会话的读写是非常频繁的操作，用户每个请求都可能要读取甚至更新会话信息（比如更新最后操作时间），Redis的数据都在内存里，读写速度极快，通常能达到微秒级别，完全能够应对高并发的会话访问需求，不会成为网站的瓶颈，相比之下，如果为了共享会话而去用传统的关系型数据库（比如MySQL），频繁的IO操作很可能就把数据库压垮了。

还有啊,Redis支持持久化，虽然会话数据通常不是那么关键，丢了顶多让用户重新登录，但有些场景下我们可能还是希望会话能有一定的可靠性，别一重启Redis全没了，Redis提供了RDB（快照）和AOF（日志）两种持久化方式，可以根据需要选择配置，就算Redis重启了，也能从磁盘上恢复数据，保证了数据的可靠性。

Redis的功能很丰富,如果你想实现一个“强制下线”的功能，管理员在后台踢掉某个用户，你只需要直接删除Redis中对应的那个会话Key，下次这个用户的请求再来时，就会发现会话找不到了，自然就被判定为未登录状态，再比如，你可以很方便地统计当前在线用户数，大概就是查看一下Redis里有多少个带特定前缀的会话Key（更精确的做法可能需要其他数据结构辅助）。

用Redis也不是说就一点注意事项都没有,你得确保Redis服务本身是高可用的，如果Redis挂了，那所有用户都相当于退出登录了，网站基本就瘫痪了，所以生产环境通常会给Redis做主从复制、哨兵机制或者集群部署，来保证它的高可用性，会话数据毕竟包含了用户的状态信息，如果Redis服务器暴露在不安全的环境下，也存在被窃取会话的风险，所以网络安全配置也要做好。

用Redis来搞会话管理,确实像题目里说的，“挺方便的，支持啥功能一目了然”，它凭借其内存级的性能、原生的过期机制、丰富的数据结构以及作为集中式存储带来的分布式支持，成为了实现高效、可靠会话管理的一个非常流行和实用的选择，很多互联网公司现在都是这么干的，可以说是经过大规模实践检验的成熟方案了。