维护应用程序服务器或数据库中的状态？

Question

REST提倡在服务器上没有客户端状态的Web应用程序。着名的购物车示例被转换为通常驻留在数据库中的资源。

我想知道将数据库用于那种数据是否是一种好习惯，因为数据库已经成为许多应用程序的瓶颈。使用有状态企业java bean不是更好吗？应用程序服务器的设计考虑到了clustring。

这两种方法有哪些优点和缺点？

Answer 1

在应用程序服务器上存储会话仅在以下情况下有效：

• 您的客户端始终连接到同一个应用程序服务器（又名“会话关联”）
• 您的应用程序集群节点都使用公共挂载点（nfs等）来假脱机会话

如果不保证客户端始终连接到群集中的同一应用程序节点，则将会话存储在中央数据库和/或EJB中。

另一种需要考虑的方法是使用memcached等服务。这将适用于任何一种情况。

Answer 2

一般来说：

数据库

• 更可靠，将在应用程序/服务器重启后继续存在
• 可以在负载均衡的服务器之间共享，而无需处理“粘性”会话
• 访问速度较慢

内存中（非分布式有状态bean）

• 快速存储和检索
• 少代码
• 如果应用/服务器重新启动，将会丢失

您的选择将完全取决于您的应用要求和环境。在所有条件相同的情况下，由于负载平衡和可靠性优势，我更青睐数据库解决方案，但在许多情况下这很容易过度。

Answer 3

当您的应用服务器死亡时会发生什么会话状态仍然重要吗？去一个数据库。

您是否有更多会话状态，那么您的服务器可以处理所有并发用户？将数据移动到数据库中并仅仅提取您目前真正需要的数据，可能是一种解决方案。

您的应用是否已群集？如果是这样，中央数据库会确保sessiondata始终可用。

否则：只需将其存储在会话中。

您是否有extrem扩展要求（例如stackoverflow或流量更大的网站）？找到一种不使用数据库的方法。

确实，数据库通常是瓶颈。但正确设置数据库应该可以处理几个字节的会话数据。更复杂的数据和查询是性能成本的原因。

Answer 4

所有其他项目都是很好的建议。还有一点是：如果你不是绝对需要，不要使用Session状态。

在数据库中存储会话（通常）是个坏主意，原因很简单：

1. 会话的典型用途是不必多次从数据库服务器加载公共数据。如果会话存储在数据库服务器中，那么，你真的没有做太多。

2. 每次执行单页时都必须对Session进行序列化和反序列化。这意味着必须从服务器检索会话数据，并且无论您是否使用它，都会在每个页面加载时将其写回服务器。

根据我的经验，您可以更好地在实际需要时从数据库服务器中提取数据。在大多数情况下，人们将各种短期数据放在会话中只是因为他们认为他们正在解决性能问题，而实际上他们正在使情况变得更糟。

此外，如果您限制数据量（例如用户ID，名称或类似内容），那么您可以将其存储在加密的Cookie客户端，而不必担心它。< / p>

MemCache是​​一个选项;但是我再次认真地看看你的数据库使用情况，看看你是否可以先调整查询和模式的性能。