您的位置:首页 > 其它

cache一致性问题

2009-02-25 15:00 260 查看
不过,在我的印象里面,有关分布式情况下的缓存一致性的话题,是不在一般的入门资料里面出现的.

简单的说,建议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和后端存储的一致性.只不过在分布环境下,这种一致性变得困难一些.

而所谓的同步和同步复制只是实现手段而已. 播写法和写无效法都属于同步手段,但是只有播写法才是同步复制的.
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: