使用 EhCache Server 部署 1TB 缓存

EhCache 小组的 Greg Luck 在 8 月初宣布了针对缓存的 SOAP 和 RESTful APIs 。正如文档所述：

Ehcache 现在已经有了一个 Cache Server，它以两种形式出现：适合大多数 Web 容器的 WAR 以及独立的服务器。Cache Server 有两种类型的 API：面向资源的 RESTful 以及 SOAP。这两种 API 都支持任何编程语言。

在随后的一个帖子中，Greg 简述了部署 1TB 缓存理论上的方式：

最大的 Ehcache 单实例在内存中可以缓存 20GB。最大的磁盘可以缓存 100GB。我们可以将节点整合在一起，这样缓存数据就可以跨越节点，以此获得更大的容量。将缓存 20GB 的 50 个节点整合在一起就是 1TB 了。

第一种、也是最简单的方式就是装配运行着 Ehcache Server 的几个节点，然后让客户端根据对象的 Hashcode 来决定使用哪个 Server：

String[] cacheservers = new String[]{"cacheserver0.company.com", "cacheserver1.company.com", "cacheserver2.company.com", "cacheserver3.company.com", "cacheserver4.company.com", "cacheserver5.company.com"};<br></br>Object key = "123231"; <br></br>int hash = Math.abs(key.hashCode()); <br></br>int cacheserverIndex = hash % cacheservers.length;<br></br>String cacheserver =cacheservers[cacheserverIndex];我们使用一个负载均衡器（load balancer）来支持冗余，每个节点运行两个 Ehcache Server 实例，通过使用现有的分布式缓存方案（RMI 或者 JGroups）支持节点之间的数据复制。在这种方式下，客户端依旧使用 Hashcode 来决定使用哪个 Server，但是现在我们可以在负载均衡器所分配的虚拟 IP 后透明地处理失败。

Greg 谈到的第三种方式就是转换职责以将请求路由给负载均衡器。

EhCache Server 的 RESTful 版基于 Jersey——JSR 311 参考实现。Jersey 的开发者之一 Paul Sandoz谈到了如何使用Jersey 的客户端API 以访问缓存来创建并得到一个示例XML 文档：

// retrieving a node<br></br>Node n = r.accept("application/xml").get(DOMSource.class).getNode();<br></br>// creating a node <br></br>String xmlDocument = "...";<br></br>Client c = Client.create(); <br></br>WebResource r = c.resource(http://localhost:8080/ehcache/rest/sampleCache2/2); <br></br>r.type("application/xml").put(xmlDocument);那么 RESTful 缓存适合于哪种场景呢？ James Webster 说已经有越来越多的大公司采取这种架构方式了：

我注意到一些投资银行所采取的架构模式就是一种分布式的内存缓冲，该缓存由 RESTful 的前端通过 HTTP 来访问，以得到市场数据（如股票价格、利率曲线，或者诸如表面波动和相互关系之类的引伸价值）和静态数据（如对等细节、结算拖欠）。我们可以“轻松”扩展该分布式缓存以容纳大量数据集，同时前端也允许用其他方式访问数据，只要客户端能访问 HTTP 就行。

正如 James 指出的那样，我们想要看看厂商（如 Oracle 和 Gigaspaces ）到底要花多久才能在其产品中支持 RESTful 接口。

查看英文原文： Deploying a 1 Terabyte Cache using EhCache Server