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

这个就成了系统稳定性问题了。
放到数据库，数据库也是一样会down的。
大不了做Session Server集群，热备。

用数据库保存Session和一个独立的Session Server没有本质区别啊。

disable掉二级缓存,hibernate是知道的. 但是,系统失效和disable不是一个概念上的事情.


服务器倒下的时候很容易处理的，memcache自个也有办法(怎么实现的我不知道，看起来像个短板)：

If a host goes down, the API re-maps that dead host's requests onto the servers that are available.

不会出现你说的写不进的情况
但是，要是碰到过那种服务器假死不死的情况，那就88了. 我所碰到过的系统失效情况中，假死的远比直接down的多得多。这个时候应用就会处于缓存颠簸状态，对缓存的依赖性越高，就越受影响。
而且，cache的收益是可以根据加速比和命中率计算出来的，如果命中率低于计算值，cache是没意义的。而在通路或者系统堵塞状态下，就根本没有命中率的说法了。而要考虑的则是有效访问率了,如果有效访问率是20%,那么命中率再高也没用.



这个缓存和本地的几级缓存只有名称上相似性。在本地缓存中查找得到有或者没有的结果是迅捷的，但即便如此，有一些实现也采用了竞争性手段，同时触发对缓存和下级存储的并发访问。但是，把使用本地缓存的方式用到memcache这种实现架构的网络缓存上，那是一个非常似是而非的做法。
而透过网络的访问的可用性是性能之外的一个非常重要的因素. 一个稳定的可预测的性能提升远比只在正常情况下的性能提升意义更大.  本地cache硬件失效的可能性可以忽略不计,系统崩溃的影响也可以不计,毕竟,系统都崩溃了,cache还有没有效根本就没意义. 而memcache这种方式,网络堵塞/目标服务器失效的因素是不得不考虑的, 尤其是你要做到透明的水平扩展的时候.

其实，分布式Cache，还是采用透明一些的方案，比如swarmcache. 它的性能是可预期的，失效影响是局部的，动态扩展对现有应用是没有性能影响的(memcache节点的动态扩展需要调整api的reinit)。
我就不理解，memcache除了性能上好看一点以外，还有什么别的好。和别的分布式cache相比，它的实现层次太低，需要再做几层包装之后才能实现性能提升的稳定性,或者说是兼顾可用性的性能提升.

数据库宕掉session在恢复后是可以取回来的,而内存里的session,没了就没了,就这个区别,除非有其他的持续化方式保存了session.

这有个前提,就是你的session里面只能存放在整个session存续期间不变的,而且可以从数据库取回的信息. 这个时候,session其实就是一个加速数据库访问的缓存.
这个时候,还不如不使用session, 而直接用某些缓存产品的做法.然后把所有动态的东西都放到cookie里面去.

说你是纸上谈兵，你还不信。别人五年运营日访问千万级PV的人告诉我用集中式session server是最有效的，而本地cache进行instance级别同步是low performance的。你就陶醉在你的纸面上吧。

最近如果有空，我会做一个memcached和JBoss Cache两种方案的performance test。你有兴趣也可以自己试试看，别光练嘴皮子。

就是这么回事。根本就不用Java的HTTPSession。

hehe.不要着急么. 谁说过除了memcache,别的分布式cache都是同步复制的? 不要看到jbosscache和memcache就觉得全世界的cache就这两种类型.OSCache和SwarmCache在集群状态下都不属于同步复制种类的,所以性能很难说会比那个memcache差,对于保持连接的频繁访问的用户而言,性能很有可能会超过memcache(如果有这几种cache命中和不命中时的访问开销,这个门槛值实际上可以计算出来).

而且,前面不是有个哥们说过了,session server和cache层根本就不是一个东西. 此外,我觉得你根本没有明白集中和分布的区别. 把一个集中式session服务器的案例(姑且认为它相当于一个cache)作为分布式缓存的优点的证据,好像逻辑上有点问题. 退一万步讲, 那个千万级PV,它跟session的关系应该看跑得应用吧,如果想说明session server的牛X, 得拿并发session数和session的每秒访问量说话


当然,欢迎用事实证据说话,可以测试一下到底有多少性能增长.搞个3-5台服务器,先看一下正常情况下的响应速度和并发用户数的关系,然后再把某台搞成假死,看看有什么变化,最后看看动态添加新服务器的性能影响和增长. 当然,测试用例设计得最好贴近web使用方式一点. 不过我建议不要看jbosscache了,就找那个swarm cache作为对照吧. 把jbosscache和memcache比本来就是个错误,虽然都叫cache,但是功能层次上差好几个级别呢.
在这个之前,好像大家都是纸上谈兵啊. 没啥区别. 难道你没发现? 只不过有些东西,不用做也知道,就比如9+6的加法,不需要把脚趾头伸出来就能够算对. 而且,这个不叫用嘴皮子,叫用脑子. hehe

那不就结了. 这种应用天生就可以水平扩展的.没分歧啊

你连Cache同步和同步复制这两个风牛马不相及的概念也能混为一谈。你还是先看看Cache入门资料吧。

看你口口声声分布式Cache，你知道swarmcache是用什么方式实现的吗？你又了解JBossCache是怎么实现的吗？我建议你研究一下这两个Cache，特别是要了解一下JBossCache有什么独到之处，我为什么不提swarmcache，而说JBossCache，不是没有理由的，这里我先卖个关子，看你对这两个Cache缺乏起码的了解，先花点时间了解吧。连这都搞不清楚就别在跟贴制造信息垃圾了。

robbin少安毋躁，既然欢迎大家挑刺，就不能怪我们“扎”你了。

对这个话题感兴趣，想把其中的一些问题弄清楚。robbin引入memcached的目的是“memcached可以充当全局共享变量的通用存取地址”，不是很明白这个说的“全局共享变量”是什么。从各人的讨论来看，似乎是要用memcached来实现“高效的集群容错机制”，如果不是这个目的，下面的讨论就有些跑题了，呵呵。

举个例子，一个网上商场WebApp，服务端的状态信息起码有两种，一个是“用户对象”——表示用户已经登录以及相关用户信息，创建后基本不再变化；另外一个是“购物车”——存放用户购物情况，是个不断变化的对象。一般来说HttpSession中存放的就是这些信息，集群的容错机制必须保证能够在服务器之间共享这些状态信息。robbin的意思是如何存放这些状态呢。

如果所有状态信息都只是存放在memcached中，感觉这样像你那个哥们说的“集中式session server”，那么这个就是系统的“单点故障”点。必须有机制保证memcached自身的可靠性，不夸张地说它是永远不能down掉的。

但是看到你前面的讨论，提到memcached“down就down了呗，有什么大不了的”，似乎这些状态信息是存放在数据库，memcached只是一个“缓存”，存放数据库中读取的信息。但是“购物车”是快速变化的，如何解决“缓存”和数据库的同步的这个问题呢？

或者是“购物车”直接从数据库读取，memcached只是存放很少变化的“用户对象”缓存。如果这样的话，就看不出采用memcached的好处了，我还不如直接采用一个单jvm的cache工具缓存“用户对象”，这样性能更高，无需跨网络读取。反正容错是由数据库保证的。

这就是我目前对这个讨论看不明白的地方，robbin所谓的“全局共享变量”指的是什么？因为我也很关心“高效地实现集群的容错机制”这个话题，想知道memcached是否有所帮助。

其实这里大家不采用HttpSession的原因，主要是担心HttpSession需要在集群的全部节点进行复制，严重影响性能。建议看看WebLogic Server的“Understanding HTTP Session State Replication”，它对每个用户分配“主”“从”两台AppServer，HttpSession只会在两台AppServer之间复制，效率是非常高的，相对其它方案，程序读取状态信息时候无需跨跃网络、数据库。只有在“主”“从”两台机器同时down掉的情况下，容错机制才失效，可靠性略低于全部机器down掉才实效的方案，但也是相当高的。而且开发人员可以直接用HttpSession，最为灵活，因为你可能会用到其他依赖于HttpSession的第三方工具。

我觉得WebLogic Server的这种机制非常精巧，同时考虑到可靠性和性能，如果可以在每台机器上启动memcached，它们之间也有主从的复制关系，倒是一个很不错的通用方案（可以用在php等其他语言）。