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