在tomcat实例之间共享会话（不使用粘滞会话）
我将有3个Tomcat服务器和一个负载均衡器，可以在不使用“ 粘性会话 ”的情况下调度请求。
我想在服务器之间共享会话数据，我正在考虑将它们保存在数据库中。 我想在我的数据库前面使用memcached作为一个层来更快地提供请求，并且不要让我的数据库负载很重 。
我正在考虑提供我的自定义tomcat管理器，它在获取/持久化会话数据到DB之前使用memcached，因为我没有看到这样做的透明方式（这意味着我将不得不再次管理它）我切换到另一个应用程序服务器）。
这是一个很好的解决方案还是你看到了更好的方法？
在数据库中保留会话会限制您的可伸缩性。 如果可伸缩性对您来说不重要，那么（db + memcached）是一种有效的方法。
使用nonsticky-sesions时需要记住的一件事是并发请求：当你有例如ajax-requests（并行/并发执行）时，它们将由不同的tomcats服务（由于非粘性），因此访问会话同时。 只要您有可能修改会话的并发请求，您就需要实现某种同步/会话锁定。
也许这对您很感兴趣：我创建了memcached-session-manager ，其目标是实现最佳性能和无限可扩展性。 它可以与任何与memcached兼容的后端（例如memcachedb，membase等或只是memcached）一起使用。 虽然它最初是为粘性会话方法创建的，但已经存在一个用于存在非粘性会话的分支，以及一个示例应用程序，显示它是如何工作的。 现在，邮件列表上有一个线程，用于进一步改进非粘性会话 （处理并发请求和防止单点故障）。
将会话状态存储在应用服务器之外（在您的情况下为Tomcat），对于大型网站来说是一种非常常见且推荐的配置。 这通常是为了追求名为Shared Nothing的架构风格。
您可以将您的状态存储在几个不同的位置：db，memcached，商业复制缓存等。它们都可以使用不同的权衡组合。 就个人而言，我在memcached方面取得了巨大的成功。 Memcached非常快速和稳定。
通常，我选择简单并使用N记忆服务器，其中N> 1，比如说2.当用户登录时，应用服务器会翻转硬币来决定哪个服务器存储用户状态。 发送到浏览器的cookie包括用于知道从那时开始路由到哪个内存缓存服务器的信息。 来自浏览器的后续请求在每个请求上从相应的memcache服务器获取状态。 如果memcache服务器发生故障，用户将不得不再次登录，因为应用服务器会重新选择新服务器，但这种情况极为罕见。
我们在我们的应用程序中做了类似的事情（Weblogic，但这并不重要），我们在浏览器中将一个唯一的会话密钥存储为cookie。 然后，该密钥将在每个请求中用于从数据库恢复相关会话数据。
使用此原则，我们始终可以使用负载均衡器切换到另一台服务器，而无需用户注意任何内容。 除此之外，我们几乎不存储与用户会话相关的任何内容，并在浏览器中使用大量隐藏字段（负载均衡器支持URL加密和表单值保护，因此我们处于安全的一面……） 。
我认为Terracotta Web Sessions就是你想要的。