2014_3_13_CF做session保存

2014_3_13 CF session缓存

CF支持带有Cookie的web应用的部署。

但是没有对session进行缓存

如果是要做实例池的话，第一件事，应该是session同步.
在DEA1接收到请求时，缓存session，
建一个DEA2,也同步DEA1的session？


----------
router中，首先检查请求中，是否有Cookie。如果有的话，将cookie设到http中。

cookie = {
Name: VcapCookieId
Value: x.PrivateInstanceID
Path: /
}
我们可以在检查到有Cookie的时候，发消息，进行同步
用NATS发消息？订阅？

JBoss集群使用的是JGroup进行多播

----------


JBoss集群中的同步，

web的同步，使用的异步通知。
带有< distributale/>的web应用，当它


tomcat也有session复制
if you shutdown or restart this tomcat instance (tomcat instance which is used) the loadbalancer sends the remaining requests to one other tomcat instance that is still running, as you use session replication, the instance tomcat which receives the remaining requests has a copy of the user session then the user keeps on his session。


----------
session复制如何实现？

在请求到DEA1时，同时将session保存到DEA2。
session的保存方式？


----------
GroupCache go语言编写的缓存库，但是不能update和delete
这样的特性，带来的是cluster，不会

cache请求的转发，是在router端转发，还是在DEA？

如果是url请求的话，可以做在router端。
因为router端可以判断是否有cookie。

如果是像EJB那样的应用，如果发生了任何的改变，那么，数据在DEA处cache？

主要是，CF上的应用，都是基于http请求的。

> 首先，我们考虑router端处理session数据的缓存和备份？
如果缓存、备份都做在router端了，那么相当于有一个集中式的备份点。
与DEA就无关了啊。当转发给DEA1时，发现DEA1挂了，那么router将请求转发给DEA2。
同时，router来提供这个session数据？

<br>
> 第二种，router检测到有session时，广播，**所有关心该事件的DEA**，进行session复制？
那么当DEA1挂掉后，router将请求转发给DEA2，DEA2自己就有session的副本，
>
这个只是考虑了存在session，那么所有相关的DEA保存Session
对于session修改的情况呢？



----------
session和cookie的区别？

cookie是存的键值对，而且好像是客户端的，一般是浏览器保存的数据。

session是指一次会话。session数据放在服务器上。

http是无状态的协议，客户每次读取web页面时，服务器都打开新的会话，而且服务器也不会自动维护客户的上下文信息，那么要怎么才能实现网上商店中的购物车呢，session就是一种保存上下文信息的机制，它是针对每一个用户的，变量的值保存在服务器端，通过   SessionID来区分不同的客户,session是以cookie或URL重写为基础的，默认使用cookie来实现，系统会创造一个名为   JSESSIONID的输出cookie，我们叫做session  cookie,以区别persistent   cookies,也就是我们通常所说的cookie,注意session   cookie是存储于浏览器内存中的，并不是写到硬盘上的，这也就是我们刚才看到的JSESSIONID，我们通常情是看不到JSESSIONID的，但是当我们把浏览器的cookie禁止后，web服务器会采用URL重写的方式传递Sessionid，我们就可以在地址栏看到sessionid=  KWJHUG6JJM65HS2K6之类的字符串。   

cookie的内容主要包括：名字，值，过期时间，路径和域。路径与域一起构成cookie的作用范围。若不设置过期时间，则表示这个cookie的生命期为浏览器会话期间，关闭浏览器窗口，cookie就消失。这种生命期为浏览器会话期的cookie被称为会话cookie。

  session机制。session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。
 <br/><br/> 当程序需要为某个客户端的请求创建一个session时，服务器首先检查这个客户端的请求里是否已包含了一个session标识（称为sessionid），如果已包含则说明以前已经为此客户端创建过session，服务器就按照sessionid把这个session检索出来使用（检索不到，会新建一个），如果客户端请求不包含sessionid，则为此客户端创建一个session并且生成一个与此session相关联的sessionid，sessionid的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个sessionid将被在本次响应中返回给客户端保存。保存这个sessionid的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发送给服务器。一般这个cookie的名字都是类似于SEEESIONID。但cookie可以被人为的禁止，则必须有其他机制以便在cookie被禁止时,仍然能够把session id传递回服务器。

  经常被使用的一种技术叫做URL重写，就是把sessionid直接附加在URL路径的后面。还有一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。
  


----------

session复制和粘性session
应该是粘性session和session复制都要实现。当节点1正常工作时，来自同一个用户的请求都转发给节点1，如果有session数据，需要缓存到所有的相关联节点中。当节点1失效时，启用节点2。

----------

为了实现fail-over，启用了session复制，这每个节点都会留一份session的副本，对于大规模的访问，tomcat能否撑住？假如集群面临1000个并发访问，虽然这1000个请求的压力会分散到3个节点上，但是实际上每个节点都有1000个session数，从资源的消耗上并没有节省多少，这样的话，再大的访问量并不一定撑得住。其实session复制的主要目的就是为了某节点宕掉后其他节点能迅速的接管请求，其实就是一个替补的作用。存在于其他节点中的session其实大部分都是空闲并且高度冗余。也就是说，session复制在节点数增多或者访问量激增时是很耗费资源占用中间件内存的。集群虽然提高了可用性，但是性能没有大的提升，尤其集群节点增多时。每当一个session创建后，节点都要向集群分发session，这样，节点都忙着传播session去了，集群的吞吐量会下降。

所以，一种做法就是将session外部存储或者cache，也就是说，将分散在各个节点中的会话信息拿出来，集中式存储，每个节点接收到客户端的会话请求时都去session池中查找session。这其实并不是什么很时髦的做法，大型的网站很多都采用这种办法，加上前端的页面缓存，提高网站的并发访问量和可用性，