在传统 Web 应用开发中，数据库通常是绕不开的基础设施。然而，随着无状态架构理念的普及，一个值得重新审视的问题是：当业务真正实现无状态化之后，是否还有必要保留传统数据库？答案并非简单的 “需要” 或 “不需要”，而是需要根据数据特性、访问模式、一致性要求等因素，在多种存储层替代方案之间做出精细的工程权衡。
无状态架构的本质：状态外置
理解无状态架构的关键在于明确 “状态” 的定义。无状态服务并不意味着应用没有任何数据，而是指每个请求都包含足够的上下文信息，服务实例本身不保存任何与请求相关的内存状态。这意味着会话数据、用户配置、工作流状态、历史记录等信息必须迁移到共享的外部存储系统中。从表面上看，无状态架构似乎 “去掉” 了数据库，但实际上是将状态转移到了更专业的存储层。
这种设计的核心收益在于计算层的可处置性。由于服务实例不含状态，负载均衡器可以随时将流量切换到任意副本，部署新版本时无需等待旧实例下线，系统 Failover 变得极为简单。对于需要快速弹性伸缩的业务而言，这是极具吸引力的架构演进方向。然而，收益的代价是系统复杂度的提升：原本在单机内部完成的内存操作，现在需要通过网络调用外部存储，延迟增加、依赖增多、一致性保障也更具挑战。
存储层替代方案及其适用场景
无状态架构下的存储层选择并非单一答案，而是需要根据数据类型和业务需求进行分层设计。以下是几种主流替代方案及其典型适用场景。
分布式缓存（如 Redis） 是最常见的无状态化搭档。Redis 以毫秒级甚至微秒级的访问延迟著称，非常适合承载会话数据、实时计数器、短期配置、限流状态等高频访问但对持久性要求相对宽松的场景。其内置的过期机制和丰富的数据结构（如 Hash、Set、Sorted Set）能够高效满足业务层的各类需求。但使用 Redis 作为主要状态存储需要正视几个工程挑战：缓存穿透可能导致数据库压力骤增，缓存失效时的雪崩效应需要通过多级缓存和随机过期时间等技术手段缓解，数据丢失后的回源逻辑必须妥善设计以避免惊群效应。
对象存储（如 S3、MinIO） 适用于文件、图片、日志、备份等二进制大对象的持久化存储。这类存储的成本通常远低于块存储或文件系统，且具备天然的跨可用区冗余和极高可用性。对象存储的访问延迟相对较高（通常在数十毫秒量级），不适合作为低延迟查询的事务存储，但对于无状态服务而言，将静态资源上传至对象存储并通过 CDN 分发，是实现计算与存储分离的经典模式。实践中需要注意的是，对象存储的元数据操作（如列举文件）可能成为性能瓶颈，大规模场景下应结合数据库或缓存管理元数据索引。
事件日志与消息队列（如 Kafka、Pulsar） 代表了一种截然不同的存储哲学。与传统数据库强调当前状态不同，事件日志记录的是不可变的变更历史。这种设计在审计、回溯、重放等场景下具有天然优势，也是实现事件溯源（Event Sourcing）架构的基础。无状态服务可以将关键业务事件写入日志，由下游消费者异步处理，从而实现读写分离和削峰填谷。代价是引入了最终一致性，业务层需要处理事件延迟到达和乱序问题，对于强一致性要求的场景（如金融交易）需要额外设计补偿机制。
传统关系型或 NoSQL 数据库 仍然在无状态架构中扮演关键角色，只是角色定位发生了变化。在无状态化之后，数据库不再服务于每次请求的即时读写，而是作为权威数据源和持久化后端。此时的核心工程问题变成如何最小化每次请求对数据库的依赖。常见的优化策略包括：读写分离、查询结果缓存化、批处理写入、仅在必要时查询数据库（如涉及复杂关联或事务保证的场景）。数据库从 “每次请求必访” 变为 “按需访问”，其负载压力反而可能下降。
工程权衡的量化维度
在实际选型时，团队需要从多个量化维度进行评估，而非仅凭直觉或社区热度。以下是建议纳入考量的关键参数。
延迟敏感度是首要考量。对于延迟要求在毫秒以内的核心链路（如登录验证、实时推荐），应优先考虑 Redis 缓存层甚至本地缓存，仅将持久化写入异步化处理。对于延迟容忍度较高的后台任务或分析场景，事件日志和对象存储是更经济的选择。
一致性要求决定了技术方案的复杂度。强一致性场景（如库存扣减、账户转账）通常离不开数据库的事务支持，或需要引入分布式事务中间件。最终一致性场景（如日志记录、异步通知）则可以充分利用消息队列和事件日志的解耦能力。
成本结构在规模化后尤为关键。对象存储的存储成本通常仅为数据库的十分之一到百分之一，但检索成本较高；Redis 按内存容量计费，大规模状态存储成本可能超过传统数据库；数据库的读写 capacity unit（RCU/WCU）或连接数限制可能成为隐形成本瓶颈。团队应基于预估的数据量和访问模式建立成本模型，而非仅比较单价。
运维复杂度是容易被忽视但影响深远的因素。引入新的存储层意味着增加运维对象、监控指标、故障域和人员技能要求。Redis 集群的哨兵或 Redis Cluster 拓扑管理、对象存储的跨区域复制配置、事件日志的消费滞后监控，每一项都需要专人负责。在团队规模有限的情况下，存储层的数量应严格控制。
实践建议与参数清单
基于上述分析，以下是面向无状态架构存储层选型的实践建议。
首先，采用分层存储策略而非单一方案。典型配置为：无状态 API 服务器加 Redis 处理会话与热点缓存，对象存储承载静态资源，数据库保存核心业务实体，事件日志记录关键变更用于审计和异步处理。这种分层设计能够充分发挥各类存储的优势，同时通过适当的写入策略（如写穿透或写回）控制复杂度。
其次，设定明确的一致性契约。每个数据类别都应明确其一致性要求：是强一致、最终一致还是仅需最终一致。这一决策将直接影响技术选型和代码实现复杂度。避免在系统演进过程中频繁切换一致性模型，因为这往往意味着大规模重构。
第三，建立存储层的监控告警体系。关键指标包括：缓存命中率（目标通常在 95% 以上）、数据库连接池使用率、对象存储请求延迟分布、消息队列消费滞后量（Lag）。建议为每类存储设定基线告警阈值，例如 Redis 内存使用率超过 80% 时触发扩容评估，数据库 CPU 使用率持续超过 70% 时触发读写分离改造。
第四，设计无状态服务的降级策略。当 Redis 不可用时，是否允许降级到数据库直接读取？当消息队列积压时，是否停止写入或切换到本地缓冲？这些降级逻辑需要在架构设计阶段明确，并配合灰度发布和熔断机制实现。
无状态架构并不意味着 “消灭数据库”，而是将状态管理从应用服务器转移到更专业的存储层。正确的做法是根据数据的生命周期、访问模式、一致性要求和成本约束，选择最适合的存储技术，并在系统层面建立清晰的分层边界和监控体系。
资料来源：本文技术细节参考 Aerospike 关于有状态与无状态架构的对比分析，以及 CloudZero 和 System Design School 的系统设计权衡讨论。