设计一个应该易于扩展的系统时，您首先要尝试扩展系统的不同组件。
在客户端层，你有你的客户端设备，可以是台式机或移动设备
在应用层，您将拥有CDN、负载均衡器、应用服务器或 Web 服务器以及其他用户管理实用程序。
在数据库层，您将拥有源数据库和复制数据库。
当涉及到用户会话时，您打算将这些会话存储在哪里？
您不能将它们存储在应用程序层中，因为应用程序服务器将具有缓存的内存存储来更新用户会话。
这引入了持久存储用户会话的需求。存储用户会话的最佳位置是在数据库层内。如何存储它取决于您尝试选择的架构类型。
有两种类型的体系结构用于存储用户会话状态。
有状态的架构：
要求用户登录其帐户的身份验证会话需要维护会话状态。其他多动作过程也需要维护会话。在有状态架构中，服务器存储从一个请求到下一个请求的客户端状态。
当用户转到他们以前从未登录过的其他设备（例如手机或台式机）时，最初他们最初需要一个身份验证过程，例如2FA，然后才能将该设备的用户会话状态存储到服务器上。所以会话状态实际上是存储在服务器上的。
下图显示了有状态架构的设计方式。
有状态架构在单个服务器上存储和维护用户会话。来自该用户的 HTTP 请求无法路由到另一台服务器，因为响应将失败。
因此，来自用户的所有请求都必须路由到其指定的服务器以访问该用户的状态。这使得架构很难扩展，因为添加或删除服务器会导致从用户收到的请求中出现许多故障点问题。
为了确保这种架构的可行性，我们可以在负载均衡器中使用粘性会话。但是，这会增加很多开销。
无状态架构
一个无状态服务作为一个整体通常仍然需要以某种形式处理状态。无状态只是指在服务器端会话中不跟踪此状态的事实。
在无状态架构中，来自用户的 HTTP 请求可以发送到任何 Web 服务器，因为用户会话不是存储在应用层，而是存储在数据库层的共享存储空间中。
过去，客户端设备在处理维护会话的额外复杂性方面的硬件和软件能力非常有限。因此，大部分繁重的工作都是在服务器端完成的。
然而，由于技术进步以及基础设施和计算能力的多样化增长，不充当服务器的个人和专业计算设备已经足够强大以处理会话状态。
这种架构的美妙之处在于，当我们将存储用户会话数据的想法从应用层转移到持久数据存储层时，它可以让系统更加简单和可扩展。
根据网络流量在应用程序层自动缩放 Web 服务器的额外灵活性使您不必担心开销。