一、无状态与有状态

1.1 无状态

无状态性体现为服务器在完成单次请求处理后，不保存任何与该事务相关的上下文信息。每个 HTTP 请求均被视为独立的原子操作，服务器响应过程完全依赖当前请求携带的信息，而不依赖先前请求产生的历史数据。

以淘宝网首页为例，用户首次请求时，服务器依推荐算法生成商品推荐与活动界面；页面刷新时，服务器将新请求视为全新事务，重新检索数据并渲染页面，不参考历史访问记录。这种设计契合无状态协议原则，有效提升前端服务器集群并发处理能力，减少服务器资源消耗，适用于高并发场景。

无状态设计简化服务器逻辑，降低复杂度。在淘宝每日亿级用户访问首页的场景下，若记录用户历史与会话状态，将消耗大量内存与计算资源。无状态设计使服务器独立处理每个请求，故障时其他服务器可快速接管，不影响服务，也便于系统扩展维护，新服务器无需同步历史数据即可参与请求处理。

1.2 有状态

与无状态协议不同，有状态通信机制需服务器维护客户端会话状态，包括身份认证、操作记录、交易进度等核心数据。

以支付宝转账为例，系统将交易状态（处理中 / 已完成 / 异常）持久化存储。用户后续操作时，服务器依记录状态生成响应，保障交易连贯与数据一致。这种设计虽确保复杂业务逻辑完整，但对服务器状态管理与数据持久化能力要求极高。

转账过程中，从余额检查、资金冻结到入账的每个步骤对应不同状态。若不记录，不仅无法处理后续操作，还威胁资金安全。如转账异常中断，服务器凭借 "异常中断" 状态，可执行解冻资金或引导重操作等处理。但维护状态需消耗额外资源，且要兼顾数据一致性、持久性和高可用，显著提升系统设计与运维复杂度。

二、水平拓展与垂直拓展

2.1 水平拓展

水平拓展是指通过增加服务器节点数量，实现系统处理能力的线性扩展，该策略在 HTTP 无状态架构中具有显著的技术优势。

淘宝网 "双 11" 的技术实践极具代表性。面对瞬时暴增的访问与订单请求，技术团队通过动态扩容服务器集群，新节点无需与原有节点进行状态同步即可立即处理请求。基于无状态设计的水平拓展策略，有效分散流量负载，保障了高并发场景下系统的可用性与响应速度。

若采用有状态架构，新服务器需同步大量用户会话数据，耗时且易因数据不一致引发服务异常。而基于 HTTP 无状态特性，新服务器加入集群后仅需完成服务配置，即可直接承接流量。如原有 100 台服务器，新增 50 台后可立即分摊请求，避免单台过载，显著提升系统吞吐量与稳定性。

2.2 垂直拓展

垂直拓展是指通过升级单台服务器的硬件配置（如 CPU 性能提升、内存容量扩展、存储 I/O 优化等）实现处理能力增强。

阿里早期采用垂直拓展优化数据处理系统，通过升级 CPU、扩展内存、更换存储设备，显著提升了处理效率。但随着业务规模扩大，这种方式暴露出明显局限：一方面，高性能硬件成本高昂；另一方面，性能提升存在边际效应，例如 CPU 从四核升级到八核可提升 50% 性能，而从八核升级到十六核仅提升 20%，成本却大幅增加。因此，随着用户和数据量激增，垂直拓展逐渐被水平拓展架构取代。

三、向后移动状态、向前移动状态

3.1 向后移动状态

向后移动状态是指将服务器端维护的状态信息迁移至后端存储系统（如 Redis、MySQL 数据库），以解决分布式架构中的状态管理问题。

以淘宝网用户登录系统为例，初期将登录状态存储于应用服务器内存，导致水平拓展时出现会话不一致问题。用户首次请求由服务器 A 处理并记录登录状态，后续若被分配到服务器 B，因 B 无对应状态信息，用户需重新登录。引入 Redis 集群后，利用其分布式与高并发特性，实现跨服务器状态共享。各服务器均可从 Redis 读写用户登录状态，无论请求分配至哪台服务器，都能获取最新信息，确保用户切换服务器时登录状态一致，有效解决了分布式系统的状态管理难题。

3.2 向前移动状态

向前移动状态指将状态信息迁移至客户端，常用 Cookie、LocalStorage 等技术实现。

淘宝网借助 Cookie 存储商品浏览历史，当用户回访时，服务器解析 Cookie 精准呈现浏览记录。为应对安全隐患，技术团队通过数据加密、设置合理过期策略，既优化用户体验，又保障数据安全。

客户端存储状态信息可减轻服务器压力。如淘宝将用户浏览记录存于 Cookie，浏览器后续访问时自动回传，服务器据此推荐商品。但该方式存在数据窃取、篡改风险，因此淘宝对 Cookie 加密处理，并设置失效时间，在提升体验的同时筑牢安全防线。