乔杰华　刘亚卓　翟晓宁

【摘 要】本文以一个定向新闻采集平台的实现为例，详细说明了分布式内容聚合平台结构的设计方案，并针对分布式特点在具体开发实现过程中涉及的资源结构、快照查重、标识确定、消息同步、以及数据库设计等技术要点进行了阐述，对同类信息系统的研究开发有一定的借鉴参考作用。

【关键词】聚合；采集；分布式；消息

1 架构设计

聚合平台的主体功能包括三项：一是，对已定义的新闻资源进行采集，提取新闻的URL列表；二是，根据列表逐一采集新闻内容页，提取需要的信息数据（标题、发布时间、正文）；三是，如果有需要，则对新闻相应的图片进行采集。这里提到的新闻资源是指包含有多个新闻内容页链接的列表，比如新浪网的新闻频道首页。容易想到，平台按照功能划分可设计三类功能节点：资源采集、内容采集和图片采集，此外我们再加入资源产生和图片服务两种节点。严格来说，图片服务不属于新闻采集的范畴，它是为前端用户提供图片服务的，将其纳入本文内容是为了完整说明一个新闻生成的完整过程。

如图1所示，生产运行过程中，资源产生节点从资源数据库中取出已定义的资源并作为任务告知资源采集节点，内容采集节点的任务来自资源采集节点在资源中提取的新闻链接列表，而图片采集节点的需求驱动则来自内容采集节点的在采集内容时发现的图片，最后圖片采集成功后会将图片部署到图片服务节点，任务数据（或事件）将依次在五种节点间单向传递。新闻的生成在内容采集节点发生，并由其存入新闻数据库，而新闻是否有图片可用则由图片服务节点来决定，这是因为只有图片部署完成可用才能说明新闻的图片是可用有效的，所以需要图片服务节点完成部署后对新闻数据库进行“回写”以标识新闻的图片可用性。

图1 新闻聚合采集平台拓扑结构图

由于新闻采集本身并没有快速实时响应的要求，所以各节点间的通知传递选用异步的消息方式，与同步方式（如RPC）相比消息方式能够方便实现每一类节点的集群式扩展，即每节点功能可以实现集群化。这种分布式的结构有三个明显优点：一是，功能分割实现了模块或节点间的松耦合；二是，能过节点扩展能够应对高负载需求；三是，避免单点故障。

2 实现要点

2.1 资源结构

一个资源对象当然包括有URL、分类、标签等要素，但更重要的是应有如何提取新闻列表的信息。传统搜索引擎会面对各式各样的网页内容，所以通常会使用一些复杂的算法模型提取所需要的标题内容等信息，对无效信息（如广告）进行降噪处理。而定向采集的资源内容结构性稳定，所以分析提取信息可以使用一些DOM工具来实现，可以将新闻列表的XPATH描述作为提取要素，采集以此来解析资源页面中的新闻列表。

2.2 资源“快照”

为了将资源中最新发布的新闻采集同步到本地，通常每天会一次或多次采集资源，但对有些更新不频繁的资源的采集就会造成节点的“空载”运行，这包括资源采集节点的扫描解析，内容采集节点对新闻列表的逐一采集，而这些新闻实际上全是已采过的“旧闻”。因此设计资源“快照”，资源采集节点对从资源中的列表进行“拍照”并与上一次的拍照结果进行比较，如果未发生变化则表明列表无更新也就无需进一步采集。

2.3 标识问题

首先，如何识别新闻是否已被采集过。“快照”检测只是资源列表级的，当一个列表有部分更新时就需要有识别某个具体新闻是否已被采集过以避免复采，显然新闻的URL是最好的标识，可以对其进行摘要（如HASH、MD5）取值建立索引快速检查新闻是否已存在。其次，如何为新闻生成全局性ID。用URL的摘要值不适合做新闻的ID，毕竟摘要值有重复可能，再者如果后续需要使用Hadoop和Mahout等大数据工具进行推荐等挖掘计算如用纯数字的ID会更方便。容易想到用时间戳来设计ID，但在集群环境下多个节点产生ID也会有冲突可能，因而给每个节点配置一个ID前缀，节点产生的ID再冠以前缀可以避免ID冲突。

2.4 消息与同步

节点间的消息通信可以用rabbitmq、kafka等高效的消息平台，值得提出的是资源产生、资源采集、内容采集和图片采集节点之间的消息应该选用单队列topic主题模式，因为一个采集任务被任意节点执行都是无差别的，但图片采集和图片服务节点间则应该用广播方式传递消息，因为每一张图片都需要被部署到所有图片服务节点上。

2.5 数据库设计

聚合采集平台用于存放新闻的数据库可以选用一些常规的数据库（如Mysql），因为仅供挖掘或推荐平台提供数据源而不是直接面向用户服务。但如果采集的数据量或集群规模很大则可以考虑分库，多个节点甚至单个节点使用一个数据库。实际上，对于采集平台直接以文本文件方式存放数据（以ID作为文件名）也是可行的，而且这样还可以大幅提升存写速度，只是在存放结构上需要根据数据的使用需求进行设计，比如可以选用多级散列目录存放实现根据ID快速定位文件。

3 结论

本文限于篇幅原因还有较多采集中的细节未能提及，比如针对各种资源中不同的列表结构（列表、相对、表格等形式）该如何定义XPATH以提取有效信息，又比如该如何设计消息的结构以提升整个平台的工作效能，再比如资源产生节点如何实现集群化以及对于一些“连续”性资源（比如有“下一页”）又如何进行自动翻页采集历史数据等技术点都没能在文中说明。同时，对于一个完善的信息流处理平台来说还有些应该具备的功能还未考虑到，比如平台运行的在线监控以及对各类节点所产生日志的分析挖掘等等，这些有待于下一步进行研究和实现。

【参考文献】

[1]邓胜利.信息聚合服务的发展与演变研究.情报资料工作，2012.

[2]Web3.0技术.https：//baike.baidu.com/item/web%203.0/2587429？fr=aladdin.endprint