1、状态数据概述：什么是状态数据、有状态服务 vs 无状态服务、状态数据的生命周期

各位同学，咱们今天正式开讲《状态数据结构演进与兼容性》这门课。第一节课，我想先聊聊最基础的问题——到底什么是状态数据？

我见过不少做了三五年开发的朋友，一提到「状态」就含糊其辞。说白了，状态数据就是那些「需要被记住的信息」。你的购物车、用户的登录会话、银行账户的余额……这些都是状态。它们不会随着一次请求结束就消失，而是会跨越多个操作、多个会话，甚至跨越整个系统生命周期。

1.1 什么是状态数据

状态数据，本质上就是系统在运行过程中产生的、需要持久化或跨请求共享的信息。它可以是内存里的一个变量，也可以是数据库里的一行记录，还可以是 Redis 里的一个缓存键。

我习惯把状态数据分成三类：

• 会话状态：用户登录后的 session、购物车内容、浏览历史。这类数据通常有明确的过期时间。
• 业务状态：订单状态、支付流水、库存数量。这类数据是业务逻辑的核心，必须保证一致性和持久性。
• 系统状态：服务实例的注册信息、配置中心的版本号、分布式锁的持有者。这类数据支撑着整个系统的正常运行。

举个例子。我在做一个电商平台时，遇到过用户下单后支付成功，但订单状态还是「待支付」的情况。查了半天，发现是订单服务重启后，内存里的状态丢了，而数据库里的状态还没来得及更新。嗯，这就是典型的「状态数据生命周期管理」出了问题。

1.2 有状态服务 vs 无状态服务

这两个概念，我估计大家都听过。但真正理解它们区别的人，其实不多。

无状态服务，说白了就是「不记事儿」。每次请求都是独立的，服务端不保存任何客户端上下文。HTTP 协议本身是无状态的，RESTful API 也是无状态的。你发一个请求，我处理完就忘，下次再来我当你是陌生人。

有状态服务，就是「记事儿」。服务端会保存客户端的状态信息，比如 WebSocket 连接、游戏服务器里的玩家位置、流式计算中的窗口数据。你发一个请求，我不仅处理，还记住你刚才干了什么。

我整理了一个对比表格，方便大家理解：

维度	无状态服务	有状态服务
扩展性	水平扩展简单，加机器就行	需要处理状态迁移，扩展复杂
容错性	实例挂了直接替换，无影响	实例挂了可能丢数据，需要恢复
性能	每次请求都要携带上下文，开销大	状态本地缓存，处理速度快
典型场景	API 网关、静态文件服务	会话管理、实时游戏、流计算
调试难度	低，请求可重放	高，依赖上下文

你想想看，为什么微服务架构推崇无状态？因为无状态服务好扩展、好运维。但现实是，很多业务场景根本绕不开状态。比如用户登录后的 session，你总不能每次请求都让用户重新输入密码吧？

我曾经在一个金融项目中踩过坑。团队把所有交易状态都放在内存里，觉得 Redis 太慢。结果一次机房断电，所有未结算的交易状态全丢了。嗯，从那以后，我再也不敢把关键状态放在内存里了。

1.3 状态数据的生命周期

状态数据不是永生的。它有自己的生命周期，从创建到销毁，每个阶段都需要精心管理。

我一般把状态数据的生命周期分为四个阶段：

1. 创建：状态数据第一次产生。比如用户登录时创建 session，订单提交时创建订单记录。
2. 使用：状态数据被读取或更新。比如每次请求都检查 session 是否过期，每次支付都更新订单状态。
3. 迁移：状态数据从一个节点转移到另一个节点。比如服务扩容时，需要把部分用户的 session 迁移到新节点。
4. 销毁：状态数据不再需要，被清理。比如用户退出登录时删除 session，订单完成后归档。

这里有一个很多人容易忽略的点：状态数据的销毁时机。销毁太早，用户还在用就丢了；销毁太晚，内存被占满，系统崩溃。

下面这张图，是我自己总结的状态数据生命周期管理框架，大家可以参考：

在实际项目中，状态数据的生命周期管理往往比这张图复杂得多。比如在分布式系统中，状态迁移可能涉及数据分片、一致性协议、故障恢复等一系列问题。这些内容，我们会在后面的章节中逐一展开。

1.4 状态数据与系统架构的关系

状态数据的位置，直接决定了系统架构的形态。我总结了几种常见的模式：

• 本地状态：状态存在单机内存里。性能最好，但扩展性和容错性最差。适合单机应用或开发环境。
• 集中式状态：状态存在一个中心化的存储里（如 Redis、MySQL）。扩展性好，但中心节点可能成为瓶颈。
• 分布式状态：状态分散在多个节点上，通过一致性协议保证数据正确。扩展性和容错性都好，但实现复杂。

你想想看，为什么很多公司从单体架构迁移到微服务架构时，第一个遇到的问题就是「状态怎么拆」？因为状态数据一旦分散到多个服务里，数据一致性、事务边界、查询复杂度都会成倍增加。