REST 提倡在服务器上没有客户端状态的 Web 应用程序。著名的购物车示例被转换为通常驻留在数据库中的资源。
我想知道将数据库用于此类数据是否是一种好习惯，因为数据库已经是许多应用程序的瓶颈。改用有状态的企业 Java bean 不是更好吗？应用程序服务器在设计时考虑了集群。
这两种方法的优缺点是什么？
问问题
2922 次
4 回答
3
只有在以下情况下才能在应用程序服务器上存储会话：
- 您的客户端始终连接到同一个应用程序服务器（又名“会话亲和性”）
- 您的应用程序集群节点都使用公共安装点（nfs 等）来假脱机会话
如果不能保证您的客户端始终连接到集群中的同一应用程序节点，则将会话存储在中央数据库和/或 EJB 中将起作用。
要考虑的另一种方法是使用诸如memcached之类的服务。这在任何一种情况下都有效。
于 2010-01-26T21:47:16.997 回答
2
一般来说：
数据库
- 更可靠，并且可以在应用程序/服务器重新启动后继续存在
- 可以在负载平衡的服务器之间共享，而无需处理“粘性”会话
- 访问速度较慢
内存中（非分布式有状态 bean）
- 快速存储和检索
- 更少的代码
- 如果应用程序/服务器重新启动将丢失
您的选择将完全取决于您的应用要求和环境。在所有条件相同的情况下，我更喜欢数据库解决方案，因为它具有负载平衡和可靠性优势，但在许多情况下这很容易被矫枉过正。
于 2010-01-26T21:47:17.377 回答
1
当您的应用服务器死机时会发生什么。会话状态仍然重要吗？去一个数据库。
您是否有更多会话状态，然后您的服务器可以处理所有并发用户？将数据移入数据库并仅提取当前真正需要的数据可能是一种解决方案。
你的应用是集群的吗？如果是这样，中央数据库确保会话数据始终可用。
否则：只需将其存储在会话中。
您是否有极端的扩展要求（例如 stackoverflow 或流量更大的网站）？想办法不使用数据库。
确实，数据库通常是瓶颈。但是正确设置的数据库应该可以很好地处理几个字节的会话数据。更复杂的数据和查询会降低性能。
于 2010-01-26T21:47:57.853 回答
0
所有其他项目都是很好的建议。还有一个是：如果您不是绝对需要它，请不要使用会话状态。
出于几个简单的原因，将会话存储在数据库中（通常）是一个坏主意：
会话的典型用途是避免多次从数据库服务器加载公共数据。如果 session 存储在 db 服务器中，那么，你真的没有完成太多。
会话必须为每个页面执行进行序列化和反序列化。这意味着必须从服务器检索会话数据，并在每次页面加载时将其写回服务器，无论您是否使用它。
根据我的经验，当您真正需要数据时，您最好从数据库服务器中提取数据。在大多数情况下，人们只是因为他们认为他们正在解决性能问题而将各种短期数据放在会话中，而实际上他们正在使情况变得更糟。
此外，如果您限制数据量（比如用户 id、名称或类似的东西），那么您可以将其存储在加密的 cookie 客户端中，而完全不必担心。
MemCache 是一种选择；但我会再次认真查看您的数据库使用情况，看看您是否可以先对查询和模式进行性能调整。
于 2010-01-26T22:18:26.853 回答