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

hehe,前面那个贴居然被删了？我就再简单而且正式的说一下.
不过,在我的印象里面,有关分布式情况下的缓存一致性的话题,是不在一般的入门资料里面出现的.
简单的说,建议robbin去看看厚度超过300也的计算机体系结构教材,或者关于高性能计算的入门材料,可以大致了解一下.实际上,这些年在cache实践中用到的方法,应该说至少在10年前在高性能计算领域就已经成熟了.
这里主要是指的cache一致性问题. 有两个方面: (这里假设cache的后端存储是主存,cache的操作者是cpu)
1. 本地条件下的一致性: 可能有两个情况引发不一致. 一个是操作者对cache的写操作导致cache/后端存储的不一致, 另一个是其他设备对主存的写引发的 .
对应到hibernate缓存的情形,前面那种是hibernate的写操作,第二种是其他程序绕过hibernate写数据库
第一种情况下有两个策略来保证cache一致性,写直达法(Write-through)和写回法(Write-back),具体的含义就如名称,hibernate使用的应该是写直达法.但不论用哪种方法,写操作不命中时都又有别的处理方式,这个与话题无关,就不多说了.
第二种情况在高性能计算中,其实就是分布环境下的cache一致性. 而对于hibernate,则是一个死穴(不是说不能处理,而是时机和代价问题,所以在集成应用中,由hibernate缓存可能被别的系统写的数据是很危险的动作)

2. 多处理机条件下的cache一致性(对应于目前的集群分布情况)
处理起来的方法多了,大概有
a. 共享cache法. 禁止local cache. 这是memcache的做法. 但是相比多处理机情况下硬件实现的共享cache法,可靠性上差多了.
b. 写无效法(write-invalidate). 这个是指local cache更新局部cache时,除了用写直达法更新后端存储,还需要作废其他处理机的本地cache中的相关内容. swarmcache和oscache在集群环境下采用的就是这个办法
c. 播写法(write-update). 如名字所说.有更新时广播,同步复制(更新)到各个机器的local cache. JBossCache可以做到这一点
d. 目录表法.  简单的说就是有一张目录表表示某一项内容在各个节点缓存中是否存在和存在状态. 写的时候用这些信息来避免写操作. 我前面建议的(不知被谁删掉了),实际上是目录表法的一种改良. 采用两级缓存体系,第一级用swarmcache,第二级用memcache.
e. 不用local cache. 就比如直接访问网络/数据库了.
实际上b/c都属于监听同步协议,只不过写无效法中一个节点在更新一个变量后的瞬间的时候如果遭遇其他节点试图读这个变量,会导致读缺失而使流量爆增.实际上在网站的session数据的cache化中,这个问题是不存在的.所以前面一直建议robbin去了解一下这类情形的cache行为特征.而写更新协议的问题是播写到别的local cache的数据可能永远也不会使用,所以是先付出巨大代价,然后坐等收益的办法. 在多机系统中播写结果被使用的概率要大于在web集群的session缓存环境下, web环境下播写法当节点太多时实际上是非常难过的.

终结到一点,所谓的cache一致性,本质上都是指cache和后端存储的一致性.只不过在分布环境下,这种一致性变得困难一些.
而所谓的同步和同步复制只是实现手段而已. 播写法和写无效法都属于同步手段,但是只有播写法才是同步更新的. 同步保持的是一致性,而同步复制在保证一致性的同时,还试图保证cache命中率,当然要付出代价.

我看不出swarmcache有什么不好. hibernate照样不也有一个使用swarmcache的选择,难道都是假的?
在指责别人之前应该回过头去先了解一下别人在说什么. 不然会被PK得很难看的.对于一个10多年前的技术的翻版,背景知识比看代码要重要的多.
或者你能说说swarmcache不能够使用在你说指的这个环境下的理由? 反正我是没看出来. 没有必要拿着local环境下的有色眼镜去看分布环境的实际, 这两个环境需要考虑的问题差异还是比较大的.

稍微有点跑题，我简单说明一下我的观点：

基于我对多个大型企业应用tunning的经验证明，往session里面塞入过多信息是导致服务器内存溢出的主要原因。关于这个话题，在Java企业应用版有一个很长的讨论串，这里不再复述。

因此session应该仅仅放入标示用户ID的信息，所有其他信息都不应该往session里面放。而如果session里面仅仅放入用户ID，那么实际上用cookie也同样可以实现，因此采用cookie＋分布式Cache，是完全可以取代session的。而我现在设计和开发大型应用，就是必须要求不准用HTTPSession。因为一旦使用HTTPSession，就必须进行session复制，cluster节点之间不再是幂等的，随之而来的各种问题就复杂多了。

第二个问题是，分布式Cache里面应该放什么信息？应该放入只读的用户信息和权限信息，类似购物车这种信息不应该放入Cache里面，而应该放入cookie。

所以，结论就是Cache不是为了cluster容错的，而是为了减少对数据库的访问的，所以分布式Cache宕机不宕机本来就没所谓，这一点我上面阐述不知道有多少几遍了。而且令我非常吃惊的一点是，Cache的基本概念就是缓存数据，减少数据库访问的，它什么时候需要承担容错机制了？为什么大家连Cache究竟是干什么的现在都搞不清楚？


你可以想像你有5个cluster节点分布在三台机器上，这个时候memcached的好处就体现出来了。


WebLogic，WebSphere在大型企业应用中的群集我都亲自设计和部署过。说实话，我估计你们都没有真正在大型应用中做过这种方案的实施，所以多少有点纸上谈兵。我可以负责任的告诉大家，不管BEA/IBM怎么宣传，事实上，Session/Cache在JVM之间同步的开销比你们想像中要高出来很多。以至于我们当初在设计方案的时候，就尽量避免出现需要同步的数据，甚至把session放入数据库，也避免session内存复制。

我自己之前的疑问在于，类似memcached这种需要TCP通讯的集中式Cache是否性能会好，在极大容量互联网站，例如千万级PV情况下，是否能够支持的很好，现在有过来人告诉我，千万级别的互联网站他们就是采用这种方式，并被证明是一种非常有效的方式(Cache Server自行开发，不是memcached)。

企业应用的量级和互联网站的量级是不同的，也许企业应用用用JVM本地Cache复制性能还行，但是在互联网站级别，我严重怀疑这种方式的性能。既然有经验的人士以自己运营互联网站的经验告诉我这种方式是low performance的，我想这个问题我就不必在探究了。

看你粘贴大段计算机教材上面的文字就觉得好笑，什么时候你真的能够去下载和看看swarmcache和jbosscache的文档呢？而不是把时间浪费在这里高来高去的搞理论。

我不再卖关子，简单谈谈我对这两个Cache的看法：

swarmcache的定位是一个轻量级简单易用的分布式Cache，他的卖点在于简单，而不是性能，事实上只要你在底层使用JBoss的jgroups，都可以支持cache的分布式，连oscache都可以支持，也只是因为他也使用了jgroups。如果你为了追求性能，swarmcache绝对不应该是你的选择，这就是理由。另外一个比较重要的理由就是swarmcache最近一次发布的版本是2003年10月，对于一个沉寂了两年半的开源项目而言，几乎已经宣布它的死亡。

Hibernate不是Cache官方评测机构，它提供哪种Cache支持不能说明任何问题。

jboss cache有很多非常独到的地方，在我们比较关心的性能方面，jboss有一个非常值得大家关注的优点。常规的Cache在节点之间进行复制，必须要求Cache里面的对象实现序列化，而我们知道序列化是一种开销非常高的操作，密集的序列化操作对CPU和内存的消耗都很高。但是jboss在进行cache同步的时候，并没有采用这种序列化机制，而是自行实现一种对象在网络上面传输的机制，从而绕开了Cache同步的一大开销。这就是我上面卖的关子，看来charon真该好好看看jboss的文档，而不是去翻什么教科书。

现在memcached的Java client端也是采用序列化机制，我比较担心这个地方的性能，所以我想做一下相关的性能测试，有可能也想做一下jboss性能测试。当然最希望能够把jboss的对象同步方式代码抄过来改写memcached的Java client，这就最理想了。

我们这memcached被否了，用C做session server，要求用UDP连接session server，当然，这样做有一个重要原因是这方面有积累。只能有时间自己试试memcached了

用TCP有一大好处，client端可以开一个pool，从而避免了反复建立和断开socket端口的开销。我现在做法用spring bean写一个CacheService，一个init方法里面建立一个tcp pool，然后每个请求从pool里面拿连接进行操作。

BTW:最近很想把丢了很久的C语言再捡起来，这样我就可以自己尝试去改memcached和lighttpd的代码了。

socket建立和断开的开销不大吧？跟数据库的连接相比，算是很轻量级别的了

用UDP最主要的是编程比较麻烦的说

BTW:看了上面数页的讨论，其实大家提到session时，多数指的都是httpsession.
少用，最好是不用httpsession，其实大家都是认同的,只是如何去维护用户状态上有不同意见——广义上的session

这段话实际上是对你说的:

的一个注脚. 难道你了解了这些东西,还觉得分布式环境下本地cache的"同步"和"同步复制"是风马牛不相及? 这两个东西本身就是一体两面.



后面那个理由还勉强是,前面的就是@#!%$了.
上面那个帖子说得很清楚了,分布式系统中的本地cache关键在于它的同步策略. jgroup只是一个用于传送同步讯息的通讯工具,关键是通过通讯的内容.
我为什么看好swarmcache和memcache的性能对比,道理很简单,swarmcache在cache命中时访问的是本地存储,memcache需要通过网络访问.
而且,swarmcache同步开销因为不交换更新内容,比jbosscache的复制模式下少多了. 只不过初始加载的代价比较大,所以才需要测试,否则,连测试都是不必要的.

此外,至少从某种意义上说,hibernate官方是把swarmcache当作一个比较常用的cache实现的,否则提供支持干什么,为什么不先去提供memcache的实现?
而且,性能问题好像我只看到你的判断,但是没有任何证据,你的那个理由,我看起来就像是个结论.
swarmcache到底差在哪里,我是看不出来.
希望你能够从架构分析,或者性能测试上给我一个学习的机会?


jbosscache的功能点比另外几个强多了,这点我从来就没有否认过,而且,前面我记得是把它当作"牛刀"称呼的.
至于传输的时候是不是序列化,这个不是关键. 关键的因素在于传输什么东西.
如果采用播写法,需要把更新的内容传过去,那绝对是个大的通讯开销. 即便只有10%的写操作,在大量连接下,也是一个不可忽视的开销.
swarmcache是写无效的,牺牲可能的命中率来降低现实的通讯开销.


这个就不好说了,hehe. 我前面关于jbosscache的说法,都是它自己的文档或者一些使用者说的. 可不是我自己弄出来的.
至于教科书,只是抄一段给大家看而已,是有感于robbin你对cache同步和同步复制的认识而抄的.

robbin这个方案缺少个成功案例。（无调查语言）

两个要点：
用cookie解决session复制问题。
用独立进程的cache解决分布式cache引起的问题。

至于细节因为没人试过,就当假设.

http://www.danga.com/memcached/users.bml

LiveJournal(每天2000万PV)， Slashdot，WikiPedia ，SourceForge，。。。。。。

还有一些国内大型互联网站，不方便透露名字。

反而是类似JBossCache这种JVM Cache进行同步的方案尚且在大容量互联网应用中找不到一个可供参考的案例。