在哪里缓存：使用 SessionScoped 托管 bean 的数据库缓存或应用服务器？答案

【问题标题】：Where to cache : Database cache or App server using SessionScoped managed beans?在哪里缓存：使用 SessionScoped 托管 bean 的数据库缓存或应用服务器？
【发布时间】：2011-07-27 04:35:10
【问题描述】：

我正在使用 Casssandra DB 和带有 JSF 2.0 的 Java 构建 Web 应用程序。

Cassandra 有自己的缓存层，我也可以在 JSF 中使用 SessionsScoped 托管 bean 进行缓存。我想知道什么是实现不同类型数据缓存的好方法：待缓存的数据有时对于一种来说很大，有时它很小（第二种）。

由于 Cassandra 行中的缓存数据列将以序列化格式和整个列结构存储数据，我想我最好将它们存储在应用程序服务器中的会话范围 bean 中，这样我也可以更好地控制缓存数据和缓存数据可能是最相关的，我想这两种情况下的硬件要求没有区别：-（1）当我使用 sessionscoped beans 实现它时（2）如果我使用 DB 缓存。

请列出这两种缓存实现可能带来的好处的任何差异。

【问题讨论】：

标签： java session caching jsf

【解决方案1】：

不要（ab）将会话范围用作大型数据集的缓存。您基本上是在为每个访问者复制缓存。您应该有一个缓存。数据库缓存非常好。

关于数据的大小，您应该有效地拥有一个请求或视图范围的 bean，它包含完全最终用户在特定请求中需要了解的数据。例如。当您通过每页 10 个对象的分页显示 1000 个对象的数据集时，请求范围的 bean 应该正好包含这 10 个对象，并且剩余部分应该保留在 DB/DB 缓存中。代码也应该这样编写，它可以准确检索这 10 个对象（因此不要检索 1000 个对象，然后从中过滤出所需的 10 个）。

【讨论】：

如果缓存在会话 bean 中的数据非常特定于用户怎么办？
存储just在请求或会话范围内可以获取相同数据集的那些参数，例如搜索查询、第一行、行数等（因此不是整个数据集本身）。
我试图从他的关注者中存储一些帖子的 ID（在社交应用程序上），这些 ID 应该在他的页面上可见。由于 Ids 列表只有 8 字节长的列表，大约 20-30 个元素，因此存储在会话 bean 中是否有意义。这是非常具体的，并且不包含实际的数据集
我不太了解功能要求。首先回答这个问题：为什么请求或视图范围的 bean 不足？
如果数据特定于登录用户并在每个登录页面浏览中使用，那么将其与登录用户一起存储在会议。但例如搜索结果和/或任何事物的概述（例如帖子、回复、cmets、其他用户的朋友等），不应存储在会话范围内。最终对 1000 个并发用户进行压力测试并进行测量。