session服务器干什么用的？Session服务器的作用与用途详解

Session服务器就是专门负责存放和分发用户会话状态的“记忆管家”，它把用户登录态、购物车、浏览记录这类数据从每台应用服务器里抽出来集中保管，让整个集群共享同一份session数据，彻底解决多机环境下用户掉线的问题。

平时你在家里打开某个网站，登录以后切几个页面，登录状态还在，这就靠session在背后撑着，session原本放在Tomcat这类应用服务器的内存里，进程一重启，用户就被迫下线，单台服务器时，这问题不严重，但网站流量一大，前面架了负载均衡，后面挂着三五台应用服务器，问题就来了，用户在A服务器登录，下一个请求被调度到B服务器，B服务器的内存里根本没有这条session记录,用户直接被踢回登录页。

有经验的运维看到这里大概会心一笑，这种session丢失问题在电商大促期间尤其致命，用户刚把商品塞进购物车，刷新一下购物车空了,这种体验基本上等于把用户往外赶。

session服务器是什么，为什么它是分布式系统的定海神针

session服务器解决的两个核心痛点

• 第一个痛点是session丢失，请求在多台服务器之间飘来飘去，session却固定在一台机器上,找不到就成了必然结果。
• 第二个痛点是session管理失控，每台服务器的session各自为政，没有统一的生命周期管理，想统计在线人数、想让某个用户强制下线,运维根本无从下手。

session服务器干的事情很简单，它把所有session数据集中到一个独立的地方存储，应用服务器只负责处理业务逻辑，需要session时去这台服务器上取，用完再还回去，这么一改，集群里任何一台服务器都能读到同一个用户的session，用户无论被负载均衡分发到哪个节点，体验都是无缝的。这套机制，撑起了绝大多数中型以上网站的登录态和购物车功能。

session服务器本身也是一种架构模式

session服务器不是一个特定软件的名称，而是一类职责的统称，你可以用Redis搭，用Memcached搭，甚至用MySQL搭，只要它能承接session数据的读写，并对外提供统一访问入口，它就是一台session服务器，这个理解很重要，因为不少开发者在选型时纠结“用哪个产品”，其实更应该纠结“用哪种模式”。

session服务器和redis区别：别把收银台当成收银员

不少刚接触这个概念的工程师会混淆两个名词，session服务器和redis区别在于：

session服务器是逻辑概念，Redis是实现这个逻辑的存储载体，就好比“收银台”和“收银员”的关系，收银台是功能区域，收银员是具体干活的人，session服务器描述的是一个职责,而Redis是当下实现这个职责最流行的工具。

在真正的生产环境中，多数工程师说的“搭一台session服务器”，本质就是部署一个Redis实例，再让应用框架（比如Spring Session）把session交给Redis管理。

下表把常见方案的优劣摆在一起对比：

行业共识认为，只要不是极端特殊的业务，直接用Redis作为session服务器就够了，网上那些宣称“必须自研session服务”的说法,大概率是在制造焦虑。

什么时候该用独立session服务器，什么时候不该用

• 只有一台应用服务器，负载小，session直接放本地内存就行,多加一台独立服务器属于画蛇添足。
• 两台以上服务器构成集群，或者已经在用负载均衡,那就应该上session服务器。
• 如果项目用的是微服务架构，每个服务独立部署，session服务器几乎是刚需，否则用户在一个服务里登录,另一个服务根本不认识他。

session共享服务器怎么配置：最省心的Redis方案实操

网上关于session共享的教程不少，但大多又臭又长，这里给出一条最短路径，以Spring Boot项目搭配Spring Session为例,整个过程不超过三步。

第一步，在pom.xml里引入依赖。

<dependency
>
    <groupId>org.springframework.session</groupId>
    <artifactId>spring-session-data-redis</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

第二步，在配置文件application.yml里指向你的Redis地址。

spring:
  application:
    name: session-server-demo
  redis:
    host: 192.168.1.100
    port: 6379
    password: yourpassword

第三步，启动类上什么都不用多做，Spring Boot的自动配置已经接管session，原来你在代码里用HttpSession的地方依旧照常使用,框架自动把session存到Redis里。

这是不是比想象中简单？Spring Session的价值就在于此，它帮开发人员屏蔽了底层细节,让你无感切换存储方式。

老项目不改代码的方案

如果是一个运行多年的老系统，动代码成本太高，可以考虑Tomcat层面的第三方插件，比如tomcat-redis-session-manager，改一个context.xml，加几个参数,Tomcat自带的session存储就被替换成了Redis。

<Valve className="com.orangefunction.tomcat.redissessions.RedisSessionHandlerValve" />
<Manager className="com.orangefunction.tomcat.redissessions.RedisSessionManager"
         host="192.168.1.100"
         port="6379"
         database="0"
         maxInactiveInterval="60" />

注意这个插件新旧版本差异比较大，网上搜到的配置五花八门，建议直接去GitHub仓库看对应版本的README,别拿老版本配置硬套新版本。

session服务器集群部署方案：别让这台服务器自己先倒下

做了session集中之后，架构里又多了一个单点，session服务器一挂，整个系统所有用户集体掉线，这比原来多台应用服务器各自为政的故障面更大，所以session服务器自身的集群高可用,必须提前设计。

最常用的主从加哨兵结构

Redis官方的哨兵（Sentinel）机制是多数项目的标配，一台主节点负责读写，一台或多台从节点负责备份，哨兵进程监控主节点的心跳，主节点挂了，哨兵自动把从节点提拔成新的主节点，整个过程对应用是无感的,用户不会察觉到任何抖动。

部署架构上，主节点和从节点放在不同机柜甚至不同可用区，万一一个机房断电，另一个机房的从节点依然能顶上，这套方案的开源成本为零,也是最稳妥的起步选择。

避免的关键误区

有些工程师图省事，把session直接存到本地内存，再用广播把session同步给其他服务器，这在节点数超过三个以后，广播风暴和内存膨胀会拖垮整个集群，会话数据是状态，状态就应该集中存放,这是session服务器存在的基本逻辑。

session服务器多少钱，预算怎么排

成本问题决定了方案能不能落地，先给结论：其实大部分项目在session服务器上的花费接近零。

• Redis本身是开源软件,License费用为0。
• 自建的话，一台2核4G的云主机按目前行情，包年大概在几百到一千多元的区间,这个预算对大多数公司毫无压力。
• 用云厂商的托管Redis服务，按量付费起步价不高，每月的成本取决于存储量，大部分中小项目的会话数据撑死几十MB到几个GB,月费用大多在几十元到几百元之间。
• 真正花钱的地方是运维人力，配置、监控、扩缩容,这些隐性成本往往被低估。

预算充足的大型企业，直接买商业版Redis或者用云上的集群版，自带高可用、数据持久化、可视化运维，省心但费钱，预算紧张的小团队，用开源版加一堆脚本管理，多花点时间,也完全够用。

常见问题解答

session服务器是什么？

它是把Web应用的用户会话数据集中存储的服务器角色，通常由Redis等内存数据库充当，目的是让负载均衡后的多台应用服务器共享同一份session数据,用户不会因为请求被分发到不同节点而掉线。

session和cookie的区别是什么？

cookie存储在浏览器本地，体积限制在4KB左右，每次请求自动携带，存放的是会话标识符这类客户端数据，session存储在服务器端，存放的是登录状态、购物车等敏感信息，浏览器只保存一个对应的session ID，两者经常配合使用：用户首次访问，服务器生成session ID，把它写入cookie,之后浏览器带着cookie中的ID来认领服务器上的session数据。

什么时候需要独立部署session服务器？

当应用服务器的数量超过一台并启用了负载均衡，或者计划做水平扩展时，就该部署独立的session服务器，低于这个规模，session直接放在应用服务器内部就好,部署独立的session服务器反而是过度设计。