17.2 服务器会话状态

为什么 17.2 服务器会话状态 值得单独学习

订单向导通常跨越地址、配送和付款确认多个请求。页面需要继续知道用户已经填写了什么，但每次请求又不应该把可篡改的购物车正文当成事实来源。服务器会话状态把“谁拥有事实”这个决定摆到架构台面上：客户端只负责带回定位线索，服务器负责读写、授权、过期和恢复语义。

这不是“把对象塞进内存”这么简单。会话记录要有清楚的会话标识，存储层要能保存可恢复的版本，节点之间还要约定读取不到记录时是重新开始、转移到副本，还是向用户报告失效。若这些决定只藏在框架默认值里，正常请求通过也不等于架构完成。

本页以 2024 年中文版公开目录限定 17.2 服务器会话状态 的范围，并依据 Martin Fowler 的作者图书页和模式目录独立重写。下面的案例、实验、代码、判断题和答案均为本课程原创，不复现原书正文、插图或代码。

先建立直觉：状态到底由谁保管

先预测：如果请求只携带 sid=abc123，节点 A 读取服务器记录后把购物车数量从 2 更新为 3，下一次请求被路由到节点 B，哪一个对象必须能解释这次变化？答案应该是服务器端的会话存储，而不是 Cookie 中的一段未经保护的购物车正文。

服务器保存状态时，至少要定义四个边界：定位凭证是否可验证，资料是否能被序列化，旧记录怎样按TTL清理，以及多节点是否共享同一份权威记录。状态越敏感、越大或越需要跨请求一致，服务端边界越有价值；代价则是存储容量、网络往返、复制和恢复责任。

这里的“服务器端”不等于“某一台应用进程的内存”。单节点内存能快速返回，却会把扩缩容和故障恢复变成隐形的粘性会话依赖。共享存储、复制内存或明确的丢失语义，才是多节点设计可以评审的选择。

目录单元到教学证据

17.2 服务器会话状态

在 17.2 服务器会话状态 的学习边界里，问题不是记住某个框架的 Session API，而是把“请求 → 会话标识 → 状态位置 → 更新 → 过期”责任链画出来。对订单向导会话，学习者应能指出谁保存事实、谁作业务决定，以及记录消失后结果是否可解释。

专属代码案例：订单向导的会话边界

下面的代码只展示模式边界，不绑定生产框架。会话存储接口返回服务器自己的记录；请求 DTO 只接收步骤输入，不能让客户端用整个对象覆盖存储记录。

type OrderSession = {
  id: string;
  version: number;
  cartItemCount: number;
  expiresAt: number;
};
 
type SessionStore = {
  load(id: string): Promise<OrderSession | null>;
  save(next: OrderSession, expectedVersion: number): Promise<void>;
};
 
export async function addItem(
  store: SessionStore,
  sessionId: string,
): Promise<OrderSession> {
  const current = await store.load(sessionId);
  if (!current || current.expiresAt <= Date.now()) throw new Error("session-expired");
  const next = { ...current, cartItemCount: current.cartItemCount + 1, version: current.version + 1 };
  await store.save(next, current.version);
  return next;
}

这段代码有两个故意的约束：sessionId 只用于定位，购物车数量从服务端当前版本计算；expectedVersion 让存储层可以拒绝基于旧记录的覆盖。实际系统还要把会话标识绑定到登录主体、轮换凭证，并限制单条记录大小。

主图把这条责任链拆成五个可观察事件。动手试：先点“下一步”预测记录怎样变化，再播放到过期和故障转移；随后打开错误模式，观察把 cart=999 放进请求正文为何越过了服务器权威边界。

三步快照：从定位到恢复

下面的 Stepper 将主图压缩为三张确定性快照。每一步都嵌入同一章专属 Diagram，方便在暂停状态下核对对象、责任和失败语义。

多节点、过期与恢复：把隐性代价写出来

单节点内存适合短生命周期、低恢复要求的临时向导，但它会把会话定位绑定到节点。加负载均衡后，常见路线有三种：使用故障转移副本，改用集中式会话存储，或明确接受节点故障导致重新开始。选择哪一条，取决于会话资料是否可重建、用户能否接受丢失，以及复制成本是否低于恢复收益。

过期不是一次定时删除就结束。读取路径必须拒绝过期记录，后台清理器负责回收容量，续期规则要防止活跃用户在中途被误删；写入路径还要防止旧请求在续期之后把新版本覆盖。记录 sessionId、版本、节点、过期时间和失败原因，才能把“用户突然回到第一步”定位成超时、路由、复制还是授权问题。

如果状态包含付款意图、优惠资格或库存承诺，就不能只因为框架提供了 Session 就把它当成最终业务事实。会话可以保存向导草稿；提交订单时仍应重新读取关键业务数据，在事务边界内完成校验和写入。会话状态解决的是跨请求上下文，不自动解决业务一致性。

代码实践：把客户端输入限制在步骤增量

下面的处理器只接受当前步骤的增量字段，并让存储层负责版本冲突。它可以作为练习的起点：先让它返回 session-expired，再分别模拟节点不可达和版本冲突，观察调用方是否得到不同的恢复提示。

type StepInput = { address?: string; paymentToken?: string };
type SessionResult =
  | { ok: true; session: OrderSession }
  | { ok: false; reason: "expired" | "conflict" | "unavailable" };
 
async function updateWizard(
  store: SessionStore,
  sessionId: string,
  input: StepInput,
): Promise<SessionResult> {
  try {
    const current = await store.load(sessionId);
    if (!current || current.expiresAt <= Date.now()) return { ok: false, reason: "expired" };
    const next = { ...current, version: current.version + 1 };
    await store.save(next, current.version);
    return { ok: true, session: next };
  } catch (error) {
    if (error instanceof Error && error.message === "version-conflict") return { ok: false, reason: "conflict" };
    return { ok: false, reason: "unavailable" };
  }
}

这里 input 只代表步骤增量；生产实现需要把地址和支付令牌校验后合并到服务器记录，并明确支付令牌的保管方式。若 store.load 和 store.save 跨越不同节点，存储实现还必须提供原子条件写或等价的并发控制。

选择与拒绝矩阵

常见误区

本章小结

• 会话标识只负责定位，服务器记录才是业务草稿的权威来源。
• 序列化、版本和条件写共同保护跨请求更新。
• 多节点设计必须说明共享、复制或明确丢失语义。
• TTL 同时需要读取拒绝、后台清理、续期和容量观测。
• 提交订单时要重新校验关键业务事实，不能盲信会话草稿。

练习与答案

名词解释

来源与改写范围

• Martin Fowler 作者图书页：核对全书主题与模式参考结构。
• Martin Fowler 模式目录：核对模式名称、模式族与作者公开摘要。
• Pearson 出版社页面：交叉核对英文版出版信息与目录范围。

前后导航

• 上一页：17.1 客户会话状态
• 下一页：17.3 数据库会话状态