J2EE集群讨论帖

web层次的集群方案讨论，看完javaeye相关的讨论，你会大概了解：

讨论帖：http://www.iteye.com/topic/20298

对于企业级系统由于访问量不是特别大，可以采用应用服务器得ejb容器本身得session复制，ejb负载平衡功能，但是这个上升到互联网级系统就不合适了，由于session复制里同步比较耗资源，使得他不在适合这种应用，里面说随着j2ee潮流得发展，不再使用ejb得均匀负载能力，及机群从业务层提到了web层，直接在web根据sna架构就做机群处理，不是放到业务层让ejb容器来做。

注意里面robbin的无共享架构（Share Nothing Architecture）SNA。
web层次的集群主要技术就是：负载均衡和http session的失败转移。
负载均衡不再多说，焦点在于http session的失败转移。各个节点的http session复制会极大的影响性能。如何避免，robbin提出保持每个节点的无状态性，不再使用Session来保持全局状态。用户标示从cookie取得，假设不使用分布式Cache，session直接放在数据库中。他推荐了memcached作为分布式Cache，这样在从数据库读取session时中间又隔了一层Cache来提高性能。
大致的方法是这样：用户登陆的时候给他一个cookie，存放userId，同时给这个用户分配一个Session，存放user对象，然后把这个session保存到数据库和分布式 Cache里。黏性会话。写一个filter或者 webwork拦截器对用户请求进行拦截，如果他有cookie，但是session里面没有user对象，说明前一个节点down掉了，就根据 cookie里面的userId查数据库或者是分布式 Cache获得先前保存的session，把原先的session复制到他的新session里面。这样各个节点间的 session就不用复制，因为 session是没有状态的。我们的程序对使用session不受影响，只是session里的对象要可序列化，当改变session里的对象时需要同步到cache和数据库。当然，效率的原因，session里面东西越少越好，越稳定越好。
谁有这方面的经验？

 

在robbin和charon还有争论得问题就是缓存机制，

robbin说memcache好 应为他是共享式cache，通过网络访问。

而charon说warmcache好应为它是采用得本地cache，它采用本地存储，速度快。下面引用charon得话

==================================================================================

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命中率,当然要付出代价.

===================================================================================

在这里我们知道jbosscache和oscache也是用本体cache只不过同步方法不一样。robbin认为本地cache同步开销太大，而charon认为共享cache网络访问太慢，注意共享cache得实现也可以用集群，相对本地cache它只是逻辑上得集中。当然这里还提到一种二层缓存本地cache做一级，网络共享cache做二级。

而其中得session和cache并没有关系，他们得目的是不同得，cache是缓存提高效率，session是存放一些回话状态。这里联系到一起只是恰好是用cache存放得session而已。所以里面讨论得时候有时候就把两个概念放到一起了。

根据讨论得内容和robbin据的很多大网站得例子，可以认为对于互联网应用，要考虑大负载抗压能力，最好选用共享cache，集中管理共享信息（如session等）。主要是使系统满足sna结构，使得线程不需要做同步处理，这样就可以无限扩展节点，来提高效率。而对于一般企业应用则可以忽律同步cache时得损失。