Web applications 在什么情况下，有状态比无状态更好？

我一直提倡无状态web，但我想知道有状态web的倡导者在说什么

---

您是否遇到过有状态比无状态更合适的情况？

使用状态通常会使程序员的工作更轻松

然而，状态还引入了各种在无状态情况下根本不存在的并发问题

---

这本质上是函数式编程和命令式编程之间的争论。

像长表单（以及任何需要一次以上页面刷新的内容）这样的东西，在持久状态下更容易实现，因为您实际上可以简单直接地跟踪用户所处的页面/阶段。然而，我个人认为这样一个小小的优势并不值得，但它在很大程度上取决于所讨论的web应用程序。

我们的项目使用Wicket web框架，它允许有状态或无状态交互。有状态页面有许多优点：

• 在wicket中使用有状态页面可以更容易地使用wicket的AJAX框架执行部分页面更新
• Stateful是一种更“直观”的编程模型。例如，在wicket页面类中，我可以在服务器端声明一个私有成员字段，在加载页面时设置它，并在每次AJAX请求到达页面时再次访问它以执行某些更新
• Wicket通过在处理请求时在用户会话对象上同步来防止web层中最常见的并发问题
• 在服务器端存储状态有时可以提高性能；例如，构建一个耗时但必须对页面可用的对象，在页面第一次实例化时只能加载一次

在一个有状态的应用程序中，任何可能的事情都可以实现为无状态的——您只需将状态存储在客户机上，并在每个请求上提交所有相关的状态信息

---

wicket的链接：

由于可扩展性，我处于状态完整的客户端无状态服务器阵营中，但当面临解释为什么使用无状态服务器实现这一点和那一点变得更加困难的障碍时，从长远来看，您会有点听天由命，这就是状态服务器的亮点：）。 尽管我更喜欢statefull客户端，但使用asp.net viewstate很难有效地实现这一点，也许这就是statefull web变得实用的地方。 我认为，有状态客户端、无状态服务器可以让您更好地了解轮胎之间来回传输的数据量。在使用状态完整的服务器编程模型出现问题之前，这一点有时是隐藏的。此外，从无状态到状态完整也很容易（只需忽略您提供的状态信息，因为您已经知道它了……）。走相反的路几乎是不可能的/不值得的。使用statefull服务器的另一件事是，当您同时使用statefull客户端时，清除状态/缓存通常是一个问题。这只是不直观和混乱，或者可能只是我：）

无论如何，由于可伸缩性问题，GWT和许多其他现代工具包（Silverlight与WCF对话）似乎更喜欢有状态的客户端、无状态的服务器。也许有状态服务器应该是无状态规则的例外。。。每个页面/窗口都可以选择

资料来源：

---

当您开始拥有更高的流量时，无状态web应用程序是必不可少的

例如，出于安全原因，可能有大量用户数据不希望存储在客户端。在这种情况下，您需要将其存储在服务器端。您可以使用web应用程序默认会话，但如果您有多个应用程序实例，则需要确保每个用户始终指向同一实例

负载平衡器通常具有“粘性会话”的能力，负载平衡器知道向哪个服务器发送用户请求。但这并不理想，例如，这意味着每次重新启动web应用程序时，所有连接的用户都将丢失会话

---

一种更好的方法是将会话存储在web服务器后面的某种数据存储中，现在有大量的nosql产品可用于此（redis、mongo、elasticsearch、memcached）。这样，web服务器是无状态的，但您仍然有状态服务器端，可以通过选择正确的数据存储设置来管理此状态的可用性。这些数据存储通常有很大的冗余，因此几乎总是可以在不影响用户的情况下对web应用程序甚至数据存储进行更改。

我真的不明白web应用程序中会出现什么“并发问题”…假设您的站点上同时有两个用户。如果它们同时提交，它们是否都会访问您的数据库或其他服务，然后出现竞争条件？但这是数据库问题；这与您是否在web应用程序中存储状态无关。ACID兼容数据库（即所有关系数据库）是用来处理这类问题的。我认为samoz的目标是我们目前在代码商店的票证系统中遇到的问题。由于票证系统是有状态的，它知道登录用户当前打开的票证。因此，如果您试图在第二个选项卡中打开另一张票证，系统会感到困惑，因为您一次只能打开一张票证（正如您可能想象的那样，这很糟糕）。一个无状态的应用程序甚至不会有“当前打开的票证”的概念，因此也不会遇到这个问题。我想我没有完全回答OPs的问题，事实恰恰相反！但我觉得我的回答与讨论相符。。。