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

自动登陆的时候当然要检查password啦，而且如果cookie被盗用，我把password改掉那这个cookie就不能用了

你是这个意思啊，我还在想就算cookie被盗用，反正过了cookie值中指定的过期时间就不能用了。
有道理

为什么session1保存在cookie2
而session2保存在cookie3呢
真奇怪

用户不知道clone1和clone2的存在的

用cookie来保存用户ID，确实需要做一些加密的处理，当然策略有很多种，我想这个不是什么问题。

今天我请教了一个运营过中国某著名大型互联网站的资深专家，他说，大型群集应用，session都是集中保存的，他们以前就是专门用C写了一个Session Server，所有的AppServer都通过TCP连接到Session Sever来取得session。而类似JBoss Cache这种非集中式，在实例间进行同步的Cache性能是没有办法和上面相比的。

所以这个争论，我想也许可以下个初步的定论了，那就是大容量网站部署方案应该采用集中式的Cache Server，例如memcached这种，而放弃session 复制的方案。

memcache应该不是集中式的cache server吧，只能算是逻辑上的集中，物理上是分布的.
如果整个架构中只有一个单点故障点，那么可以采用技术手段进行几乎无限的加固，但像memcache这样的分布式缓存，加固的代价是很大的。
但是，从无限可扩充性而言，集中式的session存储并不具备这个特点。只能说是一个大容量站点的可行解决方案之一。性能并不会比某些方式的多级缓存会高。

纸上谈兵

集中式的session Server如何保证高可用？一旦这个server down掉，所有的应用都完了，整个就是集群的死穴。正因如此，我们最终选择的是数据库存储session，多个cache server并存的方案。

down就down了呗，有什么大不了的。打个比方，你用Hibernate二级缓存跑的应用程序正常，我现在disable二级缓存，难道你的应用就完蛋了？如果出现这种现象，只能说明你Cache的用法根本就是错误的。down无非就意味着拿不到缓存，换句话说，就相当于缓存没有命中而已，你需要直接从数据库里面取用户信息，仅此而已。应用程序该跑照跑，就是速度慢点，数据库压力大点。

可以写一个程序监控memcached(我不认为有这种必要，如果非要这样做的话)，如果memcached程序down掉，再把它重新启动起来就OK了。在这种过程中，应用程序利用cookie从memecached里面取得该用户的信息，如果memcached宕机，那么应用程序取到不到用户信息，自然转而从数据库里面取得用户信息和填充memcached(但是填充失败)，随后memcached被重新启动起来，后续的请求，应用程序再从memcached里面取用户信息，但是没有，于是从数据库取用户信息和填充memcached，这之后，一切恢复正常。

cache他就是cache，不要把cache当数据库来用，cache里面放的就是数据库信息的缓存，减少数据库访问的次数和压力的(有没有cache只会影响数据库负载，但是不会影响到应用程序的正确性)。如果非要把cache当做数据库来 用，那cache down了影响到了整个应用，只能是自找的。

robbin转移话题了。sorry,我这里表述有问题，并不是cache server。而是session server。
robbin的原话是“大型群集应用，session都是集中保存的”，“所有的AppServer都通过TCP连接到Session Sever来取得session”。说的是session服务器，而不是cache服务器。cache没了当然没关系。可是我session集中保存的话，session Server Down掉了，应用还怎么通过TCP连？

session server宕机就宕机呗。应用代码是连不上session server了，但是并不会阻塞在连接上，而是很短的时间就超时断掉连接，然后继续往下执行了，接着就访问数据库取用户信息了。