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 接口。
活动推荐:
2023年9月3-5日,「QCon全球软件开发大会·北京站」 将在北京•富力万丽酒店举办。此次大会以「启航·AIGC软件工程变革」为主题,策划了大前端融合提效、大模型应用落地、面向 AI 的存储、AIGC 浪潮下的研发效能提升、LLMOps、异构算力、微服务架构治理、业务安全技术、构建未来软件的编程语言、FinOps 等近30个精彩专题。咨询购票可联系票务经理 18514549229(微信同手机号)。
评论