Memcached的JGroups实现支持失败转移和JMX

Memcached 是一个分布式内存对象缓存系统， 用于动态Web应用以减轻数据库负载。它通过在内存中缓存数据和对象来减少读取数据库的次数，从而提高动态、数据库驱动网站的速度。Memcached基于的是一个存储键/值对的hashmap。其守护进程（daemon ）是用C写的，但是客户端可以用任何语言来编写，并通过memcached协议与守护进程通讯。但是它并不提供冗余（例如，复制其hashmap条目）；当某个服务器S停止运行和崩溃了，所有存放在S上的键/值对都将丢失。

Bela Ban，JBoss的JGroups和Clustering团队的领导，最近写了一个基于JGroups的memcached实现，它允许Java客户端直接访问memcached。该实现完全是用Java编写的，而且拥有少量优于memcached框架的特性 ：

• Java客户端和PartitionedHashMap（org.jgroups.blocks.PartitionedHashMap）可以在同一地址空间运行，因此不需要使用memcached协议进行通信。这使得servlet可以直接访问缓存，而不需要在其上进行序列化。
• 所有PartitionedHashMap进程彼此知道对方，当一个集群成员发生改变时，它们能够决定做什么。例如，一个要停止服务的服务器可以把它管理的所有键都迁移到下一个服务器。使用memcached，存 放在S服务器上的条目在S关机的时候就丢失了。
• 当一个集群成员发生改变时（例如，一个新服务器S启动了），那么所有服务器都检查自己所保存的一个条目事实上是否应该存放在S上。它们会把所有条目都转给S。这样的好处是不需要再次从DB中 重新读取这些条目并插入到缓存中（memcached正是这么做的），但是缓存要自动地使自己重新达到平衡 。
• PartitionedHashMap拥有一个一级缓存（level 1 cache——L1 cache）。这就可以使缓存的数据离真正需要它的地方很近。例如，如果我们拥有A、B、C、D和E几个服务器，且一个客户端给C增加了一个（要被高度访问的）报纸文章，那么memcached总是把所有对该文章的单一请求都转给C。这样，一个正在访问D的客户端总是会触发一个从D到C的GET请求，并返回一篇文章。JGroups在第一次访问时把这 篇文章缓存在D的L1缓存中，这样所有从D访问这篇文章的其它客户端将获得这个被缓存的文章，因而我 们可以避免又一轮对C的访问。注意，每个条目都有其失效时间，它将导致该条目在失效时被从L1缓存中删除，那么下一个访问将不得不重新从C获取该文章并再次把它放在D的L1缓存中。这个失效时间是由该文章的提交者定义的。
• 因为GET、SET和REMOVE的RPC都使用JGroups作为传输，传输的类型和服务的质量可以通过定义传输的底层XML文件来控制和定制。例如，我们可以压缩或者加密所有RPC信息。它还让我们可以选用UDP （IP多点传送和/或UDP数据报）或TCP。
• 连接器（org.jgroups.blocks.MemcachedConnector）负责分析memcached协议并调用 PartitionedHashMap上的请求（PartitionedHashMap代表了memcached的实现），服务器 （org.jgroups.demos.MemcachedServer）和L1及L2缓存（org.jgroups.blocks.Cache）可以被随意装配或替代。因此定制JGroups memcached实现很简单；比如使用一个不同的MemcachedConnector来处理二进制协议（当然需要与客户端代码匹配）。
• 所有管理信息和操作经由JMX被暴露。

启动JGroups memcached实现的主类是org.jgroups.demos.MemcachedServer。它创建了一个L1缓存（ 如果配置了）、一个L2缓存（存储所有条目的默认hashmap）、以及一个MemcachedConnector。API非常 简单且包含如下缓存方法：

• public void put(K key, V val)：按照默认的缓存时间把键/值对存入缓存
• public void put(K key, V val, long caching_time)：与上面方法相同，但是可以定义缓存失效时间。0表示永远缓存，-1表示不缓存，任何正值代表了该条目要缓存的毫秒数
• public V get(K key)：获得键K所对应的值
• public void remove(K key)：从缓存（L2及L1，如果启用的话）中删除一个键/值对

InfoQ就memcached的JGroups实现背后的动机采访了Bela Ban。他说memcached的JGroups实现使得他们可以试验分布式缓存并看看不同的缓存策略适应JBoss集群的程度如何。他还阐明了这个新的 memcached实现与JBossCache缓存框架的比较：

我们把缓存看作是一个连续统一体：从分布式缓存（数据跨越集群中多个节点，但是没有 冗余）到完全复制数据缓存（每个数据条目整体复制到每个集群节点上）。在分布式和整体复制之间， 我们还有 buddy replication，它只把数据复制到一些选定的后备节点上。这可以被比作RAID，RAID 0没有冗余（分 布式），RAID 0+1是全冗余，而RAID 5是部分冗余。

当前，JGroups的PartitionedHashMap提供了分布式缓存，JBossCache提供了全复制和部分复制（使用 Buddy Replication）缓存。其想法是让用户定义他们要放在集群中的K（每个数据项——per data item ）值，K=0表示分布式，但是如果一个节点保存有一个或多个条目，节点崩溃则数据就会丢失；K=X（这 里X
memcached的JGroups实现是尝试K=0的第一步，它是纯数据分布式缓存，没有冗余。其最终会被纳入到 JBossCache中。

memcached实现适合放在JBoss应用服务器的哪个模块？

它将成为Clustering子系统的一部分，由JBossCache提供。注意我们的实现是真正给“Java”客户端写的，因此不必使用那些非常低效的memcached协议，而是在上层使用了编组 （marshalling）/解读（unmarshalling）/复制（copying）。

谈到使用memcached的JGroups实现的典型使用场景，Bela说道：

运行在JBoss或Tomcat集群上的服务器端代码（例如servlets），其访问一个DB并需要缓存以提高速度并避免DB瓶颈。其它使用场景也类似，只是访问的不是DB而是文件系统。例如，一个HTML 页面缓存服务器（Squid立刻浮现在脑海里）。

有无计划将来把memcached引入到JBoss应用服务器中。

当然有。 数据分区（ Data Partitioning）特性将使得用户可以按照自己的需要来配置缓存。这样使得分布式缓存看上去 不像是一个新特性，而是JBossCache的配置而已。更酷的是这是动态的，因此开发者可以决定他们所放 进JBossCache的每个数据项（per data item）要使用哪种冗余特性（none=distribution，full=total replication 或 partial）。

至于该项目新特性的未来方向，Bela罗列了要做的一些事情：

• 基于缓存中的字节数而不是元素数提供一种逐出策略。
• 把从远端服务器接受到元素存储为byte[] buffer而不是对象。在第一次访问时，把byte buffer解读成对象。这在JBoss的HTTP会话复制代码中被使用且一直表现良好：因为不需要解读过程因此不会影响到性能。
• 实现全部memcached协议：现在我只提供GET、GET-MULTI、SET和DELETE。尽管其它的（APPEND 、PREPEND、CAS）很容易实现，但是我还没有做，因为Java客户端的主要使用场景位于我们memcached实现的同一JVM中，因此不需要memcached协议。
• 提供一个更好的一致散列的实现。

memcached的JGroups实现和其依赖类库可以从其sourceforge站点上下载。下面是运行该程序的命令：

java -jar memcached-jgroups.jar

Bela正在期待着社区的反馈。他说这是一个试验特性，但是将成为JBossCache支持的一个特性，社区意见将会极大影响这一特性的方向。

查看英文原文：JGroups Implementation of Memcached Supports Failover and JMX