Java 在tomcat实例之间共享会话（不使用粘性会话）

我将有3台Tomcat服务器和一个负载平衡器，它可以在不使用“”的情况下发送请求。

我想在服务器之间共享会话的数据，我想把它们保存在数据库中。我想将其用作数据库前面的一个层，以便更快地为请求提供服务。

我正在考虑提供我的定制tomcat管理器，该管理器在将会话数据获取/持久化到DB之前使用memcached，因为目前我看不到一种透明的方式（这意味着在切换到另一个应用服务器的情况下，我必须再次管理它）。

---

这是一个好的解决方案，还是您看到了更好的方法？

我们在应用程序中也做了类似的事情（Weblogic，但这并不重要），在浏览器中，我们将唯一的会话密钥存储为cookie。然后，该密钥将在每次请求时用于从数据库恢复相关会话数据

---

利用这一原理，我们可以随时使用负载平衡器切换到另一台服务器，而用户不会注意到任何情况。除此之外，我们几乎不会在用户会话中存储任何相关内容，也不会在浏览器中使用大量隐藏字段（负载平衡器支持URL加密和表单值保护，因此我们是安全的…。

我想这是您想要的

将会话状态存储在应用服务器之外（在您的例子中是Tomcat），这是一种非常常见且推荐的大型网站配置。这通常是为了追求一种称为的架构风格

您可以将您的状态存储在几个不同的位置：db、memcached、商业复制缓存等。它们都以不同的折衷方式工作。就个人而言，我在memcached方面取得了巨大成功。Memcached非常快速和稳定

---

通常，我选择简单，使用N个memcache服务器，其中N>1，比如2。当用户登录时，应用服务器会掷硬币决定哪个服务器存储用户状态。发送到浏览器的cookie中包含了一些信息，以便从那时起知道要路由到哪个memcache服务器。来自浏览器的后续请求在每个请求上从相应的memcache服务器获取状态。如果memcache服务器出现故障，用户将不得不在应用服务器重新选择新服务器时再次登录，但这种情况极为罕见。

在数据库中持久化会话会限制您的可扩展性。如果可伸缩性对您来说不是那么重要，那么这（db+memcached）是一种有效的方法

在使用非粘性session时，需要记住的一件事是并发请求：当您有例如ajax请求（并行/并发执行）时，它们将由不同的tomcat提供服务（由于非粘性），因此并发访问会话。只要您有可能修改会话的并发请求，您就需要实现某种同步/会话锁定

也许这是您感兴趣的：我创建的目标是实现最佳性能和无限的可伸缩性。它可以与任何与memcached兼容的后端（如memcachedb、membase等，或仅memcached）一起使用。 虽然它最初是为粘性会话方法创建的，但是已经有一个现有的和一个演示它是如何工作的。

---

现在有一个解决方案（处理并发请求并防止单点故障）。

@Lucas Eder我们有类似的设置，不同之处在于我们使用Memcached进行会话存储。对于某些应用程序，它“无关紧要”（就认证用户而言，ie会话数据可能不敏感），但原则上，来回传送“会话”数据——无论是作为“隐藏”字段（当然，HTML页面上的任何字段都不会对用户真正隐藏）还是作为cookie，都是不好的做法。除非应用程序的客户端需要此数据，否则不应将其公开给浏览器。@DanFarrell:隐藏字段不是敏感数据，表单值保护使其不会被调整。所以我不认为这会是一个糟糕的做法，安全方面。当然，有很多数据传输开销……我只想在这里指出，我刚刚发布了带有非粘性会话支持（以及对tomcat7的支持）的memcached会话管理器。该公告提供了一些关于非粘性会话的详细信息：关于ajax请求的观点非常好。在同一个流程中，可能会有多个服务器请求。@MartinGrotzke这可能会有帮助，可能会有帮助@Amogh我认为现在也为2010年的这个问题提供了一个非常透明的解决方案：）