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

专利名称：用于管理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的介绍可以看出，随着越来越多的传统网站正在采用 Web2.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示出的系统中的Feedi殳备(活动节点) 的内部结构的示意图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设备可以具有大于400 GB的硬盘，以及大于2 GB的存储器。
在简要介绍了 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数据的创建、查询等操作，
监^L节点140也可以是通用的计算机，例如纽约Armonk的国际商业 机器公司(IBM)的低端的X-series服务器，用于监视所有活动节点110 的状态并存储这些状态，定期对活动节点IIO进行检查，将诸如加入节点或移除节点这样的事件通知网关节点130和所有的活动节点110，以及存 储Feed数据(以及Feed表、分区)在各个节点上的分布状况。
通过上述这样组成的系统，可以将Feed数据分布到多个活动的Feed 设备(活动节点)110上，这些数据可以在需要时被检索。在本发明的一 个实施例中，这些Feed数据被复制若干份并存储在不同的活动节点110 上，从而确保了系统的健壮性。并且这些Feed设备的状态被监视，以确保 及时发现发生故障或被移除的设备或新加入的设备。
下面将结合图2A和2B具体描述根据本发明实施例的用于管理Feed 数据的系统的体系结构和运行模式。如图2A所示，客户机150向网关节 点(以下简称为网关)130提交对Feed数据的操作请求，该请求可以是 Feed数据的创建请求、查询请求或移除请求等。在接收到操作请求后，网 关130从多个活动节点110中确定一个临时主节点115,此时所有其它节 点成为从属节点。这些活动节点IIO在功能上都是相同的，用于执行Feed 数据的创建和查询等任务。例如，网关130可以根据各个活动节点IIO上 的负载来确定临时主节点115，该临时主节点115上的负载相对较轻，而 其它的活动节点IIO成为从属节点。各个活动节点IIO上的负载可以通过 访问监视节点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 传送给客户4几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数据的活动节点IIO调用自身的Feed数据移除功能 而将相应的Feed数据移除。在移除了 Feed数据之后，所述活动节点110 向临时主节点115传送移除成功的消息，该消息作为对移除请求的响应被 临时主节点115传送给客户机150。
在本发明的一个实施例中，对于Feed数据的更新是通过系统自动完成 的。系统可以定期地查询所存储的所有Feed数据的来源链接，如果发现了 已经被更新的Feed数据，则根据所述更新的Feed数据来更新系统中相应 节点上所存储的Feed数据。由于Feed数据可以被存储在Feed数据表中， 因此所述更新可以被添加到该Feed数据表中作为一个条目。本领域技术人 员可以理解，客户才几115也可以向网关130提交更新请求，则网关130响 应于该更新请求来执行对于Feed数据的更新过程。本领域技术人员可以理 解，活动节点110对于Feed数据的更新操作过程与处理查询请求、创建请 求的处理过程相类似，在此不再具体描述。
在图2A所示的系统中，监视节点140持续执行系统监视和管理的功 能，并向网关130和活动节点IIO提供所需的关于活动节点的负载情况和 存储数据分布的信息。监视节点140可以为一轻量级机器，从而节约系统图2B与图2A相类似，当客户机150再次向网关130提交另一操作请 求时，网关150从多个活动节点110中确定一个临时主节点115并将该操 作请求转发到该临时主节点115。由于系统中的任一活动节点110均有可 能成为临时主节点115，只要该节点上的负载相对较低。因此，图2B示出 了网关150将另一个活动节点确定为临时主节点115。根据请求的类型不 同，临时主节点115通过查询监4见节点140而确定相应的活动节点110来 执行对于Feed数据的创建、查询和移除等过程。这些都与图2A所述内容 相同。
在本发明的一个实施例中，如图2A与图2B所示的通过Feed设备来 管理Feed数据的系统可以向客户机150提供支持REST (RESTful)的应 用编程接口 (API) 。 REST (Representational State Transfer,表述性状 态转移)是一种基于Web的体系结构，其核心特征是组件之间有一个统一 的接口。通过在接口上应用通用性的软件工程原则，整体的系统体系结构 得到了简化，交互的可见性也得到了改善。关于REST体系结构的具体细 节，请参见Roy Thomas Fielding博士的论文"Architectural Styles and the Design of Network-based Software Architectures"，该文档可以在因特网 URL: http:〃www.ics.uci.edu/ fielding/pubs/dissertation/top.htm找至l]。
在本发明的实施例中，支持REST的API可以包括以下语法。
1) Feed创建
POST http:〃[hostl/feeds;
其参数包4舌isScratch， feedContent， feedURL， scratchURL, interval, snapshot,并且返回人类可读的URL (统一资源定位符) http:〃[hostI/feeds/url=someUrl。 2 ) Feed更新
PUT http:〃[host]/feeds/url=.";
其可以定期自动执行。 3) Feed移除DELETE http:〃[host/feeds/url=".;
DELETE http:〃hostI/feeds conl=vl&con2=v2。
4) Feed查询
GET http:〃[host/feeds/url=someUrl; GET http:〃hostI/feeds conl=vl&con2=v2;
其^t包括url (对应于Feed的URL) 、 author (对应于〈author〉元 素)、updated (对应于〈updated〉元素)等等，并返回XML (可扩展标记 语言)格式的数据。
5) Feed搜索获取
http:〃[host/feeds searchCon=someExpression; 其返回XML格式的lt据。
根据本发明的支持REST的API,可以向客户机150的用户提供简明直
观的结果。
在描述了根据本发明实施例的用于管理Feed数据的系统的体系结构 和运行模式之后，图3详细描述图2A和2B示出的系统中的Feed设备(活 动节点)110的内部结构的示意图，所述活动节点IIO可以是系统中的任 意一个活动节点。如图3所示，图3左边的缩略图表示活动节点110在所 述系统中的位置。活动节点110包括应用服务器300、数据库360和系统 环境370。每个活动节点110的应用服务器300可以是本领域已知的任意 应用服务器，例如纽约Armonk的国际商业才几器乂^司(IBM)的Project Zero。应用服务器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 数据中的〈autho1^、 <url>、 〈updated〉三个维度来进行分区的情形中，其 中〈authoi^代表作者维度，<111"1>代表URL维度，〈updated〉代表更新时 间维度，提取Feed数据中的字段值，经过哈希算法后产生维度码，再将所 得的维度码联合进行进一 步的哈希算法而得到分区码。
例如，在一个Feed数据中所包含的字段为<author>: Torn, <url>: www.sina.com.cn/blogs， <updated>: 2008.4.26。
author的哈希值也就是维度码是12434332B;url的哈希值也就是维度码是1233435333;
updated的哈希值也就是维度码是3112345453。
接着将1243433223、 1233435333、 3112345453进行进一步的哈希算法 而得到一个数值，该数值对应的是该Feed数据的分区码，例如1。通过这 样的计算方式，可以将所有的表划分为若干个分区，并使得每一分区具有 多个维度。例如，如以下表l所示。
作者维度URL维度更新时间维度分区码
124343322312334353333112345453
1243433224123343533431123454542
1243433225123343533531123454553
1243433226123343533631123454564
表l
以下通过示例来简要说明Feed表的多维度分区机制的效果。图5示出 了分区在活动节点上的示例性分布，所述分区各自包括若干Feed表。例如， 如图5所示，分区l包4舌表l-3，分区2包括表4-7，分区3包4舌表8-10， 而分区4包括表11。表1-11被离散地分布在节点1-3上。从而，当查询特 定Feed表(Feed数据)的时候，可以通过已知的维度(查询条件)首先 确定该Feed表所属的分区，然后从所确定的分区中继续查询该表，从而显 著提高了查询的效率。同一个分区可以跨多个活动节点存储，也就是说， 该分区中的多个Feed表可以被存储在不同的活动节点上。
应当注意，理论上，分区的数量可以从l直到等同于Feed表的数量。 分区的数量越多，则属于每个分区中的Feed表的数量就越少，这样可能会 影响查询分区的速度；而分区的数量越少，则属于每个分区中的Feed表的 数量就越多，这样可能会影响在每个分区中查询Feed表的速度。因此，分 区的数量应该保持为一个适当的值，从而可以使得分区数量和每个分区中 的Feed表的数量保持均衡，其中分区的数量可以是可配置的。这可以通过 对维度的精确性控制来实现，也即，控制对于维度码进行计算的哈希算法。 例如，为了适当减少分区的数量，可以将作者维度中的Tom和Thomas计算为同样的维度码，或者可以将更新日期维度中在同一周(而并非同一
天)更新的Feed数据都计算为同样的维度码。
此外，为了确保根据本发明实施例的用于管理Feed数据的系统的健壮 性，还提供了 一种对于Feed数据的复制机制，其将所有的Feed表(Feed 数据)复制若干份，并存储在不同的活动节点110上，从而当某一节点发 生故障或者被移除时，仍然可以查询到所需的Feed表。根据所述复制机制， 基于预先定义的复制系数(例如为2)，将所有的Feed数据复制两遍，其 中Feed数据被复制的次数等于复制系数，从而得到另外两份备份。例如， 某一Feed表l可以被复制为表l，和表l"，它们具有与表l完全相同的 内容，但是这三个表将被分布在不同的活动节点110上。当这三个表中之 一的内容被创建、更新或删除时，这三个表均保持为一致。因此当查询该 Feed表时，通过查询任一表均可以得到所需的数据。当存储了一个表(例 如表1)的活动节点发生故障或被移除时，对于其它活动节点上的另外两 个表(表1，和表1")的CRUD (创建、读取、更新、删除)操作将不 会受到影响。而当该活动节点被修复或者被重新加入系统时，将再次将最 新的表l，或表l"复制到该节点作为表l，从而这三个表仍然保持为一致。
注意，所述复制系数是预先定义的。复制系数越大，每个Feed表被复 制的次数就越多，从而整个系统的健壮性就会越高。但是，复制系数过大 会导致大量重复的Feed表的备份占用大量的存储空间，从而增加了系统的 成本。因此，对该复制系数的定义需要兼顾系统成本和对系统健壮性的要求。
回到图3，每个活动节点110还包括系统环境370。系统环境370可以 包括使活动节点IIO可以正常运行的操作系统、其它应用程序以及特定的 配置(诸如对应用服务器300和数据库360的支持)。用户可以通过系统 环境370对活动节点IIO进行访问和操作。可选地，用户可以通过系统环 境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可以定期地向所有活 动节点IIO发送询问消息，并将在预定时限内没有从其收到相应响应的一 个或更多活动节点IIO确定为故障节点，其中监祸4莫块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表复制)之后通知监^L节点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表。4艮据本发明的一个实施例，可以基于预先定义的复 制系数，将要创建的Feed表复制若干次，并存储到不同的活动节点上，其 中复制次数等于复制系数。然后在步骤760，该节点将创建成功的消息传 送到临时主节点，并由临时主节点将该消息作为创建请求的响应传送到客户机。
如果在步骤740，确定所述请求不是创建请求，则该请求是查询请求 或者其它请求，诸如移除请求。则所述方法进行到步骤"5，所涉及的活 动节点在其上执行查询请求或移除请求。然后在步骤MO,将所查询的结果或者移除成功的消息传送到临时主节点，并由临时主节点将所查询的结 果或者移除成功的消息作为查询请求或移除请求的响应传送到客户机。
任一活动节点对于Feed数据的创建、更新和移除都需要相应地通知监 视节点，并由监视节点更新其中的数据库中的相应内容。
以上详细描述了才艮据本发明一个实施例的用于管理Feed数据的系统 和方法。如本领域普通技术人员可以了解的，本发明可以体现为方法、系 统和/或计算机程序产品。因此，本发明可以呈现为完全硬件实施形式、完 全软件实施形式或者软件和硬件组合实施形式。此外，本发明可以被呈现 为在机器可读媒体上包括的计算机程序产品，机器可读媒体上存储了用于 对计算机系统进行编程以执行根据本发明的过程的机器可执行程序指令。 这里所使用的术语"机器可读媒体"包括向计算机系统提供用于执行的指 令的任意媒体。这种媒体可以采用多种形式，包括但是不局限于非易失 性媒体、易失性媒体和传输媒体。非易失性媒体的常见形式例如包括软盘、 软磁盘、硬盘、磁带或者任何其它磁媒体、光盘ROM (CD-ROM)或者 任何其它光媒体、打孔卡或者任何其它带有孔图案的物理媒体、可编程 ROM ( PROM)、可擦写PROM ( EPROM)、电EPROM ( EEPROM)、 闪速存储器、任何其它存储芯片或者盒式磁带(cartridge)、或者计算机 系统可以读取并适合存储指令的任何其它媒体。
适于存储和/或执行程序代码的数据处理系统将包括直接地或通过系 统总线间接地耦合于存储器单元的至少一个处理器。存储器单元可以包括 在程序代码的实际执行期间使用的局部存储器、海量存储装置、以及高速 緩沖存储器，该高速緩沖存储器提供了至少某种程序代码的临时存储以便 减少在执行期间必须从海量存储装置检索代码的次数。
此外，可以理解，方框图和/或流程图中的每个方框以及方框图和流程 图中的一些方框的组合可以用一些计算机程序指令实现。这些计算机程序 指令可以提供给一通用计算机、专用计算机或其它可编程数据处理设备的 处理器以产生一机器，使得这些指令通过计算机或其它可编程数据处理设 备的处理器的执行创建用于实现在方框图和/或流程图内或者方框内所指定的功能的装置。
尽管已经参考优选实施例具体地示出并描述了本发明，但其不是为了 以公开的形式穷举或限制本发明。对于本领域的普通技术人员，可以在形 式上和细节上进行各种改变而不会背离本发明的精神和范围。选择并描述 了实施例是为了最好地解释本发明的原理和实际的应用，以及为了使本领 域的其它普通技术人员能够理解对于各种实施例的本发明，所述实施例具 有适合于预期的具体使用的各种修改。
权利要求
1.一种用于管理Feed数据的系统，所述系统包括网关，用于向多个Feed设备之一转发对所述Feed数据的操作请求；以及多个Feed设备，所述多个Feed设备之间采用对等方式相互连接和通信，其中接收到所述操作请求的主Feed设备和其它从属Feed设备协同工作，用于存储所述Feed数据，并根据所述操作请求来执行对Feed数据的操作。
2. 根据权利要求l所述的系统，其中每一个所述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. 根据权利要求l所述的系统，进一步包括监视节点，所述监视节点 包括监视模块，用于监视和接收系统内的所有Feed设备的状态； 通知模块，用于将加入新的Feed设备、Feed设备的状态改变、以及Feed设备发生故障的情形通知所述网关和其它Feed i殳备；重新平衡模块，用于在系统内加入新的Feed设备、Feed设备的状态改变、以及Feed设备发生故障时对系统内的所有Feed设备的负栽进行重新平衡；以及数据库，用于存储每个分区在各个Feed设备中的分布情形，每个Feed 数据表在各个Feed设备中的分布情形，Feed数据表与其所属的分区之间 的对应关系，以及所述系统中的所有Feed设备的状态。
8. 根据权利要求l所述的系统，其中所述系统支持所述Feed设备的 即插即用。
9. 根据权利要求8所述的系统，其中当一个新的Feed设备被加入所 述系统时，该Feed设备向所述监视节点报告它的状态，从而所述监视节点 存储此Feed设备的节点状态，并向所述系统中的其它Feed设备和网关通 知有新的Feed设备加入的事件。
10. 根据权利要求1所述的系统，其中所述系统提供支持表述性状态 转移的应用编程接口。
11. 一种用于管理Feed数据的方法，所迷方法包括 由网关向采用对等方式相互连接和通信的多个Feed设备之一转发对所述Feed数据的操作请求；以及由所述多个Feed设备中接收到所述操作请求的主Feed设备与所述多 个Feed设备中的其它从属Feed设备协同工作，用于存储所述Feed数据， 并根据所述操作请求来执行对Feed数据的操作。
12. 根据权利要求ll所述的方法，其中存储所述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. 根据权利要求ll所述的方法，其中所述方法进一步包括 监视和接收所有Feed设备的状态；将加入新的Feed设备、Feed设备的状态改变、以及Feed设备发生故 障的情形通知网关和其它Feedi殳备；在加入新的Feed设备、Feed设备的状态改变、以及Feed设备发生故 障时对所有Feed设备的负载进行重新平衡；以及存储每个分区在各个Feed设备中的分布情形，每个Feed数据表在各 个Feed设备中的分布情形，Feed数据表与其所属的分区之间的对应关系， 以及所有Feed设备的状态。
17. 根据权利要求ll所述的方法，其中所述方法进一步包括 提供对所述Feed设备的即插即用的支持。
18. 根据权利要求ll所述的方法，其中所述方法进一步包括 当一个新的Feed设备被加入所述系统时，由该Feed设备报告它的状态，从而新的Feed设备加入的事件被通知给其它Feed设备和网关。
19. 根据权利要求ll所述的方法，其中所述方法进一步包括 提供支持表述性状态转移的应用编程接口 。
20. 根据权利要求ll所述的方法，其中所述对Feed数据的操作包括 对Feed数据的创建、更新、查询、移除操作。
全文摘要
一种用于管理Feed数据的系统和方法。所述系统包括网关，用于向多个Feed设备之一转发对所述Feed数据的操作请求；以及多个Feed设备，所述多个Feed设备之间采用对等方式相互连接和通信，其中接收到所述操作请求的主Feed设备和其它从属Feed设备协同工作，用于存储所述Feed数据，并根据所述操作请求来执行对Feed数据的操作。利用本发明的系统和方法，可以获得高效的Feed数据表的多维度分区，充分的健壮性，即插即用的高扩展性，简单的应用编程接口(API)以及对Feed数据的原生存储支持。
文档编号H04L29/08GK101594377SQ200810098478
公开日2009年12月2日 申请日期2008年5月28日 优先权日2008年5月28日
发明者波 刘, 宁 吕, 徐兆伟, 弘 戴, 毛新生, 王庆法, 王晓昱 申请人:国际商业机器公司