在应用程序服务器或数据库中维护状态？
REST 提倡在服务器上没有客户端状态的 Web 应用程序。著名的购物车示例被转换为通常驻留在数据库中的资源。
我想知道使用数据库来存储此类数据是否是一个好习惯，因为数据库已经是许多应用程序的瓶颈。使用有状态企业 java bean 不是更好吗？应用程序服务器在设计时就考虑到了集群。
这两种方法的优点和缺点是什么？
REST advocates web applications without client state on the server. The famous shopping cart example is translated to a resource which typically resides in a database.
I wonder if it is a good practise to use a database for that kind of data, since the database is already the bottleneck in many applications. Wouldn't it be better to use a stateful enterprise java bean instead? Application servers are designed with clustring in mind.
What are the advantages and disadvantages of the two approaches?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
仅当满足以下条件时，在应用程序服务器上存储会话才有效：
将会话存储在如果不能保证您的客户端始终连接到集群中的同一应用程序节点，则中央数据库和/或 EJB 将起作用。
另一种可以考虑的方法是使用 memcached 等服务。这在任何一种情况下都有效。
Storing sessions on the application server will only work if:
Storing sessions in a central database and/or EJB will work if your clients are not guaranteed to always connect to the same application node in your cluster.
Another approach to consider is using a service such as memcached. This will work in either case.
一般来说：
数据库
内存中（非分布式有状态 bean）的
您的选择将完全取决于您的应用程序要求和环境。在所有条件相同的情况下，我更喜欢数据库解决方案，因为它具有负载平衡和可靠性优势，但在许多情况下这很容易显得矫枉过正。
In general:
Database
In-Memory (non-distributed stateful bean)
Your choice will be totally dependent on your application requirements and environment. All things being equal, I favor the database solution because of the load balancing and reliability benefits, but this can easily be overkill in many scenarios.
当您的应用程序服务器死机时会发生什么。会话状态还重要吗？去找一个数据库。
您是否有更多的会话状态，那么您的服务器可以处理所有并发用户？将数据移入数据库并仅提取当前真正需要的数据可能是一种解决方案。
您的应用程序是集群化的吗？如果是这样，中央数据库将确保会话数据始终可用。
否则：只需将其存储在会话中。
您是否有极端的扩展要求（例如 stackoverflow 或流量更大的网站）？找到一种不使用数据库的方法。
确实，数据库通常是瓶颈。但是正确设置的数据库应该可以很好地处理几个字节的会话数据。更复杂的数据和查询会降低性能。
What happens when your app server dies. Is the session state still important? Go for a database.
Do you have more session state, then your server can handle for all the concurrent user? Moving data into a database and pulling only out only what you really need at the moment, might be a solution.
Is your app clustered? If so, the central database makes sure the sessiondata is always available.
Otherwise: Just store it in the session.
Do you have extrem scaling requirements (like stackoverflow or sites with even more traffic)? Find a way not to use the database.
It is true, that the database is often the bottleneck. But a properly setup database should handle a couple bytes of session data just fine. More complex data and queries are what costs performance.
所有其他项目都是很好的建议。还有一点是：如果不是绝对需要，请不要使用会话状态。
由于以下几个简单原因，将会话存储在数据库中（通常）是一个坏主意：
会话的典型用途是避免多次从数据库服务器加载公共数据。如果会话存储在数据库服务器中，那么，您实际上还没有完成太多工作。
会话必须针对每个单页执行进行序列化和反序列化。这意味着无论您是否使用它，都必须从服务器检索会话数据，并在每个页面加载时将其写回服务器。
根据我的经验，当您真正需要数据时，只需从数据库服务器中提取数据会更好。在大多数情况下，人们将各种短暂的数据放入会话中只是因为他们认为他们正在解决性能问题，而实际上他们正在使问题变得更糟。
此外，如果您限制数据量（例如用户 ID、名称或类似内容），那么您可以将其存储在加密的 Cookie 客户端中，而根本不必担心。
MemCache 是一种选择；但我会再次认真查看您的数据库使用情况，看看您是否可以首先对查询和模式进行性能调整。
All of the other items are good suggestions. One more is this: Don't use Session state if you don't absolutely need it.
Storing session in a database is (generally) a bad idea for a couple of simple reasons:
Typical use of session is to keep from having to load common data from the database server multiple times. If session is stored in the db server then, well, you really haven't accomplished much.
Session has to be serialized and deserialized for every single page execution. This means that the session data would have to be retrieved from the server, and written back to the server every single page load regardless of whether you use it or not.
In my experience you are much better served to simply pull the data from your database server when you actually need it. In most cases people put all sorts of short lived data in session simply because they think they are solving a performance problem, when in reality they are making it worse.
Further, if you limit the amount of data down (say to a user id, name, or something like that), then you can store that in an encrypted cookie client side and not have to worry about it at all.
MemCache is one option; but again I'd seriously look at your database usage and see if you can performance tune the queries and schemas first.