概述
每一次web请求，其实是通过sessionId来标识请求会话的。
1、用户端成功请求登录接口并且验证身份通过时，服务端记录该次session信息，并把seesionId返回给用户端，用户端将该信息存入cookie。
2、当同个用户再发起新的请求时，会把sessionId带上，服务端通过对比已有session信息，可识别用户身份。
更详细的描述过程
1、用户向服务器发送用户名、密码、验证码用于登陆系统。
2、服务器验证通过后，服务器为用户创建一个 Session，并将 Session 信息存储起来。
3、服务器向用户返回一个 SessionID，写入用户的 Cookie。
4、当用户保持登录状态时，Cookie 将与每个后续请求一起被发送出去。
5、服务器可以将存储在 Cookie 上的 SessionID 与存储在内存中或者数据库中的 Session 信息进行比较，以验证用户的身份，返回给用户客户端响应信息的时候会附带用户当前的状态。
使用 Session 的注意事项
1、依赖 Session 的关键业务一定要确保客户端开启了 Cookie。
2、注意 Session 的过期时间。
多服务器节点下 Session-Cookie 方案如何做？
当服务器水平拓展成多节点时，会导致用户登录信息不同步的问题。
参考方案：
1、某个用户的所有请求都通过特性的哈希策略分配给同一个服务器处理。这样的话，每个服务器都保存了一部分用户的 Session 信息。服务器宕机，其保存的所有 Session 信息就完全丢失了。
2、每一个服务器保存的 Session 信息都是互相同步的，也就是说每一个服务器都保存了全量的 Session 信息。每当一个服务器的 Session 信息发生变化，我们就将其同步到其他服务器。这种方案成本太大，并且，节点越多时，同步成本也越高。
3、单独使用一个所有服务器都能访问到的数据节点（比如缓存）来存放 Session 信息。为了保证高可用，数据节点尽量要避免是单点。