我一直提倡无状态网络，但想知道有状态网络的倡导者在说什么。
您是否有任何情况下有状态比无状态更合适？
问问题
13864 次
5 回答
8
我们的项目使用 Wicket Web 框架，它允许有状态或无状态的交互。有状态页面有很多优点：
- 在 wicket 中使用有状态页面可以更轻松地使用 wicket 的 AJAX 框架执行部分页面更新
- 有状态是一种更“直观”的编程模型。例如，在一个 wicket 页面类中，我可以在服务器端声明一个私有成员字段，在页面加载时设置它，并在每次 AJAX 请求到达页面时再次访问它以执行一些更新。
- Wicket 通过在处理请求时同步用户会话对象来防止 Web 层中最常见的并发问题。
- 在服务器端存储状态有时可以提高性能；例如，构建耗时但必须可用于页面的对象只能在页面第一次实例化时加载一次。
有状态应用程序中可能发生的任何事情也可以实现为无状态——您只需将状态存储在客户端上，并在每个请求上提交所有相关的状态信息。
链接到检票口：http ://wicket.apache.org/
于 2009-09-23T02:11:01.190 回答
4
使用状态通常会使程序员的工作更轻松。
但是，状态也引入了在无状态情况下根本不存在的各种并发问题。
这本质上是函数式编程和命令式编程之间的争论。
于 2009-07-24T12:49:55.683 回答
2
由于可扩展性，我属于有状态的客户端-无状态服务器阵营，但是当面临解释为什么使用无状态服务器变得更难实现这一点和那个的障碍时，从长远来看，你会有点辞职，这就是有状态服务器大放异彩的地方:)。尽管我更喜欢有状态的客户端，但这并不容易使用 asp.net viewstate 有效地实现，也许这就是有状态的 web 变得实用的地方。我认为有状态的客户端、无状态的服务器让你更清楚轮胎之间来回传输的数据量。这有时是隐藏的，直到使用有状态的服务器编程模型出现问题。此外，从无状态到有状态很容易（只需忽略您提供的状态信息，因为您已经知道它......）。反其道而行之几乎是不可能的/不值得的。使用有状态服务器的另一件事是，当您同时使用有状态客户端时，清除状态/缓存通常是一个问题。这只是不直观和令人困惑，或者可能只是我:)
无论如何，由于可扩展性问题，GWT 和许多其他现代工具包（Silverlight 与 WCF 对话）似乎更喜欢有状态客户端、无状态服务器。也许有状态服务器应该是无状态规则的例外......可以选择每个页面/窗口。
于 2009-10-06T16:51:51.767 回答
2
当您开始拥有更高的流量时，无状态 Web 应用程序是必不可少的。
例如，出于安全原因，您可能不想将大量用户数据存储在客户端。在这种情况下，您需要将其存储在服务器端。您可以使用 Web 应用程序默认会话，但如果您有多个应用程序实例，则需要确保每个用户始终指向同一个实例。
负载均衡器通常具有“粘性会话”的能力，负载均衡器在某种程度上知道将用户请求发送到哪个服务器。虽然这并不理想，例如，这意味着每次重新启动 Web 应用程序时，所有连接的用户都将失去他们的会话。
更好的方法是将会话存储在 Web 服务器后面的某种数据存储中，现在有很多很棒的 nosql 产品可用于此（redis、mongo、elasticsearch、memcached）。这样，Web 服务器是无状态的，但您仍然拥有状态服务器端，并且可以通过选择正确的数据存储设置来管理此状态的可用性。这些数据存储通常具有很大的冗余性，因此几乎总是可以对您的 Web 应用程序甚至数据存储进行更改而不会影响用户。
于 2013-08-22T12:24:13.810 回答
1
像长表单（实际上任何需要多次刷新页面的东西）这样的东西在持久状态下要容易得多，因为您实际上可以以一种简单直接的方式跟踪用户所在的页面/阶段。但是，我个人认为这么小的优势并不值得，但这在很大程度上取决于所讨论的 Web 应用程序。
于 2009-09-23T01:56:02.363 回答