1、独立缓存（Standalone Ehcache）：这样的缓存应用节点都是独立的，互相不通信。
2、分布式缓存（Distributed Ehcache）：数据存储在Terracotta的服务器阵列（Terracotta Server Array，TSA）中，但是最近使用的数据，可以存储在各个应用节点中。
逻辑视角：
L1缓存就在各个应用节点上，而L2缓存则放在Cache Server阵列中。
组网视角：
模型存储视角：
L1级缓存是没有持久化存储的。另外，从缓存数据量上看，server端远大于应用节点。
3、复制式缓存（Replicated Ehcache）：缓存数据时同时存放在多个应用节点的，数据复制和失效的事件以同步或者异步的形式在各个集群节点间传播。上述事件到来时，会阻塞写线程的操作。在这种模式下，只有弱一致性模型。
它有如下几种事件传播机制：RMI、JGroups、JMS和Cache Server。
RMI模式下，所有节点全部对等：
JGroup模式：可以配置单播或者多播，协议栈和配置都非常灵活。 <cacheManagerPeerProviderFactory
class="net.sf.ehcache.distribution.jgroups.JGroupsCacheManagerPeerProviderFactory"
properties="connect=UDP(mcast_addr=231.12.21.132;mcast_port=45566;):PING:
MERGE2:FD_SOCK:VERIFY_SUSPECT:pbcast.NAKACK:UNICAST:pbcast.STABLE:FRAG:pbcast.GMS"
propertySeparator="::"
/> JMS模式：这种模式的核心就是一个消息队列，每个应用节点都订阅预先定义好的主题，同时，节点有元素更新时，也会发布更新元素到主题中去。JMS规范实现者上，Open MQ和Active MQ这两个，Ehcache的兼容性都已经测试过。
Cache Server模式：这种模式下存在主从节点，通信可以通过RESTful的API或者SOAP。
无论上面哪个模式，更新事件又可以分为updateViaCopy或updateViaInvalidate，后者只是发送一个过期消息，效率要高得多。
复制式缓存容易出现数据不一致的问题，如果这成为一个问题，可以考虑使用数据同步分发的机制。
即便不采用分布式缓存和复制式缓存，依然会出现一些不好的行为，比如：
缓存漂移（Cache Drift）：每个应用节点只管理自己的缓存，在更新某个节点的时候，不会影响到其他的节点，这样数据之间可能就不同步了。这在web会话数据缓存中情况尤甚。
数据库瓶颈（Database Bottlenecks ）：对于单实例的应用来说，缓存可以保护数据库的读风暴；但是，在集群的环境下，每一个应用节点都要定期保持数据最新，节点越多，要维持这样的情况对数据库的开销也越大。