Remote Cache, Transaction

最新推荐文章于 2023-09-24 23:53:16 发布

最新推荐文章于 2023-09-24 23:53:16 发布 · 605 阅读

文章标签：

#Cache #memcached #网络应用 #JPA #网络协议

Cache 专栏收录该内容

5 篇文章

订阅专栏

本文探讨了RemoteCache与LocalCache的区别，介绍了ClusterCache的工作原理及优势，并讨论了在ORM中的应用，包括事务处理策略和Cache的一致性问题。

1. Remote Cache

Remote Cache 是对应于Local Cache来说的。
Key or Value 需要序列化，需要内部网络通信。

Remote Cache 可分为中心Cache，和Cluster Cache。

Cluster Cache的一个要点是，只是remove的时候，传播 invalidate事件。
这样只需要在 update 的时候，进行传播。
好处是，读取的时候，比起中心cache，就少了一布内部网络通信。
坏处是，命中率比memcache低，因为memory是分开的。update多的时候，需要传播 remove/invalidate事件。

2. ORM, Transaction.
Cache通常用于ORM中。人们通常考虑Cache 和 DB 的同步，甚至事务。其实不用考虑到那么细粒度。
比如，Cache 的 Read Committed 没有必要保证，可以允许一定的read committed。
原因很简单。即使是保证了read commited隔离级别的db 操作，都无法解决数据库事务并发冲突问题。只能依靠应用程序层的悲观锁和乐观锁来解决。
所以，严格保证Cache 的 Read Committed 没有意义。

至于Cache 和 DB Transaction 是否应该成为一个原子操作，统一为一个Transaction。这也只是一个概念上的事情。就看时间点如何纪录。
而且，处于和上面同样的道理，保证这个transaction也没有意义.

3. My Idea.
lightor中，我是这么处理Cache的。

首先，根本不考虑 Read Commited。甚至采用 Copy On Write 这样的方式，鼓励 Read Dirty, 增加命中率。

其次，cache模型非常简单，比map还要简单，根本不考虑时间锁之类的东西。
cluster mode中只需要传播一个 remove 事件。这个可以用底层open source cache 的实现直接支持。

再次，为了增强对 remote cache （中心cache, cluster cache）的支持，cache 实现中，都有大粒度调用方式的支持。这些支持是任何cache都没有考虑的。
比如，get(key)，remove(key)，
如果这个key，是一个 object[], collection，那么返回值也是一个collection。
这样，如果远程访问这个cache 的时候，一次通信可以完成很多工作。避免多次通信。
putAll( pairs ) 方法也是这样。
这种大粒度调用方式的实现，对于实现关联Cache非常有意义。