多台web如何共享session进行存储
若以下回答无法解决问题,邀请你更新回答
展开全部
以前业界使用session的做法:
默认情况下,php的session文件是保存在磁盘文件中。在php.ini配置文件中的配置项如下:
session.save_handler = files
session.save_path = "N;/path"
第一个配置项是指定使用files(文件形式)存储session数据。
第二个参数指定保存的路径。N表示生成多少级目录(不放到一个目录下,分散到多个磁盘目录中去)
我的配置项是:session.save_path = "F:/wamp/tmp"。那么就会去这个目录下面看到很多session数据的文件。
当我们使用php的内置函数session_start()的时候,就是去上面指定的磁盘目录把session数据载入,实际上就是拿类似
sess_74dd7807n2mfml49a1i12hkc45的文件。
74dd7807n2mfml49a1i12hkc45就是大家经常说的什么session的id号。
php.ini中还有一个关键配置项,如下:
session.name = PHPSESSID
PHPSESSID就是cookie的名称,其实上面一串"74dd7807n2mfml49a1i12hkc45"会保存在一个名为PHPSESSID的cookie中。
根据http的请求机制,当浏览器请求的时候,头部信息会把浏览器中的cookie一起发给服务器。PHPSESSID这个cookie也
是在其中发给了服务器,php引擎通过读取PHPSESSID的值来确定要载入哪个session文件。
比如值为74dd7807n2mfml49a1i12hkc45,载入的就是"sess_74dd7807n2mfml49a1i12hkc45"。
注:当你调用php的函数session_start(),才表明你需要使用session文件了。不然平白无故就去载入文件,浪费性能。
根据如上原理。session的数据默认是保存在磁盘文件中。假设这种情况:多台php服务器进行负载均衡的时候,比如有三台php服务器,为了实现负载均衡,那么三台服务器上面的php代码都是一样(拷贝一份)。
生成session数据文件都是在本地了(a,b,c各自的服务器磁盘上)。负载均衡的目的本来就是要为了平均分配请求,所以没有固定第一次访问和第二次访问是同一台服务器,实际上无法确定的。第一秒访问可能是a服务器,第二秒访问的可能是c服务器。
所以同一个登录会员,实际上就会出现:第一秒访问第一台php服务器,第二秒访问的是第二台服务器。登录的信息一般是保存在session中的。这样子登录保存的session数据就需要进行共享了。不然的话会出现,访问第一台服务器生成了一个session数据。第二秒负载请求到第三台服务器,结果获取不到刚才生成的session数据。
目前业界解决session共享的几种思路,我总结如下:
第一种办法:把原来存储在服务器磁盘上的session数据存储到客户端的cookie中去。
这样子,就不需要涉及到数据共享了。a客户端请求的时候,原来生成在服务器的数据生成到浏览器的cookie中,根据cookie中的数据识别用户。php由原来的”从本地(也就是服务器)磁盘上读取session数据”转变为”浏览器的cookie中读取数据”,
这样子,在多台php服务器负载均衡的情况下,即便第一秒请求是a服务器,第二秒请求是b服务器,都不需要管哪台服务器了。反正都是读取客户端上的cookie数据。
一般是把session数据按照自己定义的加密规则,加密后后存在cookie中。
数据保存在cookie中这种做法有好处,也有坏处。
好处是服务器的压力减小了,因为session数据不存在服务器磁盘上。根本就不会出现session读取不到的问题。
带来的弊端是:
网络请求占用很多。每次请求时,客户端都要通过cookie发送session数据给服务器。
另外,浏览器对cookie的大小存在限制。每个浏览器限制是不同的。
Firefox和Safari允许cookie多达4097个字节,包括名(name)、值(value)和等号。
Opera允许cookie多达4096个字节,包括:名(name)、值(value)和等号。
Internet Explorer允许cookie多达4095个字节,包括:名(name)、值(value)和等号。
所以第一种方案不适合高访问量的情况下,因为高访问量的情况下,每次请求浏览器都要发送session数据给服务器。一般一个cookie大小2k的样子。
要占用很多带宽了(服务器购买带宽是一个很大费用),成本增高。归纳为带宽性能,速度问题。
存储到cookie中去,第二方面是安全问题:把session数据放到客户端,一般session中存的都是重要性数据(帐号、昵称、用户id等),会存在安全问题。
了解到,淘宝以前用过这种方式,把session数据存储到cookie中,根据cookie来识别用户。
第二种思路:用一种算法(简单理解为规则),什么机制下session是保存在哪台服务器下,那么读取的时候就按照这种规则去读取,就能定位到原来的服务器。叫做分发请求,分发到特定的服务器上去,我理解其原理是存session和读session数据保证都在一台服务器操作,就不会需要涉及到共享,具体实现方式是通过约定一种分发机制来实现。
也叫做sticky模式(粘性会话模式),同一个用户的访问请求都被派送到同一个服务器上。
假设是同一个用户user1,每次访问都路由到同一台服务器上,这样即便是在负载均衡的情况下,也能保证每次访问都能读取到session,不需要做session数据共享了。
关键多台server的原因是为负载均衡而做的,那么就得把原来负载均衡的规则假设是—a,现在改为按照session来均衡分发请求的规则—b。
默认情况下,php的session文件是保存在磁盘文件中。在php.ini配置文件中的配置项如下:
session.save_handler = files
session.save_path = "N;/path"
第一个配置项是指定使用files(文件形式)存储session数据。
第二个参数指定保存的路径。N表示生成多少级目录(不放到一个目录下,分散到多个磁盘目录中去)
我的配置项是:session.save_path = "F:/wamp/tmp"。那么就会去这个目录下面看到很多session数据的文件。
当我们使用php的内置函数session_start()的时候,就是去上面指定的磁盘目录把session数据载入,实际上就是拿类似
sess_74dd7807n2mfml49a1i12hkc45的文件。
74dd7807n2mfml49a1i12hkc45就是大家经常说的什么session的id号。
php.ini中还有一个关键配置项,如下:
session.name = PHPSESSID
PHPSESSID就是cookie的名称,其实上面一串"74dd7807n2mfml49a1i12hkc45"会保存在一个名为PHPSESSID的cookie中。
根据http的请求机制,当浏览器请求的时候,头部信息会把浏览器中的cookie一起发给服务器。PHPSESSID这个cookie也
是在其中发给了服务器,php引擎通过读取PHPSESSID的值来确定要载入哪个session文件。
比如值为74dd7807n2mfml49a1i12hkc45,载入的就是"sess_74dd7807n2mfml49a1i12hkc45"。
注:当你调用php的函数session_start(),才表明你需要使用session文件了。不然平白无故就去载入文件,浪费性能。
根据如上原理。session的数据默认是保存在磁盘文件中。假设这种情况:多台php服务器进行负载均衡的时候,比如有三台php服务器,为了实现负载均衡,那么三台服务器上面的php代码都是一样(拷贝一份)。
生成session数据文件都是在本地了(a,b,c各自的服务器磁盘上)。负载均衡的目的本来就是要为了平均分配请求,所以没有固定第一次访问和第二次访问是同一台服务器,实际上无法确定的。第一秒访问可能是a服务器,第二秒访问的可能是c服务器。
所以同一个登录会员,实际上就会出现:第一秒访问第一台php服务器,第二秒访问的是第二台服务器。登录的信息一般是保存在session中的。这样子登录保存的session数据就需要进行共享了。不然的话会出现,访问第一台服务器生成了一个session数据。第二秒负载请求到第三台服务器,结果获取不到刚才生成的session数据。
目前业界解决session共享的几种思路,我总结如下:
第一种办法:把原来存储在服务器磁盘上的session数据存储到客户端的cookie中去。
这样子,就不需要涉及到数据共享了。a客户端请求的时候,原来生成在服务器的数据生成到浏览器的cookie中,根据cookie中的数据识别用户。php由原来的”从本地(也就是服务器)磁盘上读取session数据”转变为”浏览器的cookie中读取数据”,
这样子,在多台php服务器负载均衡的情况下,即便第一秒请求是a服务器,第二秒请求是b服务器,都不需要管哪台服务器了。反正都是读取客户端上的cookie数据。
一般是把session数据按照自己定义的加密规则,加密后后存在cookie中。
数据保存在cookie中这种做法有好处,也有坏处。
好处是服务器的压力减小了,因为session数据不存在服务器磁盘上。根本就不会出现session读取不到的问题。
带来的弊端是:
网络请求占用很多。每次请求时,客户端都要通过cookie发送session数据给服务器。
另外,浏览器对cookie的大小存在限制。每个浏览器限制是不同的。
Firefox和Safari允许cookie多达4097个字节,包括名(name)、值(value)和等号。
Opera允许cookie多达4096个字节,包括:名(name)、值(value)和等号。
Internet Explorer允许cookie多达4095个字节,包括:名(name)、值(value)和等号。
所以第一种方案不适合高访问量的情况下,因为高访问量的情况下,每次请求浏览器都要发送session数据给服务器。一般一个cookie大小2k的样子。
要占用很多带宽了(服务器购买带宽是一个很大费用),成本增高。归纳为带宽性能,速度问题。
存储到cookie中去,第二方面是安全问题:把session数据放到客户端,一般session中存的都是重要性数据(帐号、昵称、用户id等),会存在安全问题。
了解到,淘宝以前用过这种方式,把session数据存储到cookie中,根据cookie来识别用户。
第二种思路:用一种算法(简单理解为规则),什么机制下session是保存在哪台服务器下,那么读取的时候就按照这种规则去读取,就能定位到原来的服务器。叫做分发请求,分发到特定的服务器上去,我理解其原理是存session和读session数据保证都在一台服务器操作,就不会需要涉及到共享,具体实现方式是通过约定一种分发机制来实现。
也叫做sticky模式(粘性会话模式),同一个用户的访问请求都被派送到同一个服务器上。
假设是同一个用户user1,每次访问都路由到同一台服务器上,这样即便是在负载均衡的情况下,也能保证每次访问都能读取到session,不需要做session数据共享了。
关键多台server的原因是为负载均衡而做的,那么就得把原来负载均衡的规则假设是—a,现在改为按照session来均衡分发请求的规则—b。
本回答被网友采纳
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询