讨论内容

昨天的架构基本确定成如下图所示：

针对此架构，大家分别提了不同的看法：

【大侠】秦刘 9:53:58 
工作节点的爬虫 应该就是普通的一个cmd形式的小程序，对不对？
【大侠】秦刘 9:54:38 

webapp的作用应该只是这个
【大侠】大常 9:55:11 
这个是什么的设计图？
【大侠】大常 9:55:16 
怎么有点看不太懂呢？

【师兄】深简 9:56:07

感觉看懂了。

【师兄】深简 9:56:11

【宗师】北张9:56:28

对

【掌门】广杨 9:56:33

感觉像不像webmvc的思路

【大侠】大常 9:57:11

老大 我后面问的那个图是大概的模块耦合关系么？

【大侠】秦刘 9:57:31

我感觉webmvc管理master,master和工作节点类似Hadoop的心跳

【掌门】广立 9:57:33

【宗师】北张9:58:26

那就是cdoop和上边的四个同级？

【大侠】秦刘 9:59:13

cdoop什么含义？

【路人】四玖 9:59:30

我说这一坨 都基于PLUGIN 

【宗师】北张9:59:37

主要是分布式，参考hadoop

【路人】四玖 9:59:38

会被打不？

【宗师】北张10:00:19

那几个是考虑分出来的

【路人】四玖 10:00:24

规则引擎 和抽取引擎 基于插件 来做。

【路人】四玖 10:00:59

cdoop 感觉作为基础设施下沉.

【路人】四玖 10:01:14

轻拍。。。

【路人】四玖 10:01:21

【宗师】北张10:01:25

应该多提意见

【掌门】广立 10:01:55

新上传三本电子书

【宗师】北张10:02:35

这个是它们之间的依赖关系

【宗师】北张10:03:13

那我觉得按你这么说，其它cdoop也可以当插件做

【宗师】北张10:03:32

就是分布式，单机各种情况都可以扩展

【路人】四玖 10:04:12

如果是基于hadoop的思想的话.
他的分布式处理部分是算基础设施.
  nutch和hadoop算套件,那么nutch的就是以插件为基础.

【路人】四玖 10:04:17

我想的大概是这样

【路人】四玖 10:04:19

【路人】四玖 10:05:08

插件对外开放.
核心分布式处理内部管控.

【宗师】北张10:05:15

可以，其它人对这样设计有啥看法

【大侠】大常 10:05:39

这两种我认为@四川-玖东 的合理些

【宗师】北张10:06:01

ok，我理一下，发出来，大家继续拍

【路人】四玖 10:06:10

【大侠】秦刘 10:06:24

根为什么是WEB？

【路人】四玖 10:06:43

还是做个几种款式的
其实比较麻烦的就是 页面抽取,这一部分.

【宗师】北张10:07:15

多提瞥见

【宗师】北张10:07:46

页面抽取那个可以做插件形式，也可以独立出来

【宗师】北张10:08:42

那你建议根是什么比较好？

【大侠】秦刘 10:09:53

我感觉WEB这部分应该是独立的，应该是通过控制器接口进行操作

【大侠】秦刘 10:10:09

web不是必须的，只是便于管理的

【宗师】北张10:10:44

那现在可以肯定的是
parent
web
core
plugin

【宗师】北张10:11:06

我觉得剩下的都作为插件都可以

【路人】四玖 10:11:22

【路人】四玖 10:11:36

其实存储是可以做为插件的
因为每个项目的具体形式不一样
存储可能是mysql,redis,mongdb,hdfs.或者直接到搜索引擎
因为难点就是解决分布式问题.
玖.幺幺 2015/3/27 10:09:58
插件这个把体系设计号,可以让跟多人参与进来.

【宗师】北张10:11:40

解析和存储可以作插件也可以独立出来

【路人】四玖 10:11:56

刚和@【分】大连-常 讨论了下

【宗师】北张10:12:23

嗯，其它人怎么看

【路人】四玖 10:12:32

这种插件体系的系统 比较考手艺哦,大师们.

【大侠】大常 10:12:51

这种对大家的要求就很高了

【大侠】广张 10:12:59

耦合度没那么高了，这样系统中插件开发有点多了

【路人】四玖 10:13:10

估计要多多参考nutch,
但是nutch的插件 用起来很重.配置项太多.

【大侠】大常 10:13:11

单说存储的部分就需要大家对各种数据存储形式了解很深

【大侠】大常 10:13:20

然后还能抽象出来

【大侠】广张 10:13:27

先搞一种

【宗师】北张10:13:33

这个关键是能扩展就行，可以先存db

【路人】四玖 10:13:33

+1

【大侠】广张 10:13:35

其他存储方式后续扩展

【路人】四玖 10:13:43

先做抽象吧

【师兄】深简 10:13:46

我觉得可行。

【路人】四玖 10:13:49

具体实现 其实都没啥的

【宗师】北张10:13:50

就是一个流程走通

【大侠】大常 10:13:52

先抽象出来

【大侠】大常 10:14:00

然后走一种插件先做起来

【大侠】广张 10:14:06 
对
【大侠】大常 10:14:07 
主要是抽象出来的接口要好
【大侠】大常 10:14:18 
这个直接影响后面的插件开发的
【宗师】北张10:14:21 
先出逻辑的，再考虑接口部分
【师兄】北万10:14:24 
同意先搞一种，然会提供其他扩展接口
【大侠】大常 10:14:29 
可以
【大侠】大常 10:14:52 
我觉得@四川-玖东 后面发的这个

比较合理
【大侠】上柯10:15:14 
插件搞多了，插件管理很麻烦。
【师兄】深简 10:15:29 
@四川-玖东 我觉得这个方案的灵活性各方面都会比较好。
【大侠】上柯10:15:34 
对使用者的要求也会很高。
【宗师】北张10:15:35 
嗯，@【分】秦-刘 怎么看
【路人】四玖 10:15:55 
恩 这这样的
【大侠】大常 10:16:06 
@上柯 说的插件管理的麻烦就是我说要求一定要把结构的体系抽象好
【大侠】秦刘 10:16:35 
我对这种结构不熟，我没意见。
【路人】四玖 10:16:56 
抽象上面 就要考虑各种接入标准.如果
结构体系抽象做的不好,基本就废了
【路人】四玖 10:17:58 
http://www.baifendian.com/list.php?catid=116
有没有在这里上班的?
【路人】四玖 10:18:22 
感觉这个产品很不错.想见识见识
【大侠】上柯10:18:29 
把体系考虑好，这是最重要的。但每个模块的插件，我们要考虑好通用的插件管理模式。然后做好插件管理模式的抽象。
【大侠】大常 10:18:53 
我觉得所有插件最好不要一起管理
【宗师】北张10:19:09 
不错吗，百分点就是那几个头还行
【路人】四玖 10:19:34 
弱弱的说下.为什么感觉像在做一个垂直抓取的nutch
【宗师】北张10:20:24 
项目背景你看了是吧
【路人】四玖 10:20:41 
恩
【宗师】北张10:21:04 

【宗师】北张10:21:08 
这样？
【宗师】北张10:21:30 
你想见识百分点啥东西啊？
【路人】四玖 10:22:02 
就他的抓取系统里面自己的修改的jsengine
【路人】四玖 10:22:14 
这个有了 抽取这一块的问题基本就解决了 。
【宗师】北张10:24:08 
没太理解，抽取你指存的时候还是从页面取的时候
【路人】四玖 10:24:22 
从页面取的时候
【路人】四玖 10:24:55 
淘宝用了很多dom延迟加载.页面都是异步化的
【大侠】广张 10:25:20 
异步的抓取，用selenium可以很好解决
【宗师】北张10:25:38 
这个有很多解决办法啊
【路人】四玖 10:25:39 
恩 远程开启 浏览器
【路人】四玖 10:25:44 
但是效率太低.
【路人】四玖 10:25:55 
上百万的抓取 要等很久的
【大侠】广张 10:26:08 
比watij 好多了
【大侠】广张 10:26:30 
我用selenium 抓网站资源，包括图片还行
【路人】四玖 10:26:36 

【大侠】广张 10:27:16 
刚才这个思路我觉得可以，插件不作为这个阶段重点，考虑一种实现，重点是分布式抓取；
【路人】四玖 10:27:18 
我主要做电商抓取嘛
淘宝和亚马逊的 流量控制很严格,
京东和当当都还好
【大侠】广张 10:27:31 
后续如果想扩展，再重点搞插件
【大侠】广张 10:27:41 
jd会封你ip的
【路人】四玖 10:27:56 
So.
有http代理引擎丫
【宗师】北张10:27:57 
taobao也一样
【大侠】大常 10:27:57 
我觉得用插件这种方式就是为了以后解决刚才提到的问题的
【大侠】大常 10:28:24 
我们首先要做的应该是分布式
【大侠】上柯10:28:26 
http://www.zhuaqu.com/search.html
【大侠】大常 10:28:28 
这个部分
【大侠】上柯10:29:15 
先把流程走通，然后才能分布式。
【路人】四玖 10:29:40 
不知道 你们研究过webmagic没.我和那个作者交流过
【宗师】北张10:30:02 
看过那东西，黄吗
【路人】四玖 10:30:20 
恩.那个想法很简单的
【宗师】北张10:30:33 
你用的感觉怎么样，他那个
【路人】四玖 10:30:50 
我基于他的想法 最后做了改造
【宗师】北张10:31:18 
我在想那个代理用单独搞出来个模块吗？
【路人】四玖 10:31:22 
做了三个独立系统,.
抓取,抽取 存储
【宗师】北张10:31:54 
嗯，就是抓取，解析和存储，是吧
【宗师】北张10:32:11 
我的目的是把抓取再扩展一下
【路人】四玖 10:32:19 
我也是扩展了抓取

【路人】四玖 10:32:32

加入了代理.使用了redis 做url队列

【宗师】北张10:33:14

取的时候呢

【宗师】北张10:33:18

这种？

【路人】四玖 10:33:27

恩.

【宗师】北张10:33:49

嗯，我们最开始做的时候也是第一个想到的生产者消费者

【宗师】北张10:34:02

就是订阅发布这种

【宗师】北张10:34:22

【宗师】北张10:34:25

这个你看没

【路人】四玖 10:34:30

简单粗暴嘛.依托于中间件来做.抓取端水平扩展容易

【路人】四玖 10:34:56

承担调度

【宗师】北张10:35:08

嗯，队列现在有挺多不错的，这样是比较简单粗暴

【大侠】上柯10:35:27

简单粗暴好。

【大侠】上柯10:35:40

就怕设计过度。

【大侠】大常 10:35:43

简单粗暴效率高呀

【宗师】北张10:36:11

【宗师】北张10:36:45

别跑题了，那
就设计成接口

【路人】四玖 10:36:54

这个还是要综合具体的业务场景,项目周期来说吧

【宗师】北张10:37:21

其实我觉得第一阶段重点抓内容类的

【路人】四玖 10:37:37

数据抓取.
就抓，取,两个问题解决.

【大侠】上柯10:38:12

流程来说，任务调度，爬取，解析，存储。

【大侠】大常 10:38:21

应该概括成爬和取两个

【大侠】大常 10:38:30

这两个是关键问题

【大侠】上柯10:38:42

难点在爬上

【宗师】北张10:38:56

任务调度你们现在是啥方式

【宗师】北张10:39:06

扩展cron?

【路人】四玖 10:39:11

恩

【路人】四玖 10:39:20

最后还是有问题

【宗师】北张10:39:36

什么问题？

【路人】四玖 10:39:37

任务多了 资源竞争 经常锁

【路人】四玖 10:40:08

最后我在考虑.
为什么不把hadoop当成一个调度容器.

【宗师】北张10:40:29

嗯，这个想法挺好，跟我想的差不多

【路人】四玖 10:40:36

分布式的,高可用的.

【宗师】北张10:40:47

但是用mapreduce做不太合适

【掌门】广立 10:40:51

我觉的我可以用erlang从0现一个这样的调度

【掌门】广杨 10:41:00

应该找两个典型的网站，分析后，先针对这几个网站抓去

【路人】四玖 10:41:04

我不用它做什么计算.就单纯的当个调度器

【宗师】北张10:41:15

对

【大侠】大常 10:41:32

只抽出hadoop的调度能力？

【宗师】北张10:41:41

所以才有了那个

【路人】四玖 10:41:47

实现分布式调度容器.

【宗师】北张10:42:01

也就是咱们分布式的核心

【掌门】广立 10:42:16

【宗师】北张10:42:44

这个图我没明白的是为什么弄个bloom filter

【路人】四玖 10:42:51

@北张

【掌门】广立 10:42:55

能说清楚点master和worker的职责吗

【掌门】广杨 10:43:17

后再根据网站不同扩展处理，配置等等

【宗师】北张10:43:22

就是指挥和工作者

【大侠】上柯10:43:31

http://www.dataguru.cn/article-5327-1.html

【掌门】广立 10:43:36

如果只是弄一个这样的分布，我用erlang从0写一个都很快

【宗师】北张10:44:34

啊，我知道那个bloom filter
啥用了

【路人】四玖 10:44:58

数据结构化

【大侠】上柯10:45:03

啥用？

【宗师】北张10:45:24

排重的

【路人】四玖 10:45:45

我理解的反正 就是数据格式化 数据清洗 之类的

【大侠】上柯10:46:03

http://blog.chinaunix.net/uid-22414998-id-3774291.html

【大侠】大常 10:47:56

那是个过滤器吧

【宗师】北张10:48:11

对

【宗师】北张10:48:22

大数据下专用

【宗师】北张10:48:44

有误差

【路人】四玖 10:48:53

总的来说是个过滤器.
个人感觉就是数据格式化 数据清洗 之类的

【大侠】大常 10:48:55 
数据越大误差越大
【大侠】上柯10:50:22 
我自己做了个简单的任务调度的东西。从任务队列里取20条任务，把一个任务分配到一个存活的端。下一个任务分配到另一个存活端。
【宗师】北张10:51:11 
通过什么规则调度
【大侠】大常 10:51:29 
我感觉那个布隆过滤器是不是用来过滤访问过的url的？
【宗师】北张10:51:52 
不是，是取回来的数据
【大侠】上柯10:51:57 
根据任务的创建时间和优先级。
【大侠】大常 10:52:38 
取回来的数据是没处理的呀，处理过程中去掉那些存在的url
【宗师】北张10:52:43 
你怎么确定哪个端存活不存活
【大侠】大常 10:52:44 
是不是这样
【大侠】大常 10:52:53 
我去翻翻cola源码
【大侠】上柯10:53:23 
简单来说，下载端定时发送消息给master端。
【大侠】上柯10:53:37 
然后master中有张存活端的表。
【掌门】广立 10:53:51 
@北张 你怎么确定哪个端存活不存活
【宗师】北张10:53:54 
对啊
【掌门】广立 10:54:01 
这不是很简单？
【大侠】上柯10:54:08 
还有张取到的任务的表
【掌门】广立 10:54:10 
ping一下就知道
【宗师】北张10:54:11 
那存活端的使用情况呢？
【宗师】北张10:54:31 
比如性能等
【掌门】广立 10:54:55 
每个worker都应该有类似server_info这样的吧
【大侠】上柯10:54:58 
这个不用关心。
【大侠】上柯10:55:21 
爬 本身所耗的资源不大。
【宗师】北张10:55:49 
你看一下hadoop你就知道了，他是自动判断各个端的情况然后自动分配的
【掌门】广杨 10:56:04 
这个就是心跳吧
【少侠】北金10:56:27 
linux root用户怎么查看当前用户的密码？
【宗师】北张10:56:28 
对，如果你觉得自动判断不需要，咱们可以不做
【掌门】广立 10:56:30 
worker接受了任务，可以设置为忙碌状态，处理完了，向master返回waitting状态。。
【宗师】北张10:56:37 
id
【宗师】北张10:56:42 
密码查不了
【少侠】北金10:56:57 
噢 好吧
【宗师】北张10:57:31 
你那个只解决了任务分配情况的问题，但是使用资源情况完全可以用自己的协议来定一套
【大侠】上柯10:57:54 
恩。思路差不多。
【掌门】广立 10:57:56 
我感觉你们说的这个分布调度，跟游戏的跨服是一个东西。。
【宗师】北张10:59:07 
没太弄过你说的那个跨服
【掌门】广立 10:59:52 
几百几千个服联通
【掌门】广立 11:00:14 
就事类似你那个图了
【大侠】大常 11:00:54 
联通的时候是跨服的数据交互吧
【大侠】大常 11:01:04 
要求对用户进行节点分配么？
【掌门】广立 11:01:17 
每个worker是一个游戏服，想master提交操作，master分发同步到各个worker
【宗师】北张11:01:42 
同步数据到worker?
【大侠】上柯11:01:44 
同步用户数据？
【掌门】广立 11:03:24 
是的，粒度细小到服务器和用户级别。
【大侠】大常 11:04:04 
master把数据下发到worker，worker向mater提交？
【掌门】广立 11:04:09 
这种复杂的都可以应付了，我感觉master只是给各个worker分配任务应该比较简单了
【宗师】北张11:04:16 
跟我们说的是俩概念，我说的是master只负责指标，然后告诉worker去工作
【宗师】北张11:05:03 
对，思路正确，这就是hadoop最核心的，不移动数据
【宗师】北张11:05:10 
分布式运算
【掌门】广立 11:05:21 
你说的这个是模型更简单，master就只是指挥worker工作
【大侠】上柯11:05:48 
恩。我们不需要map/reduce
【大侠】大常 11:05:55 
现在老大说的是问如何保证任务分配给最佳节点
【大侠】大常 11:06:07 
所以需要获取worker的性能信息
【宗师】北张11:06:11 
对，这就是为什么咱们研究它那个分布式的原因
【宗师】北张11:06:26 
这个可以后期补充
【掌门】广立 11:06:33 
这个不用管啊
【掌门】广立 11:07:48 
记录一个状态，空闲状态的就异步分发任务，如果worker处理完了异步返回一个状态
【宗师】北张11:09:32 
回到刚才这个问题，这东西到底加到哪？
【掌门】广立 11:09:50 
如果收不到返回的状态，这个任务可以假设是失败的，可以再被分配，太多一下细节了，这个应该跟业务结合
【宗师】北张11:10:46 
对
【大侠】上柯11:10:48 
对的，这是基本思想。一个任务超过指定时间，一定要断掉。
【宗师】北张11:11:15 
上边那问题

【宗师】北张11:11:23

别讨论太细了

【大侠】上柯11:11:45

我觉得在任务调度，下载，解析，存储，每个都可以加个Plugin、

【宗师】北张11:12:35

你在图上标识一下你的想法

【大侠】上柯11:12:35

然后我们自己对这4步做个实现。

【宗师】北张11:12:57

或者干脆也来个图

【大侠】上柯11:14:08

好，我想想

【路人】四玖 11:19:58

http代理 属于调度部分.

【路人】四玖 11:20:13

额 属于抓数据的部分

【路人】四玖 11:20:33

对外开放的就是放入代理ip,端口,密码

【大侠】大常 11:20:55

这个就是可配置就行了

【宗师】北张11:21:10

嗯，目的就是个代理池是吧

【大侠】大常 11:21:46

对

【大侠】大常 11:21:56

主要就是应对封ip

【大侠】上柯11:22:00

【大侠】大常 11:22:45

调度也是插件？

【大侠】上柯11:23:25

可以留接口用来扩展。

【宗师】北张11:23:45

我也觉得那个没必要弄的挺大

【大侠】上柯11:25:22

代理池的调度可以弄简单点。

【大侠】上柯11:26:30

那可以不要。

【宗师】北张11:27:52

【宗师】北张11:28:05

这个是你画的跟我最开始想的对应关系

【大侠】上柯11:30:56

恩，下载，解析，都可以用配置规则来实现。

【大侠】上柯11:31:29

对了，在调度之前，还要加个URL去重。

【宗师】北张11:31:56

嗯，看url的量了

【大侠】大常 11:32:38

去重这个地方的指纹算法用什么？

【大侠】上柯11:33:57

这个真心不懂。

【大侠】大常 11:34:06

我觉得·在一个job进入队列之前的地方需要一个队url的过滤器
包括识别url陷阱，url过滤

【大侠】上柯11:34:16

要求助这方面的高手。

【大侠】大常 11:35:34

比如Rabin指纹

【掌门】广立 11:35:43

worker不可以处理过滤吗？

【掌门】广立 11:36:38

每个worker都应该有很多action吧，不是单一的，可以处理N中业务，根据master的指令来做事

【大侠】上柯11:37:05

去重是针对整个url库来的。

【大侠】上柯11:37:28

从根本上去重，这样任务量会大大降低。在worker中去重，效果不大。

【掌门】广立 11:38:09

master维护这N种任务的队列，或是一个主的master，管理几个具体业务的master，这些master再协调worker

【路人】四玖 11:38:51

url去重,现在不要考虑太复杂的算法.
整体url做个md5摘要.

【路人】四玖 11:39:03

包括queryString

【路人】四玖 11:40:21

querString 的参数 按字母大小写重排以后做一个md5摘要

【路人】四玖 11:42:22

这个如果从现实角度来讲.
使用redis 比较合适,Set,和map这两种数据类型先天性的具体这种功能

【路人】四玖 11:42:57

全库去重.你想。url达到100w的时候.效率相当痛苦.

【掌门】广立 11:49:15

redis很吃内存吧？

【路人】四玖 11:51:58

redis 吃内存这个
看具体数据量

【路人】四玖 11:52:34

你如果把redis当个缓存介质的话,你应该会定期的清理撒
如果当存储介质的话,他都是存在内存里面的

【路人】四玖 11:52:40

redis看你怎么用

【掌门】广立 11:52:44

今早看到有人说，redis只适合放热点数据

【掌门】广立 11:53:17

当数据库的话mongo比redis合适吧

【路人】四玖 11:53:20

看具体情况

讨论还在继续……

项目地址

https://github.com/zongtui/zongtui-webcrawler