session - stateless 是否仅将客户端的状态转移到其他地方？

Question

我花了一整天的时间了解什么是无状态架构。我读了很多帖子和答案，比如

Can My Web App Implement User Login and Remain Stateless?

Pros and Cons of Sticky Session / Session Affinity load blancing strategy?

http://www.quora.com/What-is-stateless-and-statefull-web-architecture

• stateless好像只是把一些用户状态转移到 其他地方(数据库/内存缓存或客户端 cookie)。这是对的吗？如果是，则状态仅存储在其他地方，因此必须有一些东西不是无状态的(客户端或服务器)，尽管负载均衡器现在不需要担心路由到哪台机器。

• 如果上面是正确的，如果我们选择将用户信息转移到中心位置(根据一些答案，转移到客户端似乎并不总是解决方案)比如数据库或内存缓存，我们仍然需要找到这个 session 信息每一个请求。这意味着持有用户状态的地方将有同样的压力同时处理数千万个请求。并且可能，我们找到 session 信息的方式就像粘性 session (将信息请求路由到内存缓存中的单个节点)。那么为什么我们认为转移状态更具可扩展性呢？压力只是转移(而且一直以来，数据库已经负载太大)

我是否遗漏了什么或理解错误？

谢谢!

Answer 1

您是正确的，将您的状态移动到不同的层意味着您的应用程序是有状态的(真正无状态的应用程序很少，大多数只有纯数学应用程序)。

这并不意味着单个层不能是无状态的，那些层的缩放方式与有状态层不同。这个想法是，通过使应用程序的特定部分无状态，您将能够对其进行扩展 horizontally ，而不是垂直，因此能够通过简单地购买更多硬件来响应更多请求。

无论将该状态推向何处，您仍然需要进行扩展。因此，如果您要将其推送到数据库，则需要能够相应地扩展该数据库。如果您可以将其推送到可以廉价扩展的层(如 memcached)，则此方法效果很好。

使您的业务层和 Web 层无状态化通常是目标，因为它们的扩展成本通常比数据存储层高得多，但这并非总是如此。如果您在数据存储层上放置了很多负载，而在您的应用程序或 Web 层上放置了很少的负载(例如数据驱动应用程序与交互驱动应用程序)，那么您的数据层就会过载。

因此，与其他所有事情一样，是否让您的应用程序无状态归结为“视情况而定”。通常，有状态的业务层和 Web 层往往会在数据层重载之前很久就重载。特别是如果你正在做重要的 OOP。