内容概要
JBoss缓存简介
JBoss Cache 是一个分布式的企业应用缓存，它的目的是为企业应用分布式和集群提供解决方案，通过缓存需要频繁访问的 Java 对象,提高应用的可用性并大幅度提升应用的整体性能。JBoss Cache是一个单独的产品，你可以单独使用或将其部署注册于中间件平台当作服务来使用。JBoss Cache也是一个Java类库，你也可以扩展将其整合到你的应用中使用。 一个典型的例子就是JBoss Cache在JBoss中的使用，JBoss中EJB集群、JMS集群、Web应用集群、JNDI集群等都是通过JBoss Cache完成的。
JBoss Cache 是一个事务性的复制缓存。因为多个 JBoss Cache 实例可以分布运行(可以在同一主机或不同主机上的相同或不同的 JVM 里)且数据在整个组群里进行复制,所以称之为复制缓存。因为用户可以配置 JTA 兼容的事务管理者并使缓存操作事务化,所以它是事务性的缓存。请注意,这个缓存也可以不进行任何复制,也就是以本地模式运行。
JBoss Cache 是一个开源的产品，有一个开发人员和贡献者活跃参与的社区。JBoss Cache 有两个版本:Core 和 POJO 版本。Core 库(使用org.jboss.cache.Cache 接口)是在树型结构里组织数据和处理锁、钝化、逐出和复制的底层库。POJO 库(使用org.jboss.cache.pojo.PojoCache接口)构建在 Core 库之上,它允许通过 JBoss AOP 来允许对象自省(Introspection)以提供透明的一致性。Bela Ban 最初建立了这个项目,而现在它是由Manik Surtani 来负责。下面是Bela Ban和Manik Surtani访谈，看他们是怎样定位和描述JBoss Cache。
Bela Ban访谈
问：你能告诉我们一点关于你自己和您的工作？
答：我是JGroups（www.jgroups.org）项目和JBossCache（www.jboss.org）项目的领导者。 JGroups是一个可靠多播通信的在Java工具包，是JBoss的集群和JBossCache的基础。我出生在瑞士，在苏黎世大学完成了我的博士学位。我还曾在IBM苏黎世研究院工作四年。然后，我移居美国，在康奈尔大学获得博士后，然后在Fujitsu工作直到2003年。我在2003年加入了JBoss社区。
问：您刚刚发布了JBossCache，请告诉我们一点您的产品吗？
答：JBossCache是一个树状结构复制的事务处理缓存，可用于跨进程事务性的复制数据。所以，如果你的元素添加到一棵树，它会出现在集群中的所有的树。缓存可以是本地的或集群复制的。在集群复制的情况下，我们可以做异步或同步复制，后者将阻塞调用者，直到所有集群中的树已更新，前者只是将修改请求发送到通道总线上而立即返回。 JBossCache可以使用事务，这意味着，如果你有一个事务，JBossCache能够将收集的所有修改，只有在最后一个修改完成时结束时复制。当然，如果你回滚事务，不会有任何的复制。因此，要总结我想JBossCache说主要有三种模式：- 作为一个纯粹的本地缓存中，没有任何复制
- 作为一个复制缓存，使用异步复制。你有一个主服务器，更新树，并定期或立即更新复制到所有备份服务器，但总是在后台（不阻塞调用者）
- 作为一个复制缓存，使用同步复制。在这里，我们运行一个两象限（2 phase）提交协议在集群中的所有树木，以确保数据的一致性，这种情况下，我们需要确保修改已应用到集群中的所有树。当然，为了可靠性，在性能方面，你必须付出一定的代价。
问：是什么促使你进入想要开发一个缓存的产品？
答：企业应用需要的高速缓存，以加快速度，如EJB、HTTP会话复制等。
问：在任何项目中，我们一直猜测的性能瓶颈在那里，您认为JBossCache的瓶颈在那里？
答：首先两象限（2 phase）提交是非常昂贵的。另一个瓶颈是，如果你访问同一个对象在不同的位于在同一集群中，你可能会遇到死锁。我们解决这个问题，通过使用锁获取超时，这样的两个事务同时访问同一个对象其中一个事务可能回滚，而另一个可能会成功。但是，从长远来看，我们希望拿出一个方案，提供了一个分布式死锁检测机制。
问：你能告诉我们您遇到过的任何瓶颈？
答：我们并没有真正发现任何意外的瓶颈。我们的一个单元测试因超时而失败过一次，我们意识到，我们做了500次两象限提交，这是导致问题的原因，当然我们使用的树型结构缓存不会有此问题。
问：您将前往HP实验室做了一些性能测试。这将是一个有趣的经历，你能告诉我们一点关于它吗？
答：HP意识到很多他们的客户使用JBoss，所以他们自然希望能够为JBoss提供支持，并在将问题升级到JBoss社区之前能自己解决性能问题。所以他们愿意为我们提供性能测试实验室，我们将测试JGroups和JBossCache的性能，但我也有兴趣在测试的JBoss集群性能。
问：如果你有能力改变Java中某一设计您会选择什么？
答：我很高兴学习使用Java，我认为Sun已经做了很好的工作，一小点建议：NIO缺失一些重要功能，不支持多播套接字，SSL安全套接字，我们需要更原始的套接字，这样Java应用有更多的选择。
Manik Surtani访谈
问：Manik,您能否首先跟大家讲一下在您所接触或者了解的客户中,大部分人都是怎样运用JBoss Cache 的?缓存能带来哪些优点?尤其是在高度的可用性方面,缓存带来了怎样的进步?
答：从持续存储、尤其是数据库中读取数据需要付出昂贵的代价。而且,数据库在伸缩性方面也是臭名昭著(或者不便宜),当你想要扩展前端或增加更多客户端时,这个弊端显然就成了障碍。另一方面,CPU 和内存的价格越来越便宜,这意味着更多的人可以负担得起架设高可用系统所需的成本。“本站正在维护中”的暂停服务方式都应当成为历史。像 JBoss Cache 这样的分布式缓存扮演的是一个处于应用服务前端和数据库间的中间层的角色,提供对持久性数据状态在内存中的快速访问。JBoss Cache 能够确保缓存中的数据状态和数据库中的状态一致、及时更新数据状态、并且保证 JVM 不会出现堆溢出问题。
问：JBoss Cache 和其它一些开源项目,例如 Hibernate 和 JBoss Seam 等的集成情况怎样?
答：一些开源项目确实用到了 JBoss Cache。Hibernate(以及 JBoss ApplicationServer 的 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 类,与其说对性能有什么帮助,倒不如说它是浪费开销。
问：你们如何管理引用完整性(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 复制。
问：在缓存和集群方面,您对近期的发展状况有怎样的期望?JBoss Cache 将会如何去满足新的用户需求?
答：随着硬件越来越便宜、CPU 厂商在每块芯片上放置越来越多的内核,分布式缓存将会越来越重要。这无疑意味着需要更多的“虚拟”机,意味着数据库需要“竭尽全力”去管理高度的并发性,也意味着分布式缓存将会成为数据瓶颈(data bottleneck)最重要的解决方式之一。逐渐流行的数据网格和云计算也同样会推动分布式缓存的发展,无论是“云”还是网格的数据节点都需要访问和共享数据。
3066
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
