关于rails大容量网站部署的性能讨论

可能会有这个问题，我没有验证过。

不过我现在倾向于根本不使用session，因为这种使用方式，当用户修改信息的时候，难于在多个节点之间进行同步修改。因此一定要session信息的话，恐怕也只能往分布式Cache里面设置了。

不用session,权限怎么控制?比如根据不同的用户显示不同的连接,一般都是用tag取得session里面的值,acegi也是用session保存信息的

我觉得在节点数不多时可以考虑采用Session复制技术做群集，必要时用专用的光纤网卡和光纤交换机，这样应该可以支撑较多节点。

weblogic 的群集session复制可以控制在“主、从”两个节点间进行，占用带宽较小，可以参照其实现类似的session复制。

我是指client保存的clone1的session id不见了
（我还不至于要讨论session什么原理，被人看小了）
client保存的只有一个session id，那是clone1的还是clone2的呢？
如果load balance突然改了clone呢？

我是说，我们用jk Sticky session来解决这个问题的
请问你的load balance方案是怎么解决的？

如果你退一步说还是完全不用session好了
我就觉得这个方案还可以接受

你理解错了，robbin用来保存用户id的cookie不是tomcat存sessionid的那个cookie。
第一次访问clone1，没有登录，要求登录，我们自己生成存用户id的cookie（cookie1），同时tomcat会生成session1，sessionid存在cookie2中，同时我们自己在session1中setAttribute("userInfo",userInfo)。
然后访问clone2，tomcat自动生成session2，sessionid存在cookie3中，我们自己getAttribute("userInfo")读不到值，但是能读到存userId的cookie1，因此根据userId查询用户信息，然后在session2上setAttribute("userInfo",userInfo)。
这个时候，浏览器有两个tomcat的session，同时还有我们自己存userId的cookie。
再访问clone1的时候直接得到session1了，怎么会不停的创建呢？

这是废话，所有用cookie保存sessionid的系统（基本上所有的系统）都是这样的。
问题在于，通常情况下，我们让tomcat自己管理session，sessionid是随机生成的，session超时以后就不再有效，而这里的这个cookie是永久有效的。
所有生成永久有效cookie的方式我认为都是有不安全的。
想到google我想起一个办法，google可以让你记住用户名自动登录，但是只有效两个星期。也就是说，最多两个星期以后就会更换加密密钥。
那么用robbin的方式也可以每天凌晨0点更换一个密钥加密userId。每个tomcat同时有两个密钥，昨天的和今天的，保持两个密钥是考虑到session存在的时间跨越一天的情况。每个userId的cookie过来先用昨天的密钥解（可能是昨天23:55生成的，但是现在时间是今天0:05），不行就用今天的密钥解。
这样每个cookie最多有效两天。算是解决了永久有效的问题，麻烦之处在于要在tomcat之间同步密钥。

acegi生成的自动登陆cookie:
username + ":" + expiryTime + ":" + Md5Hex(username + ":" + expiryTime + ":" + password + ":" + key)

似乎从Cluster的讨论演变成了SSO......

其实PHP就可以承受非常大的访问量，这点上不比Java差，用Squid + Apache + PHP + MySQL就可以具有非常高的性能。

而且用Squid之后可以很好的提升站点的性能，用反向代理比纯粹的Request转发具有更好的性能，前者具有自己的缓存机制，把静态数据的缓存做在这一层具有更好的性能。

SSO方面用过CAS，配置和实现都非常简单易用了，可以说比自己写Cookies还容易。对于Session的复制方面，如果可能的话，还是采用分布式缓存机制来做，比存数据库和各服务器互相复制的代价低。

没理解。
按照robbin的方案，浏览器端是不知道访问了clone1还是clone2的，而且部署在clone1/clone2上的程序也不知道自己是部属在哪个节点上的,而且，这个程序也不应该为了群集而作特别的处理。
另外，浏览器得到的域名都是前端分发请求的那个服务器的域名。这样，实际上这些cookie都保存在一个cookie文件(文件名应当是域名)里面，而且，因为tomcat的sessionid用的是同一个名字，好像都是jsessionid吧，并且cookie的域名和路径也必然是一样的，按照RFC2109

....
4.3.3 Cookie Management
If a user agent receives a Set-Cookie response header whose NAME is
the same as a pre-existing cookie, and whose Domain and Path
attribute values exactly (string); match those of a pre-existing
cookie, the new cookie supersedes the old. However, if the Set-
Cookie has a value for Max-Age of zero, the (old and new); cookie is
discarded. Otherwise cookies accumulate until they expire (resources
permitting);, at which time they are discarded.
....

第一次从clone1跳到clone2的时候，就会把cookie里面的jsessionid从clone1的换成clone2的。然后再跳回去的时候，因为不可能根据clone2的sessionid从clone1里面取出session来，所以只能新生成一个session,然后从cookie里面取出userid，从数据库里面取出userinfo.
这样，就不停的在两个clone之间跳舞了。还不如不把userinfo保存在session里面，每次直接在数据库中取好了。

如果要在session里面放东西，那么session的同步复制问题肯定不能避免。还是不在session里搞东西的好。不过那样一来，代价就有点大了，就是说为了群集而修改了程序模型。
最好是httpsession可以提供一个缓存插口.........

这个帖子是有些跑题，要不拆贴了吧，我觉得跑题的讨论还是有意义的


我弄错了，好像是有问题。
两个tomcat会生成相同的cookie，域名，路径都相同，cookie的名字也一样


这是个不错的主意，比我想出来的办法好。不过我不明白要password做什么
userName+对称加密的过期时间
就应该可以了