采集任务监控采集队怎么找

转载

误会一场 2024-04-30 19:33:37

文章标签 采集任务监控内存分配数据库断点续传 文章分类 运维

采集配置模块:

管理单任务配置文件和蜘蛛配置文件, 比较繁琐, 没有太多难点.

采集内核模块:

URL管理模块-

因为采集过程需要知道几个URL队列, 如已采集队列, 待采集队列, 采集去重队列.

已采集队列负责已经抓取到的URL列表.

待采集队列负责已经发现, 等待采集的URL列表.

采集去重队列负责已采集和已经发现的URL列表集合, 这样确保不重复收集URL.

咱们目前采用的队列情况:

已采集队列, 待采集队列, 采集去重队列, 数据库已有存储去重队列,已采集缓冲队列, 待采集超出值队列, 待采集超出值缓冲队列, 待采集备份队列

已采集队列负责已经抓取到的URL列表. (此队列为硬盘队列.)

待采集队列负责已经发现, 等待采集的URL列表. (此队列为硬盘队列.)

采集去重队列负责已采集和已经发现的URL列表集合, 这样确保不重复收集URL. (此队列为内存布隆过滤队列.)

数据库已有存储去重队列负责目前数据库中已有的URL队列, 因为在拿到一个URL的时候, 咱们需要判断URL是否已经存在于数据库, 存在则应该覆盖更新, 不存在则应插入, 目前发现数据库中超过10W条纪录后, 对纪录存在的检索成为瓶颈, 数据库服务器每次处理需要1S, CPU40%, 所以在三个线程同时查询的时候, CPU就会出现峰值瓶颈, 导致速度过慢, 所以引入此队列进行判定. (此队列为内存布隆过滤队列.)

已采集缓冲队列负责对已经下载的URL进行内存缓冲, 到达一定数量后统一插入到以文件表示的已采集队列中. 目前是100URL缓冲. (此队列为内存队列)

待采集超出值队列负责在待采集队列已经膨胀到一个非常庞大的数字后, 将新捕获的URL地址加入一个超出URL队列进行硬盘存储, 以确保整体的下载内存占用和CPU速度. 主要是衡量了Windows对进程的内存控制, 如果队列过于庞大后会出现两种情况: 1, 内存控制器会频繁试图释放内存, 造成很大的CPU负担. 2, 容易造成队列存放的堆内存使用过大后Windows主动推出OOM内存溢出异常, 从而影响采集的持续运行. (此队列为硬盘队列.)

待采集备份队列负责两种情况, 1, 负责在程序正常退出的时候, 将正在进行的采集任务中的待采集队列保存并且将原有队列备份, 以确保之后的断点续传过程. 2, 在采集任务长时间运行的过程中, 进行定时的自动备份, 以确保异常断开后工作断点续传不受影响.

效率和存储过程目前的试验情况:

目前使用的内存队列: Arraylist 和Queue, Arraylist用以处理小型缓冲, 目前估计值1W使用内存10-20M, queue处理待处理列表的大型缓冲, 目前估计值100W使用400M.

(因为如果不事前申请内存的话, 研究了目前内存自动申请流程是以2进制位数+1处理, 即每次申请上次申请大小的2倍, 所以在申请104W长度队列后会自动申请208W队列, 目前考虑又不想提前申请造成浪费又不想让它无节制申请内存, 所以目前待采集队列控制在100W, 其余转存入待采集超出值队列, 目前测量大概最大内存极限是5000W, 再大就非常不稳定了)

目前使用的布隆过滤队列: 1.5E URL大概100M内存, 毫秒查询速度, 比较理想. 缺点是不可逆, 只能做过滤队列, 不能做存储队列.

文件存储队列: 是以硬盘换内存的手法, 大概1M硬盘可以存2W URL队列. 100W URL大概在60M左右, 目前采用流方式读取和写入, 读取速度大概1S/5-10Wurl, 写入2-3Wurl.

去重模块-

URL去重模块目前使用的是布隆去重, 在内存里建立一个位向量的hash列表,

大概在10E内存分配情况下的1E碰撞测试6W, 大概几率是0.06%.

2E内存分配情况下1000W碰撞测试7224, 大概几率0.07%

2E内存分配情况下100W碰撞测试2, 大概几率0.0002%

具体碰撞概率跟内存分配大小及HASH函数有关，可通过增加HASH函数次数或增加内存分配来减小碰撞.

(2E分配量大概是20M内存空间)

网页下载模块-

网页编码分析模块-

网页内容提取模块-