非常多研发中涉及到用户的Session验证非常保留的问题,这个问题比较有意思,总结了几种方案,只供参考。
[ 问题提出 ]
为了满足足够大的应用,满足更多的客户,于是我们架设了N台Web服务器(N>=2),在多台Web服务器的情况下,我们会涉及到一个问题:用户登陆一台服务器以后,如果在跨越到另一台服务器的时候能够继续使用客户的Session?
(以下描述方案只是针对Linux/Unix + Apache + Mysql + PHP的研发架构,当然,也能扩展到其他平台。)
[ 问题解决方案 ]
既然我们的问题已摆在面前了,那么就要从技术角度去解决问题,给我们的客户更好的体验,总结了几个方案。
1. 写客户端Cookie的方式
当用户登陆成功以后,把网站域名、用户名、密码、token、session有效时间全部采用cookie的形式写入到客户端的cookie里面,如果用户从一台Web服务器跨越到另一台服务器的时候,我们的程式主动去检测客户端的cookie信息,进行判断,然后提供对应的服务,当然,如果cookie过期,或无效,自然就不让用户继续服务了。当然,这种方法的弊端就不言而喻了,比如客户端禁用了cookie或cookie被黑客窃取了呢?
2. 服务器之间Session数据同步的方式
假设Web服务器A是所有用户登陆的服务器,那么当用户验证登陆一下,session数据就会写到A服务器里,那么就能自己写脚本或守护进程来自动把session数据同步到其他Web服务器,那么当用户跳转到其他服务器的时候,那么session数据是一致的,自然就能够直接进行服务无须再次登陆了。缺点是,可能会速度慢,不稳定,如果是单向同步的话,登陆服务器出现问题,那么其他服务器也无法服务,当然也能考虑双向同步的问题。
3. 利用NFS共享Session数据的方式
其实这个方案和下面的Mysql方案类似,只是存储方式不相同。大致就是有一台公共的NFS服务器(Network File Server)做共享服务器,所有的Web服务器登陆的时候把session数据写到这台服务器上,那么所有的session数据其实都是保存在这台NFS服务器上的,不论用户访问那太Web服务器,都要来这台服务器获取session数据,那么就能够实现共享session数据了。缺点是依赖性太强,如果NFS服务器down掉了,那么大家都无法工作了,当然,能考虑多台NFS服务器同步的形式。
(关于NFS的经典文章:http://linux.vbird.org/linux_server/0330nfs.php)
4. 利用Mysql数据库共享Session数据的方式
这个方式和NFS的方式类似,也是采用一台Mysql服务器做共享服务器,把所有的session的数据保存到Mysql服务器上,所有Web服务器都来这台Mysql服务器来获取Session数据。缺点也是依赖性太强,Mysql无法工作了影响所有的Web服务器,当然,能考虑多太Mysql数据库来共享session,使用同步Mysql数据的方式。
(Mysql同步我写过文章:http://blog.csdn.net/heiyeshuwu/archive/2005/10/31/520007.aspx)
5. 使用硬件设备
这个算是比较成熟的解决方案了,使用类似BIG-IP的负载设备来实现资源共享,那么就能够又稳定又合理的的共享Session了。目前非常多门户网站采用这种方式。缺点非常明显了,就是要收费了,硬件设备肯定需要购买成本的,不过对于专业或大型应用来讲,是比较合理并且值得的。
(关于BIG-IP设备:http://www.f5.com.cn/channel.php?channel=product&type=BIG-IP-%D3%A6%D3%C3%C1%F7%C1%BF%B9%DC%C0%ED&id=36)
以上这些只是我的个人愚见,没有经过试验,不确保其准确实在性,只是提供一种想法和参考。
分享到:
相关推荐
具体的实现细节和技术选型需要结合项目实际情况来确定,例如《多台服务器共享SESSION - 学在囧途的日志 - 网易博客》和《多服务器共享session的方法》这两篇文章可能提供了更深入的实践案例和技术解析,值得进一步...
然而,当一个网站部署在多台服务器上时,单个服务器上的session无法在其他服务器之间共享,这可能导致用户在切换服务器时丢失其会话信息。 此时,就需要引入session共享技术。PHP的memcache扩展提供了一个解决方案...
4. **JWT(JSON Web Token)**:使用JWT作为session的载体,将用户信息编码为一个安全的令牌,这个令牌可以在集群中的所有服务器之间传递。客户端负责保存JWT,每次请求时将其附在请求头中,服务器通过验证JWT来识别...
但这仅解决了部分问题,如果所有服务器需要共享Session数据,还需要更复杂的解决方案。 描述中提到的“jar包”,很可能是指实现Session共享的中间件,如Redis或Memcached。这些缓存服务可以作为一个集中式的Session...
在分布式系统环境中,Web项目的集群部署能够提供高可用性和负载均衡,但同时也引入了一个问题:如何在多个服务器之间共享Session信息。"web项目集群时共享session方案实践"的主题旨在探讨和解决这一挑战。以下是关于...
该方案的核心思想是利用ASP.NET 2.0的内置功能,将Session对象序列化为可传输的文本格式(如Binary或Soap),然后在不同Web服务器之间通过共享文件系统进行传递。这种方法的优点在于减少了对数据库的依赖,并且在...
引入Redis作为Session存储解决方案的原因在于,Redis是一个高性能的键值数据库,支持多种数据结构如字符串、哈希、列表、集合等,同时也提供了丰富的操作命令。更重要的是,Redis可以通过网络进行通信,适合于分布式...
分布式Session解决方案是为了在分布式系统环境下实现用户会话的共享,以克服HTTP协议无状态的特性。在传统的Web应用中,Session通常存储在单个Web服务器的内存中,但在分布式环境中,用户请求可能会被负载均衡器分配...
2. 多服务器共享Session:在高可用性和负载均衡的架构下,通常会有多个应用服务器,如Tomcat、JBoss等,每个服务器都需要能够访问和更新同一个Session。 3. 跨平台Session共享:即使应用系统基于不同的技术栈,例如...
通过使用 Redis 作为 Session 存储,多个应用服务器可以共享同一个 Session,从而实现分布式 session 共享。 7. 优点 本方案的优点包括: * 实现分布式 session 共享 * 提高系统的可扩展性和灵活性 * 简化了登录 ...
总的来说,使用Memcache实现PHP Session的多服务器共享是一种高效的方法,特别适合高并发、分布式环境的Web应用。不过,为了提高可用性和可靠性,可以考虑结合其他持久化存储(如Redis)或使用更高级的Session管理...
为了解决这个问题,我们需要一个共享session的机制。 **解决方案**: 利用Redis作为session存储,每个Tomcat实例在接收到请求时,不再在本地存储session,而是将其保存在Redis中。Nginx在分发请求时,可以通过粘滞...
本解决方案将详细介绍如何在`CentOS7`上配置`Nginx`以实现`Tomcat`的负载均衡,并利用`Redis`进行Session共享,以提高系统的可扩展性和用户会话的一致性。 首先,我们需要在`CentOS7`上安装`Nginx`。可以使用`yum`...
在构建分布式Web应用程序时,确保用户会话在多个服务器之间无缝地共享是一项关键任务。PHP是一种广泛使用的服务器端脚本语言,它默认的session存储机制并不适用于多服务器环境。为了解决这个问题,开发者通常会利用...
标题中的“Memcached分布式缓存服务替换Session解决方案”是指一种使用Memcached作为分布式缓存来管理Web应用中的Session状态的方法,以替代传统的基于服务器端Session存储的策略。这种方案主要针对的是多服务器环境...
在集群环境中,单台服务器无法共享Session,需要使用粘性会话(sticky sessions)或共享Session存储方案。例如,使用负载均衡器分配特定的服务器处理特定用户的请求,或利用分布式Session存储如Redis、Memcached,...
综上所述,跨域共享session涉及到多个技术层面,包括浏览器限制、服务器配置、前端处理和安全措施。实现HTTP到HTTPS的session共享需要综合考虑这些因素,并确保在提供便利的同时,保证用户数据的安全。
实现方式:可以使用开源的 MSM 插件解决 Tomcat 之间的 Session 共享。 第四种:Session 持久化到数据库 Session 持久化到数据库是指将 Session 信息存储到数据库中,以保证 Session 的持久化。 优点:服务器出现...
在分布式系统中,由于用户请求可能会被路由到不同的服务器上,因此,如何在多台服务器之间共享session数据成为了一个挑战。这就是“用redis共享session”这个主题所关注的核心问题。 Redis是一个高性能的键值数据库...
4. **共享Session的解决方案**: 为了实现session共享,我们可以利用Redis这样的内存数据存储系统。Redis具有高速读写性能,支持数据持久化,适合做session的中央存储。将session存储在Redis中,每个Tomcat实例在...