CN101594377A - 用于管理Feed数据的系统和方法 - Google Patents

Abstract

一种用于管理Feed数据的系统和方法。所述系统包括：网关，用于向多个Feed设备之一转发对所述Feed数据的操作请求；以及多个Feed设备，所述多个Feed设备之间采用对等方式相互连接和通信，其中接收到所述操作请求的主Feed设备和其它从属Feed设备协同工作，用于存储所述Feed数据，并根据所述操作请求来执行对Feed数据的操作。利用本发明的系统和方法，可以获得高效的Feed数据表的多维度分区，充分的健壮性，即插即用的高扩展性，简单的应用编程接口(API)以及对Feed数据的原生存储支持。

Description

用于管理Feed数据的系统和方法

技术领域

本发明一般地涉及Web Feed(也可以称为Web订阅源，以下简称为Feed)数据的存储和检索，并且具体而言涉及一种用于管理Feed数据的系统和方法。

背景技术

随着万维网(World Wide Web，WWW)的蓬勃发展，Web的内容变得越来越丰富。在进入Web 2.0时代之后，估计Web一共具有大约150-300亿个网页。因此，对于用户来说，手动地逐个访问感兴趣的网页以及在其中定位感兴趣的内容正在变成一项繁重的劳动。由此，许多网站提供REST、SOAP、WSDL、FEED以及其它用于机器访问的Web服务。

Feed数据是一种数据格式，其用于向用户提供频繁更新的内容。内容分发者将Feed联合(syndicate)，从而允许用户订阅它。收集可访问的Feed的集合被称为聚合(aggregation)，其通过因特网聚合器来实现。

对于Feed的应用可以理解为是一种信息传输方式，与我们所熟悉的电子邮件、万维网(WWW)、即时消息传送(IM)并列。这种新的信息传输方式主要解决了以下几个问题：

1.信息源的更新监测；

2.多个信息源的集中处理；

3.所有信息按照信息源的自动分类。

从它主要解决的几个问题可以看出，通过Feed的这种信息传输方式将信息获取(处理)的效率提升到了一个新的高度，它节省了用户浏览信息所需要的时间，或者在同样的时间内能够让用户浏览更大量的信息。例如RDF、RSS、ATOM都是信息源的格式标准。Feed之所以出现并且流行，是因为因特网上的信息源越来越多，而且信息源的更新越来越频繁，而用户的浏览效率越来越低，从而需要一种工具来帮助用户查找感兴趣信息的更新并向用户通知。

在应用Feed的典型场景中，内容提供者在其网站上发布Feed链接，终端用户可以通过在其自己的机器上运行的聚合器程序(也可以被称为Feed阅读器或新闻阅读器)在网站上进行注册。终端用户可以简单地将Feed链接从Web浏览器拖拽到聚合器。当聚合器运行时，它向它的Feed列表中的所有服务器询问其是否具有新内容。如果有新内容，则聚合器或者对该新内容进行注释，或者下载该内容。聚合器还可以被调度为周期性地检查新内容。

由Feed所传送的数据的种类典型地为HTML(超文本标记语言)的网页内容或者指向网页的链接以及其它类型的数字媒体。通常，当网站提供Feed来向用户通知内容更新时，该通知通常包括Feed的摘要而不是其整个内容。

相对于经由电子邮件或者其它方式接收频繁发布的内容，Feed具有很多优点。当订阅Feed时，用户不必公开他们的电子邮件地址，从而不会增加与暴露电子邮件相关的风险，诸如垃圾邮件、病毒、身份盗窃等等。当用户想停止接收Feed数据的更新时，他们不必非要发送“取消订阅”请求，而是他们可以简单地从其聚合器中移除Feed链接。

通过上述对Feed的介绍可以看出，随着越来越多的传统网站正在采用Web 2.0的特征，并提供支持Feed的Web服务，以及随着用户对Feed的需求和订阅行为的增加，Feed数据将是海量的，且在不停更新和增加，并且Feed数据的内容是多种多样的。例如，博客(blog)网站所提供的博客内容每天都在不断增加。因此，这些海量的Feed数据需要一种简单的、成本合算的存储系统，其具有高度的可扩展性和可恢复性，以便支持对Feed数据的各种操作(例如存储、爬取(crawling)、查询、搜索和维护)。

出于此目的，例如可以使用现有技术中的RAID(独立磁盘冗余阵列)、SAN(存储区域网络)、分布式RDB(关系数据库)、文件系统、RDB群集等等。但是，由于Feed数据的固有特点(海量、不断增加、多种多样)，这些现有技术对于Feed数据的存储来说并非最佳选择。例如，这些现有系统的特征有：专注于一般数据存储，而缺乏对Feed数据的原生(native)存储支持；难于进行扩展；安装和管理十分复杂；以及对于海量的Feed数据的存储和操作来说是昂贵的。

因此，为了在Web 2.0时代中更好地处理海量的Feed数据，提高对Feed数据的各种操作(例如存储、爬取、查询、搜索、维护)的运行效率，同时兼顾可扩展性、简单性和健壮性，存在对于一种用于管理Feed数据的改进的系统和方法的需要。

发明内容

为了针对Feed数据的特性来管理Feed数据，而提出了本发明。在本发明中，通过将Feed数据存储为Feed数据表，实现对Feed数据的原生存储支持，基于多个维度将Feed数据表划分到不同的分区，建立数据表级别的复制机制，并且以对等方式将Feed设备架构成群集，且提供简单的面向资源的访问接口。

在本发明的第一方面中，提出了一种用于管理Feed数据的系统，所述系统包括：

网关，用于向多个Feed设备之一转发对所述Feed数据的操作请求；以及

多个Feed设备，所述多个Feed设备之间采用对等方式相互连接和通信，其中接收到所述操作请求的主Feed设备和其它从属Feed设备协同工作，用于存储所述Feed数据，并根据所述操作请求来执行对Feed数据的操作。

在本发明的第二方面中，提出了一种用于管理Feed数据的方法，所述方法包括：

由网关向采用对等方式相互连接和通信的多个Feed设备之一转发对所述Feed数据的操作请求；以及

由所述多个Feed设备中接收到所述操作请求的主Feed设备与所述多个Feed设备中的其它从属Feed设备协同工作，用于存储所述Feed数据，并根据所述操作请求来执行对Feed数据的操作。

利用本发明的系统和方法，可以获得高效的Feed数据表的多维度分区，充分的健壮性，即插即用的高扩展性，简单的应用编程接口(API)以及对Feed数据的原生存储支持。

附图说明

在附带的权利要求中阐明了被认为是本发明新颖特性的特征。然而，通过参考以下结合附图的说明性实施例的详细描述，将最好地理解本发明本身以及其优选使用模式、另外的目的和优点，在附图中：

图1示出了根据本发明一个实施例的用于管理Feed数据的系统的简单示意图；

图2A和2B具体描述根据本发明实施例的用于管理Feed数据的系统的体系结构和运行模式；

图3详细描述了图2A和2B示出的系统中的Feed设备(活动节点)的内部结构的示意图；

图4示出了对于Feed数据表的存储策略的示例性示图；

图5示出了分区在活动节点上的示例性分布，所述分区各自包括若干Feed表；

图6详细描述了图2A和2B示出的系统中的监视节点的内部结构的示意图；以及

图7示出了根据本发明一个实施例的用于管理Feed数据的方法的流程图。

需要注意，在全体附图中，相同或相似的标号指代的是相同或相似的单元或组件。

具体实施方式

在下文中将结合附图对本发明的示范性实施例进行描述。为了清楚和简明起见，在说明书中并未描述实际实现方式的所有特征。然而，应该了解，在开发任何这种实际实施例的过程中必须做出很多实现方式所特定的决定，以便实现开发人员的具体目标，例如符合与系统及业务相关的那些限制条件，其中，这些限制条件会随着实施方式的不同而改变。此外，还应该了解，虽然开发工作有可能是非常复杂和费时的，但对得益于这个公开内容的本领域技术人员来说，这种开发工作仅仅是例行的任务。

此外，还需要说明的一点是，为了避免因不必要的细节而混淆了本发明，在附图中仅仅示出了与根据本发明的方案密切相关的装置结构和/或处理步骤，而省略了与本发明关系不大的其它细节。

为了帮助对本发明的理解，在本发明的上下文中，一个Feed数据指的是来自于同一个链接的所有数据，该Feed数据可以随时被更新。一个Feed数据可以被存储在一张Feed数据表中。对Feed数据的每次更新，都会被添加到该Feed数据表中作为一个条目。

在根据本发明实施例的用于管理Feed数据的改进的系统和方法中，Feed设备是一种基本的以及必要的组件。需要创建在内部绑定了Web应用服务器和数据库的Feed设备，使得该Feed设备具有对Feed数据的各种操作(例如爬取、查询、搜索、维护)的功能。每个Feed设备都在系统中充当一个节点。在整个系统中包括多个节点，其中每个Feed设备都可以是即插即用的(plug&play)。各个Feed设备以对等(Peer-to-Peer，P2P)方式相互通信，从而该系统可以容易地进行扩展以便在必要时提高系统的工作性能，并且有利于系统中的节点之间的相互通信。

为了更好地理解本发明及其特征和优点，以下对Feed设备进行详细介绍。Feed设备是一种硬件设备，其具有基本的系统环境。系统环境可以具有操作系统、其它应用以及特定的配置，其中，所述应用可以用于实现对节点自身的各种操作(例如，加入系统、建立连接等)以及由用户用于对节点进行访问和各种操作，所述特定配置例如可以提供对于应用服务器和数据库的支持。Feed设备还具有在该系统环境下运行的Web应用服务器和数据库，其中Web应用服务器包括用于对Feed数据进行操作的各种功能(诸如Feed数据的创建、查询和移除等)，以及用于存储节点自身的状态，以及数据库用于存储Feed数据。在实践中，Feed设备可以是通用的台式计算机、笔记本计算机、或者具有上述功能的专用硬件设备。例如，一个Feed设备可以具有大于400GB的硬盘，以及大于2GB的存储器。

在简要介绍了Feed设备的结构和功能之后，以下是对本发明及其实施例的详细介绍。首先参见图1，图1示出了根据本发明一个实施例的用于管理Feed数据的系统的简单示意图。如图所示，所述系统包括：网关节点130、监视节点140、以及多个Feed设备110(下文中也可以被称为活动节点)。在图1中，多个Feed设备110与网关节点130、监视节点140通过总线120彼此互连，从而可以实现对等连接，以便确保系统的可扩展性。

连接到系统中的每个Feed设备(活动节点)都具有相同的功能，并可以执行相同的操作，例如对于Feed设备自身的操作和对于Feed数据的操作。每个Feed设备存储一部分的Feed数据。Feed数据的存储方式是基于Feed表的。Feed表提供对Feed数据的原生存储支持。并且可以将所有的Feed表划分到多个多维度分区，每个分区中包括具有相同或相似特征的Feed表。该存储方式将在下文中进行详细介绍。每个Feed设备只有在连接到系统中的时候才被称为活动节点。尽管在图1中将Feed设备示出为台式计算机，但是这仅是一种示例，并不意味着对Feed设备的种类的限制。

网关节点130可以是服务器或交换机，用于执行负载均衡操作，因此网关节点130自身的负载很低。例如，网关节点130可以负责接收客户机对Feed数据的操作请求，并将该请求转发到一个负载较轻的活动节点作为临时主节点，而忽略负载较重的活动节点。由主节点负责协调其它节点进行Feed数据的创建、查询等操作，

监视节点140也可以是通用的计算机，例如纽约Armonk的国际商业机器公司(IBM)的低端的X-series服务器，用于监视所有活动节点110的状态并存储这些状态，定期对活动节点110进行检查，将诸如加入节点或移除节点这样的事件通知网关节点130和所有的活动节点110，以及存储Feed数据(以及Feed表、分区)在各个节点上的分布状况。

通过上述这样组成的系统，可以将Feed数据分布到多个活动的Feed设备(活动节点)110上，这些数据可以在需要时被检索。在本发明的一个实施例中，这些Feed数据被复制若干份并存储在不同的活动节点110上，从而确保了系统的健壮性。并且这些Feed设备的状态被监视，以确保及时发现发生故障或被移除的设备或新加入的设备。

下面将结合图2A和2B具体描述根据本发明实施例的用于管理Feed数据的系统的体系结构和运行模式。如图2A所示，客户机150向网关节点(以下简称为网关)130提交对Feed数据的操作请求，该请求可以是Feed数据的创建请求、查询请求或移除请求等。在接收到操作请求后，网关130从多个活动节点110中确定一个临时主节点115，此时所有其它节点成为从属节点。这些活动节点110在功能上都是相同的，用于执行Feed数据的创建和查询等任务。例如，网关130可以根据各个活动节点110上的负载来确定临时主节点115，该临时主节点115上的负载相对较轻，而其它的活动节点110成为从属节点。各个活动节点110上的负载可以通过访问监视节点140上所存储的活动节点110的状态而获得。如果存在多个负载较轻的活动节点110，则网关130可以按照某种策略或者随机地从中选择一个作为临时主节点115。在确定了临时主节点115之后，网关130将操作请求转发到该临时主节点115。

如果所述请求是对于Feed数据的创建请求，则由所确定的临时主节点115将新的Feed数据传送给具有可用存储空间的活动节点110。临时主节点115可以通过访问监视节点140而获得关于哪个/哪些活动节点110具有可用存储空间的信息。在图2A中，Feed数据被示出为在除了临时主节点115之外的3个其它从属的活动节点110上创建。可以理解，可替换地，Feed数据也可能在临时主节点115自身之上创建。由收到Feed数据的活动节点110调用自身的Feed数据创建功能来创建用以存储Feed数据的Feed数据表。在创建了Feed数据之后，所述活动节点110向临时主节点115传送创建成功的消息，该消息作为对创建请求的响应被临时主节点115传送给客户机150。

如果所述请求是查询请求或移除请求，则由所确定的临时主节点115访问存储了所需的Feed数据的一个或更多其它从属的活动节点110(在图中示出3个)。临时主节点115可以通过访问监视节点140而获得关于所需的Feed数据被存储在哪个/哪些活动节点110上的信息。在图2A中，Feed数据被示出为存储在除了临时主节点115之外的3个其它从属的活动节点110上。可以理解，可替换地，Feed数据也可能被存储在临时主节点115自身之上。如果所述请求是查询请求，则存储了Feed数据的活动节点110调用自身的Feed数据查询功能而获得相应的Feed数据并返回给临时主节点115。在获得所需的Feed数据之后，临时主节点115将所获得的Feed数据作为对查询请求的响应返回到客户机150。如果所述请求是移除请求，则存储了Feed数据的活动节点110调用自身的Feed数据移除功能而将相应的Feed数据移除。在移除了Feed数据之后，所述活动节点110向临时主节点115传送移除成功的消息，该消息作为对移除请求的响应被临时主节点115传送给客户机150。

在本发明的一个实施例中，对于Feed数据的更新是通过系统自动完成的。系统可以定期地查询所存储的所有Feed数据的来源链接，如果发现了已经被更新的Feed数据，则根据所述更新的Feed数据来更新系统中相应节点上所存储的Feed数据。由于Feed数据可以被存储在Feed数据表中，因此所述更新可以被添加到该Feed数据表中作为一个条目。本领域技术人员可以理解，客户机115也可以向网关130提交更新请求，则网关130响应于该更新请求来执行对于Feed数据的更新过程。本领域技术人员可以理解，活动节点110对于Feed数据的更新操作过程与处理查询请求、创建请求的处理过程相类似，在此不再具体描述。

在图2A所示的系统中，监视节点140持续执行系统监视和管理的功能，并向网关130和活动节点110提供所需的关于活动节点的负载情况和存储数据分布的信息。监视节点140可以为一轻量级机器，从而节约系统成本。

图2B与图2A相类似，当客户机150再次向网关130提交另一操作请求时，网关150从多个活动节点110中确定一个临时主节点115并将该操作请求转发到该临时主节点115。由于系统中的任一活动节点110均有可能成为临时主节点115，只要该节点上的负载相对较低。因此，图2B示出了网关150将另一个活动节点确定为临时主节点115。根据请求的类型不同，临时主节点115通过查询监视节点140而确定相应的活动节点110来执行对于Feed数据的创建、查询和移除等过程。这些都与图2A所述内容相同。

在本发明的一个实施例中，如图2A与图2B所示的通过Feed设备来管理Feed数据的系统可以向客户机150提供支持REST(RESTful)的应用编程接口(API)。REST(Representational State Transfer，表述性状态转移)是一种基于Web的体系结构，其核心特征是组件之间有一个统一的接口。通过在接口上应用通用性的软件工程原则，整体的系统体系结构得到了简化，交互的可见性也得到了改善。关于REST体系结构的具体细节，请参见Roy Thomas Fielding博士的论文“Architectural Styles and theDesign of Network-based Software Architectures”，该文档可以在因特网URL：http://www.ics.uci.edu/～fielding/pubs/dissertation/top.htm找到。

在本发明的实施例中，支持REST的API可以包括以下语法。

1)Feed创建：

POST http://[host]/feeds；

其参数包括：isScratch，feedContent，feedURL，scratchURL，interval，snapshot，并且返回人类可读的URL(统一资源定位符)：

http://[host]/feeds/url＝someUrl。

2)Feed更新：

PUT http://[host]/feeds/url＝...；

其可以定期自动执行。

3)Feed移除：

DELETE http://[host]/feeds/url＝...；

DELETE http://[host]/feeds？con1＝v1&con2＝v2。

4)Feed查询：

GET http://[host]/feeds/url＝someUrl；

GET http://[host]/feeds？con1＝v1&con2＝v2；

其参数包括url(对应于Feed的URL)、author(对应于<author>元素)、updated(对应于<updated>元素)等等，并返回XML(可扩展标记语言)格式的数据。

5)Feed搜索获取：

http://[host]/feeds？searchCon＝someExpression；

其返回XML格式的数据。

根据本发明的支持REST的API，可以向客户机150的用户提供简明直观的结果。

在描述了根据本发明实施例的用于管理Feed数据的系统的体系结构和运行模式之后，图3详细描述图2A和2B示出的系统中的Feed设备(活动节点)110的内部结构的示意图，所述活动节点110可以是系统中的任意一个活动节点。如图3所示，图3左边的缩略图表示活动节点110在所述系统中的位置。活动节点110包括应用服务器300、数据库360和系统环境370。每个活动节点110的应用服务器300可以是本领域已知的任意应用服务器，例如纽约Armonk的国际商业机器公司(IBM)的ProjectZero。应用服务器300包括主(master)功能310和从属(slave)功能320。主功能310和从属功能320分别具有Feed创建、Feed查询和Feed移除的功能，这些功能都支持REST。当活动节点110被网关130确定为临时主节点115时，其主功能310开始起作用，主功能310主要用于协调其它从属节点的操作。如果活动节点110是从属节点，且从临时主节点115接收到对于Feed数据的创建、查询、移除的命令，则它的从属功能320开始起作用。从属功能320在此节点110上执行对于Feed数据的创建、查询和移除等具体操作，并在所述操作完成之后将结果传送给临时主节点115。

应用服务器300还可以包括节点状态330、节点注册表340、以及本地高速缓存350。节点状态330表示节点当前的状态，例如可以是活动、故障等，并且可以包括该节点的存储空间状况、负载情况等等。监视节点140可以存储该节点状态330，从而使得网关150或临时主节点115可以确定该节点目前在系统中的运行情形，从而确定是否能够向该节点分配任务。节点注册表340用于将该节点登记到系统，从而系统知道该节点的存在，例如，节点注册表340可以是对于每个节点唯一的标识符(ID)。本地高速缓存350用于临时存储Feed数据。

每个活动节点110的数据库360包括用于存储Feed数据的Feed数据表。所述数据库可以是本领域已知的任意数据库，例如纽约Armonk的国际商业机器公司(IBM)的DB2数据库。数据库360对于Feed数据的存储方式将在以下进行介绍，其具有对Feed数据的原生存储支持。

根据本发明的一个实施例，在创建Feed数据，也就是将Feed数据存储到活动节点110的数据库360中的时候，将Feed数据存储在一个Feed数据表(简称为Feed表)中。Feed表是用于存储实际的Feed数据的一个表。在Feed数据被存储到Feed表之前，Feed数据被遍历和解析，以便从中提取某些预定的属性数据，从而将所提取的属性数据存储在Feed表中的相应的字段中，而将Feed数据的其余部分存储在该Feed表中的特定一个字段中。图4示出了对于Feed数据表的存储策略的示例性示图。

如图4所示，根据存储策略，一个Feed数据表的每一条目具有若干字段(如400所示)，其中字段410为标识符(ID)，字段420为统一资源定位符(url)，字段430为作者(author)，字段440为更新时间(updated)，字段450为Feed数据的其余部分。除了字段450之外，这些字段中的每一字段都用于存储从Feed数据中提取的特定属性，其遵从针对该列的已定义的格式，如400的第二行所示。字段450为Feed数据的其余部分，其可以是纯粹XML格式的一段代码。字段450的详细内容例如可以如框460所示。在Feed数据表中，字段450的空间将被保留足够大，以便存储整个的XML代码。在绝大多数情况下，字段450的空间将足以存储整个Feed数据的条目。例如，对于该字段中的每个单元，可以保留1M字节的空间。如果在极端情况下，字段450中要存储的XML代码超过1M字节，则节点上的Feed创建功能可以将该Feed数据的条目拆分为几行，其中每行中存储的XML代码不超过1M字节。注意，图4中示出的若干字段仅是作为示例，在实际应用本发明时，可以根据需要对于图4中示出的字段的种类进行添加、修改或删除。

如图4所示的对于Feed数据的存储策略具有对Feed数据的原生存储支持，从而便于对Feed数据进行存储和搜索，并且没有冗余。注意，在一个活动节点110中可以具有多个以这样的方式存储Feed数据的Feed表。

由于Feed数据的数量极大，并且不断增加，因此Feed表的数量也极大，从而在活动节点110中查询Feed表仍然是一项繁重的工作。在本发明的一个实施例中，提供了一种分区机制，其通过将大量的Feed表划分为分区而提高对于Feed数据的查询效率。通过所述分区机制，可以将具有相同或相似属性特征的Feed表划分到一个分区中，从而使得每个分区包括一个或更多Feed表。这样，当查找某个Feed表时，只需要先按照属性特征确定该Feed表所属的分区，就可以在该分区中找到该表，而不用查询所有的Feed表。这样，对于Feed表的查询速度可以大大提高。

进一步地，在本发明的一个实施例中，所述分区机制可以进一步基于多个维度来将Feed表划分为分区。仍然采用图4所示的示例，通过所述多维度分区，将每一查询条件(图4的400中除了字段450之外的字段)看成是一个维度。用户可以根据需要来确定查询条件。例如，在针对Feed数据中的<author>、<url>、<updated>三个维度来进行分区的情形中，其中<author>代表作者维度，<url>代表URL维度，<updated>代表更新时间维度，提取Feed数据中的字段值，经过哈希算法后产生维度码，再将所得的维度码联合进行进一步的哈希算法而得到分区码。

例如，在一个Feed数据中所包含的字段为：<author>：Tom，<url>：www.sina.com.cn/blogs，<updated>：2008.4.26。

author的哈希值也就是维度码是：1243433223；

url的哈希值也就是维度码是：1233435333；

updated的哈希值也就是维度码是：3112345453。

接着将1243433223、1233435333、3112345453进行进一步的哈希算法而得到一个数值，该数值对应的是该Feed数据的分区码，例如1。通过这样的计算方式，可以将所有的表划分为若干个分区，并使得每一分区具有多个维度。例如，如以下表1所示。

作者维度	URL维度	更新时间维度	分区码
				1243433223	1233435333	3112345453	1
1243433224	1233435334	3112345454	2
				1243433225	1233435335	3112345455	3
1243433226	1233435336	3112345456	4

表1

以下通过示例来简要说明Feed表的多维度分区机制的效果。图5示出了分区在活动节点上的示例性分布，所述分区各自包括若干Feed表。例如，如图5所示，分区1包括表1-3，分区2包括表4-7，分区3包括表8-10，而分区4包括表11。表1-11被离散地分布在节点1-3上。从而，当查询特定Feed表(Feed数据)的时候，可以通过已知的维度(查询条件)首先确定该Feed表所属的分区，然后从所确定的分区中继续查询该表，从而显著提高了查询的效率。同一个分区可以跨多个活动节点存储，也就是说，该分区中的多个Feed表可以被存储在不同的活动节点上。

应当注意，理论上，分区的数量可以从1直到等同于Feed表的数量。分区的数量越多，则属于每个分区中的Feed表的数量就越少，这样可能会影响查询分区的速度；而分区的数量越少，则属于每个分区中的Feed表的数量就越多，这样可能会影响在每个分区中查询Feed表的速度。因此，分区的数量应该保持为一个适当的值，从而可以使得分区数量和每个分区中的Feed表的数量保持均衡，其中分区的数量可以是可配置的。这可以通过对维度的精确性控制来实现，也即，控制对于维度码进行计算的哈希算法。例如，为了适当减少分区的数量，可以将作者维度中的Tom和Thomas计算为同样的维度码，或者可以将更新日期维度中在同一周(而并非同一天)更新的Feed数据都计算为同样的维度码。

此外，为了确保根据本发明实施例的用于管理Feed数据的系统的健壮性，还提供了一种对于Feed数据的复制机制，其将所有的Feed表(Feed数据)复制若干份，并存储在不同的活动节点110上，从而当某一节点发生故障或者被移除时，仍然可以查询到所需的Feed表。根据所述复制机制，基于预先定义的复制系数(例如为2)，将所有的Feed数据复制两遍，其中Feed数据被复制的次数等于复制系数，从而得到另外两份备份。例如，某一Feed表1可以被复制为表1’和表1”，它们具有与表1完全相同的内容，但是这三个表将被分布在不同的活动节点110上。当这三个表中之一的内容被创建、更新或删除时，这三个表均保持为一致。因此当查询该Feed表时，通过查询任一表均可以得到所需的数据。当存储了一个表(例如表1)的活动节点发生故障或被移除时，对于其它活动节点上的另外两个表(表1’和表1”)的CRUD(创建、读取、更新、删除)操作将不会受到影响。而当该活动节点被修复或者被重新加入系统时，将再次将最新的表1’或表1”复制到该节点作为表1，从而这三个表仍然保持为一致。

注意，所述复制系数是预先定义的。复制系数越大，每个Feed表被复制的次数就越多，从而整个系统的健壮性就会越高。但是，复制系数过大会导致大量重复的Feed表的备份占用大量的存储空间，从而增加了系统的成本。因此，对该复制系数的定义需要兼顾系统成本和对系统健壮性的要求。

回到图3，每个活动节点110还包括系统环境370。系统环境370可以包括使活动节点110可以正常运行的操作系统、其它应用程序以及特定的配置(诸如对应用服务器300和数据库360的支持)。用户可以通过系统环境370对活动节点110进行访问和操作。可选地，用户可以通过系统环境370进行用户控制，诸如安全级别控制、用户登录等。系统环境370还可以包括显示器(未示出)。

在详细描述了该系统中的活动节点110的内部结构之后，图6详细描述了图2A和2B示出的系统中的监视节点140的内部结构的示意图。图6左边的缩略图表示监视节点140在所述系统中的位置。监视节点140包括应用服务器600、以及数据库660。应用服务器600可以是本领域已知的任意应用服务器，例如IBM的Project Zero。应用服务器600包括监视模块610、通知模块620、节点注册表630以及重新均衡模块640。监视模块610负责持续地监视和接收系统内的所有活动节点110的状态，以便及时地发现节点状态发生变化的情形。例如，在一个实施例中，当系统内加入新的活动节点时，该活动节点可以将其状态传送到监视模块610，从而监视模块610可以相应地增加数据库660中与所述新节点有关的信息，并通过通知模块620将此情形通知网关130和其它活动节点110，以便网关130(以及所确定的临时主节点115)可以确定是否要向新节点分配Feed数据的创建和查询等任务。在另一个实施例中，监视模块610可以定期地向所有活动节点110发送询问消息，并将在预定时限内没有从其收到相应响应的一个或更多活动节点110确定为故障节点，其中监视模块610发送询问消息的时间间隔可以是可配置的。如果监视模块610确定出一个或更多故障节点，则通知模块620将此情形通知网关130和其它活动节点110，以便网关130(以及所确定的临时主节点115)不会再向故障节点分配Feed数据的创建和查询等任务。节点注册表630用于将该节点登记到系统，从而系统知道该节点的存在，例如，节点注册表630可以是对于每个节点唯一的标识符(ID)。重新平衡模块640在系统内的节点状态出现变化(例如，加入新节点、已有节点发生故障或被移除等)时对系统内的所有节点的负载进行重新平衡。例如，当系统内加入新节点时，可以将对于Feed数据的存储任务优先分配给该新节点。当系统内出现发生故障的节点时，可以在其它节点中寻找该故障节点上存储的数据的备份，并复制到另一个活动节点上。当系统内的多个节点的负载都比较高的情况下，可以协调这些节点协同工作，以便减少每个节点上的负载。

监视节点140的数据库660可以是本领域已知的任意数据库，例如IBM的DB2数据库。数据库660包括Feed分区映射模块661、表-节点映射模块662、分区-表映射模块663以及节点状态表664。Feed分区映射模块661存储了每个Feed分区在各个活动节点110中的分布情形。表-节点映射模块662存储了Feed数据表在各个活动节点110中的分布情形。分区-表映射模块663存储了Feed数据表与其所属的分区之间的对应关系。当客户机150(图2A、2B)提交查询请求时，临时主节点115可以通过查询这三个模块上存储的信息来获知所需的Feed数据位于哪个/哪些活动节点110上。当任一节点上出现新事件时，所述事件可以是加入新节点、移除已有节点、已有节点上的Feed数据存储发生变化(创建、删除等等)，监视节点140都要相应地更新上述模块中存储的内容，以便保持与实际状况相一致。节点状态表664存储了系统中的所有活动节点110的状态、例如负载情况、可用存储空间等等。当节点状态接收模块650收到与节点状态有关的变化或者监视模块610查询到与节点状态有关的变化时，监视节点140都要相应地更新节点状态表664。

当一个新的Feed设备110被加入系统时，它向监视节点140报告它的状态(负载情况、存储状况等)，从而监视节点140将此节点的节点状态存储到节点状态表664中，并通过通知模块620向其它所有的活动节点110和网关130通知有新节点加入的事件，从而该新节点被系统中的所有节点所知并可以被分配任务。

网关130根据对于监视节点140的查询来确定每个活动节点110的状态、负载情况，从而确定临时主节点115。当网关130从客户机150接收的请求是创建请求时，所确定的临时主节点115根据对于监视节点140的查询来确定具有可用存储空间的活动节点110，并且在该活动节点110创建Feed数据(多维分区计算、Feed表复制)之后通知监视节点140更新数据库660中的相应的模块。当所述请求是查询请求或移除请求时，所确定的临时主节点115根据对于监视节点140的查询来确定Feed表所属的分区，并且进而确定该Feed表所在的活动节点110，从而该活动节点110可以查询或移除所需的Feed数据，并且如果Feed数据被移除则在该活动节点110移除Feed数据之后通知监视节点140更新数据库660中的相应的模块。

以上是对于根据本发明一个实施例的用于管理Feed数据的系统的详细介绍。在同一发明构思下，下面结合图7对根据本发明一个实施例的用于管理Feed数据的方法的流程图进行介绍。

如图7所示，所述方法的过程开始于步骤705，在步骤705，客户机向网关提交请求，该请求可以是Feed数据的查询请求、移除请求或者创建请求。在步骤710，网关接收该请求，并执行负载均衡计算。网关通过向监视节点查询各个活动节点的状态和负载情况来执行负载均衡计算。在步骤715，网关从多个活动节点中将负载相对较低的一个活动节点确定为临时主节点，此时所有其它节点成为从属节点。在步骤720，网关将所述请求转发到该临时主节点。在步骤725，每个活动节点确定其自身是临时主节点还是从属节点。如果该活动节点是临时主节点，则在步骤730调用通过查询监视节点来确定需要进行Feed数据操作的从属节点，并通过其主功能来协调所述从属节点的相应操作。否则如果该活动节点是从属节点，则在步骤735调用其从属功能来执行Feed数据的创建、查询和移除等操作，并在所述操作完成之后将结果报告给临时主节点。在步骤740，确定所述请求是否是创建请求。

如果所述请求是创建请求，则所涉及的活动节点在步骤745进行分区计算，其可以是基于多维度的分区计算，即，基于多个维度将Feed表划分到分区中。如果该Feed表所属的分区不存在，则创建一个新分区。接着在步骤750创建Feed表。根据本发明的一个实施例，可以基于预先定义的复制系数，将要创建的Feed表复制若干次，并存储到不同的活动节点上，其中复制次数等于复制系数。然后在步骤760，该节点将创建成功的消息传送到临时主节点，并由临时主节点将该消息作为创建请求的响应传送到客户机。

如果在步骤740，确定所述请求不是创建请求，则该请求是查询请求或者其它请求，诸如移除请求。则所述方法进行到步骤755，所涉及的活动节点在其上执行查询请求或移除请求。然后在步骤760，将所查询的结果或者移除成功的消息传送到临时主节点，并由临时主节点将所查询的结果或者移除成功的消息作为查询请求或移除请求的响应传送到客户机。

任一活动节点对于Feed数据的创建、更新和移除都需要相应地通知监视节点，并由监视节点更新其中的数据库中的相应内容。

以上详细描述了根据本发明一个实施例的用于管理Feed数据的系统和方法。如本领域普通技术人员可以了解的，本发明可以体现为方法、系统和/或计算机程序产品。因此，本发明可以呈现为完全硬件实施形式、完全软件实施形式或者软件和硬件组合实施形式。此外，本发明可以被呈现为在机器可读媒体上包括的计算机程序产品，机器可读媒体上存储了用于对计算机系统进行编程以执行根据本发明的过程的机器可执行程序指令。这里所使用的术语“机器可读媒体”包括向计算机系统提供用于执行的指令的任意媒体。这种媒体可以采用多种形式，包括但是不局限于：非易失性媒体、易失性媒体和传输媒体。非易失性媒体的常见形式例如包括软盘、软磁盘、硬盘、磁带或者任何其它磁媒体、光盘ROM(CD-ROM)或者任何其它光媒体、打孔卡或者任何其它带有孔图案的物理媒体、可编程ROM(PROM)、可擦写PROM(EPROM)、电EPROM(EEPROM)、闪速存储器、任何其它存储芯片或者盒式磁带(cartridge)、或者计算机系统可以读取并适合存储指令的任何其它媒体。

适于存储和/或执行程序代码的数据处理系统将包括：直接地或通过系统总线间接地耦合于存储器单元的至少一个处理器。存储器单元可以包括在程序代码的实际执行期间使用的局部存储器、海量存储装置、以及高速缓冲存储器，该高速缓冲存储器提供了至少某种程序代码的临时存储以便减少在执行期间必须从海量存储装置检索代码的次数。

此外，可以理解，方框图和/或流程图中的每个方框以及方框图和流程图中的一些方框的组合可以用一些计算机程序指令实现。这些计算机程序指令可以提供给一通用计算机、专用计算机或其它可编程数据处理设备的处理器以产生一机器，使得这些指令通过计算机或其它可编程数据处理设备的处理器的执行创建用于实现在方框图和/或流程图内或者方框内所指定的功能的装置。

尽管已经参考优选实施例具体地示出并描述了本发明，但其不是为了以公开的形式穷举或限制本发明。对于本领域的普通技术人员，可以在形式上和细节上进行各种改变而不会背离本发明的精神和范围。选择并描述了实施例是为了最好地解释本发明的原理和实际的应用，以及为了使本领域的其它普通技术人员能够理解对于各种实施例的本发明，所述实施例具有适合于预期的具体使用的各种修改。

Claims (20)

1.一种用于管理Feed数据的系统，所述系统包括：

网关，用于向多个Feed设备之一转发对所述Feed数据的操作请求；以及

多个Feed设备，所述多个Feed设备之间采用对等方式相互连接和通信，其中接收到所述操作请求的主Feed设备和其它从属Feed设备协同工作，用于存储所述Feed数据，并根据所述操作请求来执行对Feed数据的操作。

2.根据权利要求1所述的系统，其中每一个所述Feed设备包括：

应用服务器，用于执行对Feed数据的操作，其中所述操作包括对Feed数据的创建、更新、查询、移除操作；

数据库，用于存储所述Feed数据；以及

系统环境，用于为所述应用服务器和数据库提供系统支持。

3.根据权利要求2所述的系统，其中在所述数据库中，每一个所述Feed数据存储在一个Feed数据表中，其中将从所述Feed数据中所提取的特定属性数据存储在所述Feed数据表中的相应的字段中，而将所述Feed数据的其余部分存储在所述Feed表中的特定一个字段中。

4.根据权利要求3所述的系统，其中在所述数据库中，所述Feed数据表被划分到各个分区中，其中将具有相同或相似属性特征的Feed数据表划分到一个分区中。

5.根据权利要求4所述的系统，其中在所述数据库中，所述Feed数据表基于多个维度被划分到各个分区中，其中将所述Feed数据表中除了存储所述Feed数据的所述其余部分的字段之外的各个字段分别作为一个维度，而将所有的所述Feed数据表划分到多个多维度分区中。

6.根据权利要求3所述的系统，其中在不同的Feed设备的数据库中存储了所述Feed数据表的备份，所述Feed数据表的备份的数量等于一个预先定义的复制系数。

7.根据权利要求1所述的系统，进一步包括监视节点，所述监视节点包括：

监视模块，用于监视和接收系统内的所有Feed设备的状态；

通知模块，用于将加入新的Feed设备、Feed设备的状态改变、以及Feed设备发生故障的情形通知所述网关和其它Feed设备；

重新平衡模块，用于在系统内加入新的Feed设备、Feed设备的状态改变、以及Feed设备发生故障时对系统内的所有Feed设备的负载进行重新平衡；以及

数据库，用于存储每个分区在各个Feed设备中的分布情形，每个Feed数据表在各个Feed设备中的分布情形，Feed数据表与其所属的分区之间的对应关系，以及所述系统中的所有Feed设备的状态。

8.根据权利要求1所述的系统，其中所述系统支持所述Feed设备的即插即用。

9.根据权利要求8所述的系统，其中当一个新的Feed设备被加入所述系统时，该Feed设备向所述监视节点报告它的状态，从而所述监视节点存储此Feed设备的节点状态，并向所述系统中的其它Feed设备和网关通知有新的Feed设备加入的事件。

10.根据权利要求1所述的系统，其中所述系统提供支持表述性状态转移的应用编程接口。

11.一种用于管理Feed数据的方法，所述方法包括：

由网关向采用对等方式相互连接和通信的多个Feed设备之一转发对所述Feed数据的操作请求；以及

由所述多个Feed设备中接收到所述操作请求的主Feed设备与所述多个Feed设备中的其它从属Feed设备协同工作，用于存储所述Feed数据，并根据所述操作请求来执行对Feed数据的操作。

12.根据权利要求11所述的方法，其中存储所述Feed数据的所述步骤进一步包括：将每一个所述Feed数据存储在一个Feed数据表中，其中在所述Feed数据被存储到所述Feed数据表之前，所述Feed数据被遍历和解析，以便从中提取特定属性数据，并将所提取的属性数据存储在所述Feed数据表中的相应的字段中，而将所述Feed数据的其余部分存储在所述Feed表中的特定一个字段中。

13.根据权利要求12所述的方法，其中存储所述Feed数据的所述步骤进一步包括：将所有的所述Feed数据表划分到各个分区中，其中将具有相同或相似逻辑特征的Feed数据表划分到一个分区中。

14.根据权利要求13所述的方法，其中将所述Feed数据表划分到各个分区中的所述步骤进一步包括：

将所述Feed数据表基于多个维度划分到各个分区中，其中将所述Feed数据表中除了存储所述Feed数据的其余部分的字段之外的各个字段分贝作为一个维度，而将所有的所述Feed数据表划分到多个多维度分区中；以及

当所划分的分区不存在的时候，创建一个新的分区。

15.根据权利要求12所述的方法，其中存储所述Feed数据的所述步骤进一步包括：

将所述Feed数据表的备份存储在不同的Feed设备的数据库中，所述Feed数据表的备份的数量等于一个预先定义的复制系数。

16.根据权利要求11所述的方法，其中所述方法进一步包括：

监视和接收所有Feed设备的状态；

将加入新的Feed设备、Feed设备的状态改变、以及Feed设备发生故障的情形通知网关和其它Feed设备；

在加入新的Feed设备、Feed设备的状态改变、以及Feed设备发生故障时对所有Feed设备的负载进行重新平衡；以及

存储每个分区在各个Feed设备中的分布情形，每个Feed数据表在各个Feed设备中的分布情形，Feed数据表与其所属的分区之间的对应关系，以及所有Feed设备的状态。

17.根据权利要求11所述的方法，其中所述方法进一步包括：

提供对所述Feed设备的即插即用的支持。

18.根据权利要求11所述的方法，其中所述方法进一步包括：

当一个新的Feed设备被加入所述系统时，由该Feed设备报告它的状态，从而新的Feed设备加入的事件被通知给其它Feed设备和网关。

19.根据权利要求11所述的方法，其中所述方法进一步包括：

提供支持表述性状态转移的应用编程接口。

20.根据权利要求11所述的方法，其中所述对Feed数据的操作包括对Feed数据的创建、更新、查询、移除操作。

Images