精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2007-02-02
项目中需要用jbosscache解决分布式cache问题。我们想实现如下cache模式: 假设集群有2个节点,分别是node1和node2,我们要缓存的对象叫test.table1, 1、node1 检索test.table1的id为“id1”的值, 这时,由于缓存中没有相应数据,它会先访问数据库,然后缓存在本地,即调用类似treecache.put("/test/table1","id1" "value1")的语法保存在缓存中;这时其他节点的cache不受影响;下次node1再次访问该值,就会从缓存中取到该值。 2、同样,node2访问test.table1的id为“id1”的值,这时缓存中也没有该值,同样访问数据库,然后放到缓存中。 3、node1修改了test.table1的id为“id1”的值,这时,应该调用treecache的remove方法,将改对象清除出缓存,并向node2发送invalidation通知,使node2也清除相应的对象。 我们在考察了jbosscache支持的4种同布方法(REPL_ASYNC,REPL_SYNC,INVALIDATION_ASYNC,INVALIDATION_SYNC)后,觉得INVALIDATION_SYNC这种方式满足我们的需求。即各个节点都单独保留自己的cache数据,在查询数据库后,保存在本地的缓存中,这时不同步数据到其他节点。但当某个节点修改了缓存中的数据,这时需要发送 invalidation消息到其他节点,使得其他节点删除相应的缓存。
在通过1个下午的测试后,结果和我们设想的有很大出入,以下就是测试结果: 1.node1 加入新的数据 /test1,正常,node2相应的缓存没有变化; 2.node2加入新的数据/test1,奇怪的事情发生了,node1的 /test1节点不见了,我看日志,确认它受到了Eviction消息,即数据失效消息; 3、同样,我们再次在node1加入数据/test1,结果,node2的/test1数据不见了,同样是收到了相应的数据失效消息。
以上现象,会导致node1到数据库取数据,更新缓存,node2的缓存中相应数据会因此失效,下次node2取同样的数据时,由于数据失效,还要去数据库取,再次更新node2缓存后,此时,node1将收到缓存失效消息。这样循环往复,实际上缓存一点也没有起到分布式的作用。 实际上,应该是node1和node2分别保存自己的缓存,只有在我们更新的数据或删除了数据时,这时才能发送invalidation消息,其他节点清除相应缓存数据。
有没有朋友用过INVALIDATION模式,帮我解答下这个问题,谢谢!
声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2007-02-03
没用过 jbosscache ,
前几天在测试oscache的demo,oscache使用 jgroups就是你所描述的cache模式的. |
|
返回顶楼 | |
发表时间:2007-02-03
codeutil 写道 没用过 jbosscache , jbosscache内部也用的jgroups,但这种模式我总觉得不合理,我理解应该remove的时候才发invalidation消息,put的时候只是本地的,不发同步消息。
前几天在测试oscache的demo,oscache使用 jgroups就是你所描述的cache模式的. 不知道你们是怎么用的,能否解释下? |
|
返回顶楼 | |
发表时间:2007-02-05
有没有朋友用过INVALIDATION模式呢?难道有其他配置参数吗?项目急需解决该问题,谢谢啦!
|
|
返回顶楼 | |
发表时间:2007-02-05
找到了一些线索,搜索jbosscache的论坛,
http://jboss.org/index.html?module=bb&op=viewtopic&t=98149 ====================================================== Hi, Sorry for the slow response. For your use case where you need to maintain state across all servers, INVALIDATION will not work. You do need to use replication. Just to brush up on the concepts, invalidation will *remove* state on remote nodes if one node updates this state while replication will *update* this state on all remote nodes. Invalidation only makes sense if you use a *physical* cache loader (such as a database, file system or far cache) rather than the clustered cache loader, which relies on this state being available on remote cache nodes. Regarding your multicast issues, I'd recommend troubleshooting your network/JGroups stack first - Here's some literature that may help. Cheers, Manik _________________ Manik Surtani Project Lead, JBoss Cache JBoss, a division of Red Hat ========================================================= 他说INVALIDATION模式总是在本节点更新的时候,废除其他节点的信息。 但,还是没有解决我的问题。:-( |
|
返回顶楼 | |
发表时间:2007-02-22
首先简化node1为1,node2为2:
1、这样的cache方式肯定也是有用的,因为访问的序列不可能是 1-2-1-2-1-2-1-2 ....这样的方式, 应该是1-1-1-2-2-1-1-2-2-2-2-1等随机序列方式,那样jboss缓存是能发挥作用的。 2、就算完全是1-2-1-2-1这种规律间隔模式,如果是使用Hibernate,那么有基于session的一级缓存,很有可能数据是从一级缓存中读取的,还是节省了访问数据库的时间;再次之,数据库本身也有缓存,提取还是很快的。(基于这种方式,在jboss缓存之下还有一层缓存是一个较好的方法) 3、纯属个人猜测:每次put都更新远程缓存,能够避免更新数据后因为忘记remove treecache中的相应条目,而导致的cache不一致问题。 (其实我觉得put的时候不更新远程cache,remove treecache时再更新远程cache是没有问题,不知道jboss team最终为什么没使用这样的设计?) |
|
返回顶楼 | |
浏览 4368 次