Mark，觉得有点难度哈

读写分离吧，remote cache 提供 read、write，其他本地 cache 只提供读。remote cache 同时需要支持分布式锁。

这种参考 CAP 理论吧，看是要 CP，还是 AP

恩。我当时回答的也主要都是从 CAP 理论来考虑的一些场景。
但是不知道还有没有其他的一些场景

分布式主要考虑两大点：
1、failover 接管
2、同步的延迟是否满足请求频次的需求
还有就是他这个 remote cache 的容量能否跟得上这个集群所有需要同步的 cache 的量，最简单的办法就是持续加压。

remote cache 听起来就像抓娃里面的 violate，保证各个节点都从主存（remote cache）中读数据，但 violate 并不能保证线程安全，同理这个 remote cache 应该也不能，所以楼主说的业务代码需要主动加锁保证一致性是很有必要的。

港真，分布式的设计本身就需要考虑测试方案，可测试实施起来可比代码写起来难多了，我被 ehcache 坑过一回，自己做的 cache 方案自己写代码、自己测试，都快测哭了，后来换 redis 单点主从热备方案了，连集群都没敢上，业务性能需求需要的强一致性导致项目组不再信任集群间同步的效率，尤其是有限流的云服务器上……半吊子看法，讲错勿怪~

操神，好优秀

简单的想法

这个问题太难了，感觉出题的人也不会知道这个水深水浅.
下面是自己的一些想法.

1. 单个 Server Cache 场景 - 最基本 cache 的功能

• cache 的读取
• cache 如果不在内容里面从数据库取，然后再放入 cache
• cache 过期，过期策略验证
• cache 的不同类型验证
• cache 超过内容容量 cache 策略

2. 分布式看 - 太难了，感觉问问题的人也不一定很懂

首先不知道这个地方的实现，总体可能有两种情况：

1. 都是直接访问 server 的 cache，remote cache 做同步分发，协调用
2. 先过 remote cache，server 的 cache 做类似二级缓存

但是不管怎么样如果是数据一致性，高可用的话有些事情一样都很难实现和验证,比如：

1. 数据一致性，这个缓存数据的要和实际最新数据一致，而且一个 server 端的 cache 更新了需要广播更新所有的 cache,还要保证时序性保证，先到 remote cache 的不代表他真的是先发生，网络，处理能力都可能有问题的，系统最后更新的表示最新的值，这个难呀
2. 可用性，如果一个 server 重启了，那么如果复制 cache 到这个 server，性能问题 如果 remote cache 挂了，怎么让 remote cache 的数据恢复正确，和实际情况一样
3. 如果不同 server 的时间都不一致，怎么保证数据一致性
4. 如果对 key 加锁的化，性能如何？如果没有 key 的话，怎么加锁？ 没有 key 是完全可能的，就是不在缓存里面，但是是去拿同一个东西，没法控制了？
5. 如果 server cache 的内存大小都不一致，怎么保证 cache 内容是一样的？

最后说这种功能,测试还是不要碰了，谁想的方案谁验证吧

很棒的回答啊，想得很全面～