我们有一个需要维护状态的应用程序，以便客户端（浏览器）可以在“对话”交互中查询一些包含数据（可能很多）的对象。每次请求都重新加载数据效率不高。
我们使用 Spring 和会话范围的 bean 来维护一些会话控制的数据。然而，这些新豆会更大。
这是对会话范围 bean 的适当使用还是缓存 (ehcache) 更适合？
除非我们真的必须这样做，否则我们不愿意引入缓存技术。
另一个因素是应用程序需要部署在集群中。在哪种情况下，应用服务器的会话复制会复制会话范围的 bean，或者使用 ehcache 会更有效（我相信它可以分布在集群中）？
任何指导表示赞赏。
【问题讨论】：
标签： spring session-state ehcache
对此有一些想法（免责声明：我为 terracotta/ehcache 工作......所以请记住这一点......但仍然试图在这里保持公正）：
1 - 每个会话中是否有任何冗余数据？任何可以跨会话共享的东西？如果是，+1 让 ehcache 存储共享内容（因为 ehcache 针对高并发进行了优化）
2 - 你的会话对象有多大？在稳定状态下，您期望有多少并发用户？ （换句话说，您将有多少内存专用于应用服务器上的会话存储？）
如果会话占用空间总体上不是很大并且可以很好地放入您的堆中而没有 GC 问题，那么使用会话应该是一个很好的解决方案。
但它越大，您的 java 堆就需要越大……而且您将不得不使用更多的巫术技巧来控制垃圾收集和 gc 暂停时间。 通过使用 ehcache，您可以集中存储多个会话可以访问的一些对象......因此整合您的内存占用（与 1 相同） 此外，通过使用 ehcache 的企业扩展 (BigMemory=http://terracotta.org/products/bigmemory)，您可以绕过堆限制并将数据存储在堆外（根据需要 - 10 秒、100 秒 GB 或更多）。这样，需要在内存中的对象的大小就变得无关紧要了（当然，只要您可以向服务器添加 RAM）
3 - 对于会话复制，JBOSS、Weblogic、Websphere 等应用服务器都支持它。同样，这又是会话大小的问题（需要通过网络复制多少数据）。如果您的会话对象很大，并且您有很多，那么您的集群中将会有很多网络流量......可能会或不能正常工作。 在我看来，在分布式 EhCache 层中为数据存储优化核心对象，同时将会话保持在最低限度（即登录/身份验证信息）肯定会增强会话复制机制。
希望对您有所帮助。
【讨论】：