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非常有意义。