session - 无状态仅将客户的状态转移到其他地方吗？

Question

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

似乎无状态只是将一些用户状态转移到其他地方（数据库/内存缓存或客户端 cookie）。这是对的吗？如果是，则状态仅存储在其他地方，因此必须有一些不是无状态的（客户端或服务器），尽管负载均衡器现在不需要担心路由哪台机器。
如果上面是正确的，如果我们选择将用户信息传输到中心位置（根据某些答案，传输到客户端似乎并不总是解决方案），例如数据库或内存缓存，我们仍然需要为每个请求找到此会话信息。这意味着持有用户状态的地方将面临同时处理数千万请求的相同压力。并且可能，我们找到会话信息的方式就像粘性会话（将信息请求路由到内存缓存中的单个节点）。那么为什么我们认为转移状态更具可扩展性呢？压力只是转移（而且总是，数据库已经有太多的负载）

我错过了什么或理解错误吗？

谢谢！

score 2 · Accepted Answer

您是正确的，将您的状态移动到不同的层意味着您的应用程序是有状态的（很少有真正的无状态应用程序，主要是只做纯数学的应用程序）。

这并不意味着各个层不能是无状态的，并且这些层的缩放比例与有状态的层不同。这个想法是，通过使应用程序的特定部分无状态，您将能够水平扩展它，而不是垂直扩展，从而能够通过简单地购买更多硬件来响应更多请求。

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

使您的业务和 Web 层无状态通常是目标，因为它们的扩展成本通常比数据存储层高得多，但这并不总是正确的。如果您在数据存储层上加载了大量负载，而在应用程序或 Web 层上加载的负载很少（例如数据驱动与交互驱动的应用程序，那么您的数据层将会过载。

因此，与其他所有事情一样，是否让您的应用程序无状态归结为“取决于”。通常，有状态的业务和 Web 层往往在数据层之前就已经超载了。特别是如果您正在执行重要的 OOP。

1 回答 1