选择会话状态存储方式的多维权衡框架

在客户/服务器/数据库三种会话状态存储方式之间做选择，需要同时权衡多个维度。带宽：客户会话状态要求每次请求都把会话数据整个通过网络传送，数据量小尚可接受，一旦数据量大（书里提到有团队用到过三部莎士比亚戏剧那么大的会话数据）带宽压力会非常可观，即便压缩也未必够用——因此除非会话状态确实很小，否则不建议用客户会话状态。安全与完整性：客户端数据必须防范恶意用户篡改，不加密就可能出现”自己定价”式的漏洞（用户直接改价格）。隔离性：会话数据原则上不该影响会话之外的任何东西（比如没确认的航班预订不该影响其他用户），数据库会话状态在这一点上最棘手，需要额外花力气把会话数据和真正的持久记录数据隔离开。集群与迁移：用户多到需要集群时，要考虑”会话迁移”（一次会话的请求可以被不同服务器接力处理，均衡负载更好，但服务器会话状态难以支持，因为只有处理过该会话的服务器才容易找到其状态）还是”服务器亲和”（同一会话的请求固定绑给同一台服务器，代价是可能因代理IP合并而意外把大量不同用户的流量集中压到一台服务器上）。响应性：服务器会话状态能直接访问、无需转换；客户/数据库会话状态都需要额外的格式转换或查询开销。取消会话的处理：B2C场景里用户经常”人间蒸发”而不是显式退出，客户会话状态天然能应付（忘掉就是了），其余方式则必须主动检测并清理失效会话，或依赖支持会话超时的系统。系统失效恢复：数据库会话状态能扛住客户端崩溃、服务器崩溃、网络中断三种情况；服务器会话状态能否扛住取决于是否落到了持久存储介质；客户会话状态扛不住客户端崩溃，但能应付另外两种。开发代价：服务器会话状态通常最省事（尤其不需要持久化时），客户/数据库会话状态都要花额外精力做数据解析转换。

结构图：

flowchart TB
  A["会话状态存储方式选型维度"]
  A --> B["带宽:客户端方式随数据量线性增长"]
  A --> C["安全性:客户端数据需防篡改/加密"]
  A --> D["隔离性:数据库方式需额外隔离会话数据与记录数据"]
  A --> E["集群支持:会话迁移(服务器方式难) vs 服务器亲和(可能负载集中)"]
  A --> F["响应性:服务器方式免转换最快"]
  A --> G["会话取消处理:客户端方式天然免清理"]
  A --> H["系统失效恢复:数据库方式扛全部三种崩溃"]
  A --> I["开发代价:服务器方式通常最省事"]