CN106874424A - 一种基于MongoDB和Redis的网页数据采集处理方法及系统 - Google Patents

Abstract

本发明公开了一种基于MongoDB和Redis的网页数据采集处理方法及系统，该方法首先设定网页下载请求的格式；然后为下载请求分配全局唯一ID；依照配置中心预置的对应业务负载均衡策略，完成对请求的转发；采用MongoDB的副本集架构将请求按业务类型分库分表。将请求写入MongoDB数据库，并用id字段覆盖MongoDB默认的_id索引，对ts字段建立TTL索引，同时将id、biz、ts三个字段转json格式后，利用lpush操作压入Redis消息队列；最后各下载服务器一直保持监听Redis消息队列，轮询提取请求并下载解析网页，获取目标数据记录入库。本发明结合Redis内存消息队列和Mongodb副本集架构实施的分布式网页下载请求存储方案，构建成本低、简单实用。

Description

一种基于MongoDB和Redis的网页数据采集处理方法及系统

技术领域

本发明涉及数据采集技术领域，特别涉及一种基于MongoDB和Redis的网页数据采集处理方法及系统。

背景技术

当前处于一个信息爆发增长的数据时代，专业化的数据分析和深度挖掘，不断孕育出巨大商机。越来越多企业由传统模式的依靠直觉和经验判断，转向依靠大数据分析和预测来制定企业战略决策，各企业对数据的获取需求愈加强烈。特别地，对于那些并不直接生产大数据的互联网中小企业而言，通过网络爬虫技术实施有针对性、行业性、精准性的数据采集，间接建立企业的“大数据战略”体系，就显得尤为重要。不仅能大大降低企业大数据信息建设的成本，更能满足企业业务发展要求，充分利用网络数据价值，达到利益更大化。

发明内容

本发明的目的在于针对现有技术的不足，提供一种基于MongoDB和Redis的网页数据采集处理方法及系统，便于企业低成本、高效率建立满足自身业务发展需求的数据仓库。

本发明的目的是通过以下技术方案来实现的：一种基于MongoDB和Redis的网页数据采集处理方法，该方法包括以下步骤：

(1)设定网页下载请求的格式：请求唯一标识符id、业务类型biz、时间戳ts、请求实体内容data、消息处理状态flag；

(2)为下载请求分配全局唯一ID，对应下载请求的id字段；

(3)基于分布式协同服务，在配置中心预置各业务的网页请求解析规则映射表、持久化节点列表、MongoDB数据库名、集合名、集合水平拆分数、Redis消息队列名。

(4)依照配置中心预置的对应业务负载均衡策略，完成对请求的转发：首先根据下载请求的业务类型biz，从配置中心获取该biz预先定义的持久化节点列表、MongoDB数据库名、集合名、集合水平拆分数、Redis消息队列名，再结合对唯一标识符id求模取余策略，将请求持久化到MongoDB相应的数据库和集合，同时在Redis消息队列记录此条请求；

(5)采用MongoDB的副本集架构将请求按业务类型分库分表。将请求写入MongoDB数据库，并用id字段覆盖MongoDB默认的_id索引，对ts字段建立TTL索引，同时将id、biz、ts三个字段转json格式后，利用lpush操作压入Redis消息队列；

(6)各下载服务器一直保持监听Redis消息队列，轮询提取请求并下载解析网页，获取目标数据记录入库。

进一步地，所述步骤6具体为：首先利用rpop或其阻塞版操作brpop从队列弹出请求，再结合id、biz和ts这三个字段组合成查询过滤条件，然后调用MongoDB的原子操作findAndModify查询对应的MongoDB持久化节点的数据库和集合，即可得到完整的请求内容，根据该请求附带的解析规则映射表，解析页面获取目标数据记录入库。

进一步地，在步骤1-步骤6中，实时监控网页下载请求的生成速率；监控服务节点的健康状况：包括数据库存储容量、内存使用率、慢查询操作，以及内存消息队列的内存占用、消息积压程度等，当遭遇节点故障或服务性能下滑超过设定阈值时，及时以短信或邮件方式发送报警信息；监控下载请求的处理速率，发现请求积压严重或无法在计划时间内完成处理时，及时增加处理节点动态扩容。

进一步地，所述步骤2中，使用SnowFlake为下载请求分配全局唯一ID。

一种基于MongoDB和Redis的网页数据采集处理系统，该系统包括以下模块：全局ID生成器模块、请求路由转发模块、配置中心、持久化模块和消息队列模块；

所述全局ID生成器模块为下载请求分配全局唯一ID，对应下载请求的id字段；

所述配置中心基于分布式协同服务，预置各业务的网页请求解析规则映射表、持久化节点列表、MongoDB数据库名、集合名、集合水平拆分数、Redis消息队列名；

所述请求路由转发模块依照配置中心预置的对应业务负载均衡策略，完成对请求的转发：首先根据下载请求的业务类型biz，从配置中心获取该biz预先定义的持久化节点列表、MongoDB数据库名、集合名、集合水平拆分数、Redis消息队列名，再结合对唯一标识符id求模取余策略，将请求持久化到MongoDB相应的数据库和集合，同时在Redis消息队列记录此条请求；

所述持久化模块采用MongoDB的副本集架构将请求按业务类型分库分表；将请求写入MongoDB数据库，并用id字段覆盖MongoDB默认的_id索引，对ts字段建立TTL索引；

所述消息队列模块：在请求生成者端，将请求持久化到MongoDB同时，将id、biz、ts三个字段转json格式后，利用lpush操作压入Redis消息队列。在请求消费者端，各下载服务器一直保持监听Redis消息队列，利用rpop或其阻塞版操作brpop从队列弹出请求，再结合id、biz和ts这三个字段组合成查询过滤条件，然后调用MongoDB的原子操作findAndModify查询对应的MongoDB持久化节点的数据库和集合，即可得到完整的请求内容，根据该请求附带的解析规则映射表，解析页面获取目标数据记录入库。

进一步地，该系统还包括服务监控模块，该模块实时监控网页下载请求的生成速率；监控服务节点的健康状况：包括数据库存储容量、内存使用率、慢查询操作，以及内存消息队列的内存占用、消息积压程度等，当遭遇节点故障或服务性能下滑超过设定阈值时，及时以短信或邮件方式发送报警信息；监控下载请求的处理速率，发现请求积压严重或无法在计划时间内完成处理时，及时增加处理节点动态扩容。

本发明的有益效果是：本发明结合Redis内存消息队列和Mongodb副本集架构实施的分布式网页下载请求存储方案，构建成本低、简单实用，具体表现在：1.可支撑每日千万量级请求的高效可靠存储；2.服务端自动执行过期请求清理，避免了消息积压，提升请求处理效率。3.具备快速透明的消息查询跟踪功能，这是按业界较常用的内存消息队列或消息中间件存储方案，是难以做到的。

附图说明

图1是本发明实施例的网页下载请求的主要流程示意图；

图2是请求路由转发模块执行流程示意图；

图3是持久化模块结构示意图；

图4是下载服务器处理下载请求流程示意图。

具体实施方式

下面结合附图及具体实施方式对本发明作进一步详细说明。

为方便开展后续介绍，先阐述自定义的网页下载请求各字段格式设计：

1.字段名：id，数据类型为长整型，表示请求唯一标识符。通常由全局ID生成服务分配；一方面，可以根据该字段按指定负载均衡策略将该请求转发到指定存储节点和消息队列，另一方面，利用该字段覆盖MongoDB默认的_id索引，当按该字段查询和定位消息处理记录状态时，效率极高。

2.字段名：biz，数据类型为字符串，记录该消息由何种业务产生。对于请求的生产者，查询注册中心获取该类业务的消息队列各服务节点，路由到指定的消息队列；对于消费者，根据该字段可以筛选和处理其感兴趣的业务消息。

3.字段名：ts，数据类型为时间戳,记录消息写入队列时刻。特别地，通过在该字段上建立TTL索引，可以将那些超过预设时间但未被处理的消息交给MongoDB服务器自动清理掉，避免消息大量堆积；另一方面，请求消费者也可以根据该索引字段筛选或过滤消息。

4.字段名：data，数据类型为字节数组，真正的请求实体内容(如：页面Url，解析规则在配置中心对应提取编号、http请求头请求参数等)，通常为了提高网络传输速率和减少消息耗用的存储空间，存储请求时，会采用某种序列化机制，将请求实体内容转化为字节数组。而在提取到请求后，将该字段的内容反序列化为可视对象。

5.字段名：flag，数据类型为整型，记录当前消息处理状态。通常持久化请求时状态默认赋值为0,当请求被处理后，状态同步更新为1。一般使用0和1两种状态即可。特定业亦可定义多种取值，协定消息处理的不同状态。

基于MongoDB和Redis这两种在互联网公司广泛应用的开源NoSQL数据库，构建一套简单灵活的网页数据采集方法体系。这一方法体系主要包含六个模块：全局ID生成器模块、请求路由转发模块、配置中心、持久化模块、消息队列模块、服务监控模块。完整的网页数据采集流程示意图如图1所示：首先，指定需要抓取的网页链接及相对应的解析规则说明。为了便于后期追踪和查询指定请求处理记录，通常会由全局ID生成服务，分配该请求一个唯一ID，然后将其包装为网页下载请求。之后，请求路由转发模块会根据该请求的业务类型，依照指定负载均衡策略，将请求持久化到数据库。同时，存储请求的部分关键字段到消息队列。值得说明的是，为了避免请求的生成者与请求执行者相耦合，并考虑到后期动态扩展要求，这一步并未直接将网页下载请求分配给指定的下载服务器。与此同时，各下载服务器一直保持监听消息队列和数据库的变更，定时轮询提取请求并下载网页，最后根据该请求附带的解析规则映射表，解析页面获取目标数据记录入库。

各模块具体介绍如下：

1.全局ID生成器模块：此模块用于给每个下载请求分配一个全局唯一ID，对应着下载请求的id字段。常用的全局ID生成方案包括32位长度的UUID、MongoDB采用的ObjectId、Twitter发明的SnowFlake算法、Flickr基于MySQL主键自增ID。在高并发大数据量的情况下，建议使用SnowFlake方案，性能非常突出。

2.请求路由转发模块：这一模块的主要功能类似关系型数据库中间件代理，基于客户端分库分表，以便降低单节点、单库、单表压力，提升存储和查询性能。具体应用时，依照配置中心预置的对应业务负载均衡策略(一致性哈希、简单求模取余等)，完成对请求转发。一次简单的请求路由转发流程如图2所示：首先根据下载请求biz字段定义的类型，从配置中心获取该biz预先定义的持久化节点列表、MongoDB数据库名、集合名、集合水平拆分数、Redis消息队列名，再结合对id字段求模取余策略，将请求持久化到MongoDB相应的数据库和集合，同时在Redis消息队列记录此条请求。

3.配置中心：基于Redis、etcd或Zookeeper等分布式服务，存储各业务类型的网页请求解析规则映射表，统一注册和配置相关业务的服务节点、持久化节点列表、消息队列列表。支持动态修改配置而不用重启已部署线上应用程序。

4.持久化模块：基于MongoDB,采用其副本集(Replica Sets)架构，并按业务类型分库、拆分集合，提供数据存储的整体高可用性，如图3所示。使用该技术能够将数据副本保存到多台服务器，当一台或多台服务器故障时，系统会自动切换到副本集中的其他服务器，保证了数据安全性和服务的容错性。实际持久化请求时，会用请求id字段覆盖MongoDB默认的_id索引，并对ts字段建立TTL(time-to-live)索引。TTL索引支持对每个文档预先设置超时时间,这样做的好处是：当文档达到设置的老化程度后，MongoDB服务器会自动将其删除。默认情况下，MongoDB服务器每隔一分钟开展一次TTL索清理，应用程序无需提供额外编码就能避免了消息堆积，极大地方便了开发人员。

5.消息队列模块：利用Redis原生提供的list数据结构及lpush和rpop、brpop等原子操作构建而成。由于是基于内存存储，为降低内存占用率，并未将请求全部字段写入。实际使用中：请求生成者端，将完整的请求持久化到MongoDB同时，仅将id、biz、ts三个字段转json格式后，利用lpush操作压入队列；在请求消费者端，先利用rpop或其阻塞版操作brpop从队列弹出请求，再结合id、biz和ts这三个字段组合成查询过滤条件，然后调用MongoDB的原子操作findAndModify查询对应的MongoDB存储节点的数据库和集合，即可得到完整的请求内容，流程示意图如图4所示。由于Redis获取的数据直接源于内存，而查询MongoDB又能利用上其主键id索引，故这两步操作即便以事务方式执行，亦可获得极高的执行效率。

6.服务监控模块：主要监控三个方面，1.以不同的时间精度(1秒、5秒、1分钟等)监控网页下载请求的生成速率，当请求生成过快时以便能及时调控；2.各服务节点监控状态汇报，包括数据库存储容量、内存使用率、慢查询操作，以及内存消息队列的内存占用、消息积压程度等，当遭遇节点故障或服务性能下滑超过设定阈值时，能及时以短信或邮件方式发送报警信息；3.以不同的时间精度(1秒、5秒、1分钟等)监控下载请求的处理速率，一旦发现请求积压严重或无法在计划时间内完成处理，则及时增加处理节点动态扩容。

Claims (6)

1.一种基于MongoDB和Redis的网页数据采集处理方法，其特征在于，该方法包括以下步骤：

(1)设定网页下载请求的格式：请求唯一标识符id、业务类型biz、时间戳ts、请求实体内容data、消息处理状态flag；

(2)为下载请求分配全局唯一ID，对应下载请求的id字段；

(3)基于分布式协同服务，在配置中心预置各业务的网页请求解析规则映射表、持久化节点列表、MongoDB数据库名、集合名、集合水平拆分数、Redis消息队列名。

(4)依照配置中心预置的对应业务负载均衡策略，完成对请求的转发：首先根据下载请求的业务类型biz，从配置中心获取该biz预先定义的持久化节点列表、MongoDB数据库名、集合名、集合水平拆分数、Redis消息队列名，再结合对唯一标识符id求模取余策略，将请求持久化到MongoDB相应的数据库和集合，同时在Redis消息队列记录此条请求；

(5)采用MongoDB的副本集架构将请求按业务类型分库分表。将请求写入MongoDB数据库，并用id字段覆盖MongoDB默认的_id索引，对ts字段建立TTL索引，同时将id、biz、ts三个字段转json格式后，利用lpush操作压入Redis消息队列；

(6)各下载服务器一直保持监听Redis消息队列，轮询提取请求并下载解析网页，获取目标数据记录入库。

2.根据权利要求1所述的一种基于MongoDB和Redis的网页数据采集处理方法，其特征在于，所述步骤6具体为：首先利用rpop或其阻塞版操作brpop从队列弹出请求，再结合id、biz和ts这三个字段组合成查询过滤条件，然后调用MongoDB的原子操作findAndModify查询对应的MongoDB持久化节点的数据库和集合，即可得到完整的请求内容，根据该请求附带的解析规则映射表，解析页面获取目标数据记录入库。

3.根据权利要求1所述的一种基于MongoDB和Redis的网页数据采集处理方法，其特征在于，在步骤1-步骤6中，实时监控网页下载请求的生成速率；监控服务节点的健康状况：包括数据库存储容量、内存使用率、慢查询操作，以及内存消息队列的内存占用、消息积压程度等，当遭遇节点故障或服务性能下滑超过设定阈值时，及时以短信或邮件方式发送报警信息；监控下载请求的处理速率，发现请求积压严重或无法在计划时间内完成处理时，及时增加处理节点动态扩容。

4.根据权利要求1所述的一种基于MongoDB和Redis的网页数据采集处理方法，其特征在于，所述步骤2中，使用SnowFlake为下载请求分配全局唯一ID。

5.一种基于MongoDB和Redis的网页数据采集处理系统，其特征在于，该系统包括以下模块：全局ID生成器模块、请求路由转发模块、配置中心、持久化模块和消息队列模块；

所述全局ID生成器模块为下载请求分配全局唯一ID，对应下载请求的id字段；

所述配置中心基于分布式协同服务，预置各业务的网页请求解析规则映射表、持久化节点列表、MongoDB数据库名、集合名、集合水平拆分数、Redis消息队列名；

所述请求路由转发模块依照配置中心预置的对应业务负载均衡策略，完成对请求的转发：首先根据下载请求的业务类型biz，从配置中心获取该biz预先定义的持久化节点列表、MongoDB数据库名、集合名、集合水平拆分数、Redis消息队列名，再结合对唯一标识符id求模取余策略，将请求持久化到MongoDB相应的数据库和集合，同时在Redis消息队列记录此条请求；

所述持久化模块采用MongoDB的副本集架构将请求按业务类型分库分表；将请求写入MongoDB数据库，并用id字段覆盖MongoDB默认的_id索引，对ts字段建立TTL索引；

所述消息队列模块：在请求生成者端，将请求持久化到MongoDB同时，将id、biz、ts三个字段转json格式后，利用lpush操作压入Redis消息队列。在请求消费者端，各下载服务器一直保持监听Redis消息队列，利用rpop或其阻塞版操作brpop从队列弹出请求，再结合id、biz和ts这三个字段组合成查询过滤条件，然后调用MongoDB的原子操作findAndModify查询对应的MongoDB持久化节点的数据库和集合，即可得到完整的请求内容，根据该请求附带的解析规则映射表，解析页面获取目标数据记录入库。

6.根据权利要求5所述的一种基于MongoDB和Redis的网页数据采集处理系统，其特征在于，还包括服务监控模块，该模块实时监控网页下载请求的生成速率；监控服务节点的健康状况：包括数据库存储容量、内存使用率、慢查询操作，以及内存消息队列的内存占用、消息积压程度等，当遭遇节点故障或服务性能下滑超过设定阈值时，及时以短信或邮件方式发送报警信息；监控下载请求的处理速率，发现请求积压严重或无法在计划时间内完成处理时，及时增加处理节点动态扩容。