session

1、使用Redis实现分布式部署单点登录（单点登录第一种方法：redis分布式存储解决方案） 因为这个项目是一个分布式部署的项目，而且我们采用的是nginx负载均衡的策略，导致了每一个服务器都需要开辟一个空间来进行用户信息的维护，消耗了大量的资源，所以，我当时使用到了Redis来作为维护用户信息的空间，将用户登录的信息存入Redis中，并且在存入时设置key的过期时间，所有的服务器共用一个Redis，每次进行操作时只需要去Redis中去判断这个用户是否存在，存在的话就说明这个用户现在是登录状态，不存在就说明这个用户没有登录，或者登录已经失效，让用户进行重新登录。 为什么会存在单点登录的问题 session默认是存储在当前服务器的内存中 ，如果是集群，那么只有登录那台机器的内存中才有这个session 比如说我在A机器登录，B机器是没有这个session存在的，所以需要重新验证 如何解决这个单点登录问题 不管在那一台web服务器登录，都会把token值存放到我们的一个集中管理的redis服务器中 但客户端携带token验证的时候，会先从redis中获取，就实现单点登录 现实举例 比如你写的一个tornado项目，分别部署到A，B两台机器上 如果直接使用session，那么如果在A机器登录，token只会在A服务器的内存 因为请求会封不到A，b连个机器，如果这个请求到了B机器

在访问量上去以后，很多人会采用web集群的方式在满足逐渐增长的用户量。这时候就不得不面对一个问题，那就是在多个服务器下，每次请求都会因为负载均衡而分配到不同的服务器上。用户在登录服务器后，下一次请求被分配到另一个服务器上，这时候session不同步，用户就无法继续使用原先的session。下面我就聊聊如何解决这个问题。 一、利用Mysql数据库共享Session数据的方式 使用一个mysql服务器做共享服务器，把所有的session的数据保存mysql服务器上，所有的web服务器都来这台mysql服务器来获取session数据。这里有一个关键的地方，用来存放session的数据表不要跟其他 数据库 表放在一起，要 独立开 来，专门放在一个低端的服务器上面。不然，数据库本身压力就很大了，再加上 session是需要频繁的读取 的，这使得数据库很容易达到瓶颈，从而导致过高的响应延迟。 二、利用cookie共享Session数据 当用户请求后产生的session，我们把他的 sessionId和值都存在cookie里面 。这样，当你访问a服务器后，产生了session放在客户端的cookie里面，你在访问被分配到b服务器上。这时候，b服务器先判断本身服务器上有没有这个用户的session，如果没有，在去看看客户端的cookie里面有没有这个session，如果有

http协议是WEB服务器与客户端(浏览器)相互通信的协议，它是一种无状态协议。所谓无状态，指的是不会维护http请求数据，http请求是独立的，非持久的。而越来越复杂的WEB应用，需要保存一些用户状态信息。这时候，Session这种方案应需而生。PHP从4.1开始支持Session管理。 session是很抽象的一个概念。我们不妨先从与它几个息息相关的有迹可寻的小切入点入手，然后逐渐地认识了解它。 session存储 首先，我们为什么需要Session，就是因为我们需要存储各个用户的状态数据。那么试问，如果由你来设计解决这个需求的方案，那么也许你会设置这样一个数据表用与存储各个用户的状态信息： uid created data max_age 94c55770fdf044a7 1270802787 jtUsername=admin 14400 2c37df64277e4409 1270822787 jtUsername=Joe;jtBooks=8; 14400 … … … … uid : 用户唯一标识符，区分其它用户 created : 记录产生时间 data : 存放与用户相关的数据 max_age : 记录的有效时间 同样地，PHP设计管理session方案也大致如此，它分别包含了以下信息: 1. session id 用户session唯一标识符，随机生成的一串字符串

问题 从一个例子说起，我们的客户端从服务器获取数据，这里假定获取文章。第一次使用，我们获取服务器端最新发表的几篇文章。 我们可以每次都重新获取，但这样费时又费流量。好的设计应该是我们把获取过的文章存下来，下次只获取最新发表的文章。 这样就有个问题，如果某一篇文章，我们已经获取过了，可有一天它更新了。。。。 还有个问题，文章持续获取下去，我们手机没空间了。。。。 如何使我们客户端能保存有限的文章，并且同时可以得到更新呢？ 解决方法 为了保证客户端不存过多文章，我们应该设置一个过期期限，当缓存的文章比较老旧，删除掉即可。 为了保证客户端的文章能够得到更新，服务器的文章表应该有个最后修改时间字段。同时服务器端保存客户端最后一次获取文章的时间，保存在session里。 1、文章表设计 | index | content | ts | dl | index 索引； content 内容； ts 文章最后一次的修改时间。把ts的格式设计为：NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP，即默认为当前的时间戳，且随着文章更改，自动更新为更改时间。 dl 文章是否被删除了； 2、客户端查询文章时服务器端的工作 从session中查询该用户对文章的最后一次获取时间，last_gotten_ts； 如果有该记录

PHP大型Web应用入门（三） 接上一篇：还是郁字符长度的限制。 早期版本的PHPWIND论坛的cache机制是很差的，虽然它很快，但是很脆弱，一旦cache文件损坏或丢失，它不会自己去创建它，而是直接导致程序无法运行，这种只能叫做临时文件，而不能叫cache。我不知道现在的PHPWIND什么样，因为我一直没兴趣去看它…… 下面的部分是mSession的实现，它只是模拟了session的存取过程，并对系统session进行了改进。它用了Hash目录。它的缺点是在程序结束部分还要Rewrite一下，把数据更新到session文件里，当然这个很容易被改进。 < ? php class BsmSession { var $ sid ; var $ sess_file ; function mSession_Start ( ) { // Special Function...session_start() global $ cookie_sess_id_varname , $ cookie_path , $ sess_liftime , $ mSession ; $ sid = $ _COOKIE [ $ cookie_sess_id_varname ] ? $ _COOKIE [ $ cookie_sess_id_varname ] : $ this - > _Gen_Sid ( ) ;

ACID:Atomic、Consistent、Isolated、Durable 存储程序提供了一个绝佳的机制来定义、封装和管理事务。 1，MySQL的事务支持 MySQL的事务支持不是绑定在MySQL服务器本身，而是与存储引擎相关： MyISAM：不支持事务，用于只读程序提高性能 InnoDB：支持ACID事务、行级锁、并发 Berkeley DB：支持事务 隔离级别： 隔离级别决定了一个session中的事务可能对另一个session的影响、并发session对数据库的操作、一个session中所见数据的一致性 ANSI标准定义了4个隔离级别，MySQL的InnoDB都支持： READ UNCOMMITTED：最低级别的隔离，通常又称为dirty read，它允许一个事务读取还没commit的数据，这样可能会提高性能，但是dirty read可能不是我们想要的 READ COMMITTED：在一个事务中只允许已经commit的记录可见，如果session中select还在查询中，另一session此时insert一条记录，则新添加的数据不可见 REPEATABLE READ：在一个事务开始后，其他session对数据库的修改在本事务中不可见，直到本事务commit或rollback。在一个事务中重复select的结果一样，除非本事务中update数据库。 SERIALIZABLE

1. session和cookie学习 1.1. 技术的需求 以京东未登录时添加购物车为例，在京东上购买东西（未登录）可以添加到购物车，这时候有个问题是京东如何存储没有登录的你添加的购物车物品？我们肯定想到域对象，request、ServletContext域对象 request对象有个问题：request是请求一次，产生一次，如果继续请求就会释放掉，也就是说request就有一个，就在本次请求中。这种特性显然是不行的，因为假如你添加了一个物品进入购物车，然后添加另一个物品，这是第二个请求，就会将第一个请求给覆盖掉。因此用request域对象来做购物车的添加是不可行的。 ServletContext域对象，这个也有问题，这个对象是全局的，不管谁添加购物车，都会集中在一起，在付账时会发现你会付账所有人添加的购物车，这显然是不可取的。 我们的需求是：当我们添加一个物品到购物车时，我们可以多次添加。也就是说由服务器给我们创造一个个人空间，这就引出了另一个域对象session对象 1.2. 会话技术学习 会话技术：从打开一个浏览器访问某个站点开始，到关闭这个浏览器的整个过程，成为一次会话。会话技术就是记录这次会话中客户端的状态与数据。 会话技术分为两种：cookie和session技术。cookie，数据存储到客户端本地，减少服务器存储压力，安全性不好，客户端可以清除cookie

J2EE集群不太了解的人首先可以看看附件里面的《解开J2EE集群的神秘面纱》， 讲的挺好的。 J2EE的服务器集群主要的就是 负载均衡 和 失败转移 这些。 负载均衡这个话题都烂大街了，随处可以找到相关的帖子或博文，我也就不谈了。 但是这些帖子中大部分都只谈了负载均衡，顶多再说一下 Tomcat 的 HttpSession 复制（失败转移的一种解决方案吧）。更有甚者，直接决定“集群中服务器节点宕机丢失的部分 HttpSession 不碍事”。。。 我的感觉就是， 像 Tomcat 的 HttpSession 交叉复制，如果集群中服务器过多对性能的影响肯定非常之大。 像 JBoss、WebLogic 等的服务器链式 HttpSession 复制，如果一个服务器节点宕机，此节点的下一个服务器节点就得负责两个服务器的用户请求。是不是有点怕人奥。 至于“集群中某个节点宕机就宕机， HttpSession 丢失无所谓”这样的观点也是挺匪夷所思的，毕竟后台中2000个 HttpSession 同时丢失的后果不是那么容易承担的。 为了解决上面这些问题，我自己琢磨了一套方案，感觉挺不错的（不知道网上是不是有类似“轮子”，反正我是没有搜索到）。 就发出来共享一下，嘿嘿 我想到的是 缓存服务器和Web服务器双向备份HttpSession ，这个。。。。咱语文挺烂的，表达的不好。