简述

用户的状态存放在客户端, 就叫做 cookie
用户的状态存放在服务器, 就叫做 session

session 指的存放在服务器侧的 这个用户的状态合集, 当然也不一定必须是用户的;
sessionID 可以理解为是 这个 session 的名字, 服务器端可以方便的通过这个 id 找到这个 session；

客户端每次请求携带此 ID, 就可以方便服务器找到这份状态数据;

优点

1. 服务器控制方便, 可以随时对 session 进行过期
2. 业务逻辑方便, 可以在用户状态数据中附加其它信息

缺点

1. 如果有多个应用节点, 需要考虑 session 信息的同步或集中存放;
2. 如果用户量较大时, 需要很多的内存;
3. 多应用模式跨域问题; 例如在 A 系统登录, 然后单点到 B 系统，然后再 C 系统注销;

客户端如何保存和传输 sessionID

1. cookie 保存
2. URL重写，即放置在URL参数中
3. 隐藏表单，即服务器会自动修改表单，添加一个隐藏字段;
   以便在表单提交时能够把 session id 传递回服务器
4. http header

一般产生和使用流程

1. 用户传递帐号密码进行登录
2. 服务器校验通过后，生成用户状态数据(即 session)
3. 服务器根据状态产生一个关联的 id, 即 sessionID, 发送给客户端
4. 客户端后续每次请求都携带此 sessionID
5. 服务器根据用户请求时携带的 sessionID，来查询和操作用户的状态;

分布式架构中的session保持

方法一: session 同步

不同 server 间同步 session；
优点: 业务代码不需要多修改，只要 webserver 支持同步即可
缺点: session 同步占带宽、有时延，每个节点都需要全量数据、占空间，扩展不便,
而且不能跨应用(如 java和go), 或跨业务系统

方法二: 客户端存储

也就是 以 cookie 的方式使用 session, 流程上几乎没区别; 但客户端可以更换所存储的 header 位置;
即客户端内带上 session ，每次请求时在 cookie 中带上;
优点：服务器不需要存储 session
缺点：每次请求都带上占带宽，不安全，session大小受 cookie 限制；

方法三: 反向代理HASH

可以通过源IP地址或用户ID等业务属性等进行HASH计算，如请求中携带的 UID, user_id等唯一信息；
优点：不需要后台做任何改变，支持水平扩展；
缺点：如果webserver重启或扩展，都会暂时影响到一部分用户；

方法四: 集中式存储

如数据库、redis、memcached等做集中 session 存储
优点：安全、水平扩展方法，重启webserver不会影响用户
缺点：增加了一级网络调用和序列化,反序列化

一般而言

1. 单节点应用, 就简单使用 session 最合适

2. 双节点主备应用, 可以考虑 session 同步的方式

3. 多节点应用推荐集中式缓存 session 方式

4. 反向代理模式，更多是属于组合手段使用, 不单独使用；
   例如在不方便对单节点业务进行改造但需要扩容时使用, 或者业务量非常大时

5. 如果状态数据过多, 可以考虑把部分状态数据放置到 cookie 内;

6. 什么时候推荐使用 jwt 方式呢？
   跨多个业务系统时，或者是跨中心不方便同步 session 时。