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