限时领|《AI 百问百答》专栏课+实体书(包邮)! 了解详情
写点什么

JBoss Cache 分布式缓存:Manik Surtani 访谈

  • 2008-06-23
  • 本文字数:3565 字

    阅读完需:约 12 分钟

JBoss Cache 是针对 Java 应用的企业级集群解决方案,其目的是通过缓存需要频繁访问的 Java 对象,提高应用的可用性并大幅度提升应用的整体性能。InfoQ 编辑就此对该项目的领头人 Manik Surtani 做了一次专访。

Manik,您能否首先跟大家讲一下在您所接触或者了解的客户中,大部分人都是怎样运用 JBoss Cache 的?缓存能带来哪些优点?尤其是在高度的可用性方面,缓存带来了怎样的进步?

从持续存储、尤其是数据库中读取数据需要付出昂贵的代价。而且,数据库在伸缩性方面也是臭名昭著(或者不便宜),当你想要扩展前端或增加更多客户端时,这个弊端显然就成了障碍。另一方面,CPU 和内存的价格越来越便宜,这意味着更多的人可以负担得起架设高可用系统所需的成本。“本站正在维护中”的暂停服务方式都应当成为历史。像 JBoss Cache 这样的分布式缓存扮演的是一个处于应用服务前端和数据库间的中间层的角色,提供对持久性数据状态在内存中的快速访问。JBoss Cache 能够确保缓存中的数据状态和数据库中的状态一致、及时更新数据状态、并且保证 JVM 不会出现堆溢出问题。

JBoss Cache 和其它一些开源项目,例如 Hibernate 和 JBoss Seam 等的集成情况怎样?

一些开源项目确实用到了 JBoss Cache。Hibernate(以及 JBoss Application Server 的 EJB3 实现)使用 JBoss Cache 来存储从数据库后端读取的实体数据,这样一来在调用实体时就不需要每次都连接到数据库去查找。我这样说纯粹只是一个简单的概括,Hibernate 运用分布式缓存的实际操作其实更复杂。Seam 也通过分布式缓存来缓存生成 JSF 页面元素,从而改善那些页面或者页面元素生成速度比较缓慢的站点的伸缩性。

另外还有一些开源项目,如 Lucene、Hibernate Search、GridGain、JBoss 应用服务器的 HTTP Session 集群和集群的单点登录(Single Sign-On)代码等都用到了 JBoss Cache。

JBoss Cache 提供两种缓存方式:核心缓存和 POJO 缓存。您是否能给我们概括一下这两者主要区别在哪里?

核心缓存会直接把您传递给它的数据存储在一个树型结构中。键/值对被存储在树的节点上,出于复制或持续性的需要它们都被序列化了。POJO 缓存则采用比较复杂的机制——利用字节码编织来内省(introspecting)用户类,并向用户类的域添加侦听器,一旦域值有任何变化,侦听器会立刻通知缓存。例如,如果要在 POJO 缓存中存储一个庞大、复杂的对象,会导致 POJO 缓存内省对象的字节码,最终只把该对象的原始域存储到树结构中。一旦域值有所变化,缓存只复制这个改变了的域值而不会去复制整个用户类,这是高效的细粒度复制。

当然还有一些其它的不同之处,但最主要的区别还是我刚才讲的。

细粒度复制定然会导致 POJO 缓存和核心缓存间在性能方面巨大的差异。您有没有对两者之间差异做过评估呢?

这类评估很大程度上决定于系统配置,如果只是做一般评估没多大意义。在缓存面对庞大、复杂的对象的时候,细粒度复制确实有助于提高性能。但如果只是用它来存储一些 String 的话,细粒度复制就没有什么特别价值。类似地,对简单的用户对象运用 POJO 缓存——比方说一个只拥有两个 String 域的 Person 类,与其说对性能有什么帮助,倒不如说它是浪费开销。这就是为什么我一直建议大家依赖于用例编写基准测试来做比较。我们开发了一个框架在不同缓存和不同配置情况下进行基准测试——开发这个框架主要还是为了方便我们内部比较不同版本的 JBoss Cache 之间的差异——但我们也提供该框架的下载,大家可以对它进行扩展,使用自定义的对象类型和访问模式来重新编写自定义测试。

你们如何管理引用完整性(referential integrity),尤其是 POJO 缓存?

如果你指的是对象的引用,那你刚好点到了之所以引进字节码编织的原因。我们针对 POJO 添加了拦截器并在缓存内容中插入了引用域。

对于用户来说,为什么要选择本地缓存,而不用 HashMap 呢?

很多人认为 Map 是考虑缓存的出发点(实际上,JSR-107 JCACHE 专家组曾经在 Map 的基础上扩展实现 javax.cache.Cache)。尽管 Map 非常适合用来存储简单的键/值对,在缓存必需的其它特性上,它就难免有点黔驴技穷,比如内存管理(eviction)、钝化(passivation)和持续性、细粒度锁定模型(首先,HashMap 根本不是线程安全的;而 ConcurrentHashMap 采用的锁是粗粒度级的,它甚至不允许非阻塞用户或多用户从 map 中读取数据)等。而对于“合格的”缓存来说,它还需要具备一些“企业”特性,包括 JTA 兼容、附加侦听器等功能。Map 虽然是个好的起点,但如果需要实现或者管理我刚才提到的那些特性的话,选择缓存还是要比 Map 来得更合适一些。

分布式缓存中采用哪种锁定机制?和传统数据库中采用的是同一种机制吗?

JBoss Cache 采用传统的悲观锁(pessimistic locking)的方式,树结构中的每个节点对应一个锁。这些锁的隔离级别和数据库实施的隔离级别相同,允许多用户同时读取数据。我们也提供乐观锁定(optimistically lock)方式,这个方式则牵涉到数据版本、每个事务的副本维护、主要树结构提交的事务副本确认等等。在乐观锁定方式下,需要承载大量的数据读取请求的系统因此可以获得高度并发性。那些请求读取数据的用户不会因为并发数据库写入操作而受到阻塞。而且,乐观锁定方式还可以避免悲观锁定中有可能发生的死锁。

我们携带多版本并发控制(Multi Versioned Concurrency Control--MVCC)功能的 JBoss Cache 3.0.0 正在发布阶段,当前的开发任务非常重。大部分数据库系统都用到了多版本并发控制这种锁定方式,它为我们提供了最好的乐观锁定和悲观锁。由于我们的实现不会阻碍任何用户读取数据,因此在数据访问速度上较之前者也胜出百倍。在 MVCC 功能相对稳定之后,我们希望能把它设置为 JBoss Cache 默认的锁定机制。

您能否谈一下 JGroups 集成?

JBoss Cache 用 JGroups 作为组通信类库,用来侦测组成员和组建集群。我们也把 JGroups 作为一个信道,在其上我们实现了一个 RPC 机制与组中其它缓存进行通讯。由于 JGoups 的应用,JBoss Cache 获得了高度灵活性,并在网络协议和调整方面也极具扩展性。JBoss Cache 因此还使得缓存能够摆脱 LAN 集群的框框,能够穿透防火墙的限制并组建 WAN 集群等。

可以脱离 JBoss AS 单独使用缓存吗?

当然可以!很多人都误认为 JBoss Cache 一定得在 JBoss App Server 下才能使用,其实不然。JBoss Cache 可以在独立的 Java 程序中使用,也可以在 GUI 前端使用,还能在其它一些应用服务器中使用。我们只是把它捆绑在 JBoss App Server 中发布而已。

失败转移的关键是把数据复制到多个节点,在实际开发中有很多策略可供选择来复制数据。JBoss Cache 支持的是哪种复制模式呢?

目前,我们支持两种方式——全局复制(total replication——TR)和 buddy 复制(buddy replication——BR)。全局复制将状态复制给小组中的所有成员。这种方式能够帮助成员间共享数据状态,保证在失败转移时可以转移到小组中的任何一个成员,但它限制了系统的伸缩性。Buddy 复制则挑选特定成员担当备份数据的责任,数据状态相应地只会复制到这些特定节点上。也就是说直接转移到复制节点的失败转移效率非常高,但即使转移到任何非复制节点,失败转移也同样都顺利进行,因为数据状态会根据请求转移到相应的节点。BR 最好用于 session 密切相关(session affinity)的情况下,因为数据状态的代价可能很高,所以应该尽量仅仅在发生失败转移的时候调用它。

某些特定的构架中,点对点的节点复制方式会影响到系统的伸缩性。JBoss Cache 中有类似的问题存在吗?

没有。P2P 网络和小组通讯在使用 LAN 和 IP 多播的时候效率非常高,伸缩性很强。大多数现代网络设施都支持 IP 多播。但 P2P 数据复制中,由于每个节点都拥有整个系统的数据状态,系统伸缩性因此受到影响。我下面会对全局复制稍加评论。基于前面提到的原因,我们建议用户使用与 session 密切相关的 buddy 复制。 我们还在开发分区功能,这个功能能够帮助我们在保证伸缩性的前提下真正地把数据状态发送到各个数据组,而且不需要与 session 密切相关(session affinity)。希望这个功能的推出能够取代全局复制和 buddy 复制。

在缓存和集群方面,您对近期的发展状况有怎样的期望?JBoss Cache 将会如何去满足新的用户需求?

随着硬件越来越便宜、CPU 厂商在每块芯片上放置越来越多的内核,分布式缓存将会越来越重要。这无疑意味着需要更多的“虚拟”机,意味着数据库需要“竭尽全力”去管理高度的并发性,也意味着分布式缓存将会成为数据瓶颈(data bottleneck)最重要的解决方式之一。逐渐流行的数据网格和云计算也同样会推动分布式缓存的发展,无论是“云”还是网格的数据节点都需要访问和共享数据。分区和 MVCC 功能也将助 JBoss Cache 一臂之力,能够把集群伸缩性提高一个数量级。

察看英文原文: Distributed Caching with JBoss Cache: Q&A with Manik Surtani

2008-06-23 00:476877
用户头像

发布了 71 篇内容, 共 22.4 次阅读, 收获喜欢 3 次。

关注

评论

发布
暂无评论
发现更多内容

​交易所开发 PancakeSwap DeFi 成功的秘密:您的 DEX 发展蓝图

区块链软件开发推广运营

交易所开发 dapp开发 区块链开发 链游开发 NFT开发

如何确定Apache Kafka的大小和规模

互联网工科生

kafka

如何使用透明贴图实现火焰效果

3D建模设计

材质 纹理 贴图

如何为3D模型设置自发光材质?

3D建模设计

材质 纹理 贴图

第11期 | GPTSecurity周报

云起无垠

大模型在数据分析场景下的能力评测

Kyligence

数据分析 Kyligence Copilot

等保测评后还要花很多钱做等保整改吗?

行云管家

等保 等级保护 等保测评 等保2.0

挑战吧,HarmonyOS应用开发工程师

HarmonyOS开发者

HarmonyOS

多款国产操作系统安装数据库干货文档汇总(含Oracle/MySQL/国产数据库等)

墨天轮

MySQL 数据库 oracle 国产操作系统 麒麟软件

焕新升级!新一代云原生可观测平台

华为云原生团队

云计算 容器 云原生 边缘计算

HarmonyOS多音频播放并发政策及音频管理解析

HarmonyOS开发者

HarmonyOS

特权账号管理系统简述

尚思卓越

特权账号管理 特权账号 PAM

出海 SaaS 企业增长修炼手册2:Kyligence 落地 PLG 是如何避坑的?

Kyligence

指标管理 SaaS 增长

1024 有奖征名|来给矩阵起源办公室的新猫取名字呀~

MatrixOrigin

1024 MatrixOrigin MatrixOne

1024程序员节|是时候,展示真正的实力了!

Openlab_cosmoplat

1024 1024程序员节

协同发展,生态聚合丨1024程序员节暨「源聚一堂」开源技术沙龙(北京站)成功举办

开放原子开源基金会

关于数据库分片你需要知道的

遥遥知识库

Java 分布式数据库 后端 数据库分片 关于XX你应该知道的

如何区分特权账号管理系统PAM和堡垒机

尚思卓越

网络安全 堡垒机 特权账号管理

博睿动态|GOPS全球运维大会2023上海站即将开启!

博睿数据

可观测性

战略牵手OXY精英设计、朗生、MPE美亚,小度合作生态重构再迎重要时刻

新消费日报

如何制作二维码会议签到系统?

草料二维码

揭示Lombok的代码设计缺陷:探索封装问题

树上有只程序猿

lombok Java 开发

Op丨ARB链dapp代币合约质押项目系统开发

l8l259l3365

幸福里基于 Flink & Paimon 的流式数仓实践

字节跳动云原生计算

flink paimon

JBoss Cache分布式缓存:Manik Surtani访谈_Java_Dio Synodinos_InfoQ精选文章