众推架构的进一步讨论

讨论内容

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

A%}I7W07V5JR8GWNRHN~$PY

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

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

clip_image001

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  我觉得@四川-玖东 后面发的这个

clip_image002

比较合理 【大侠】上柯10:15:14  插件搞多了，插件管理很麻烦。 【师兄】深简 10:15:29  @四川-玖东 我觉得这个方案的灵活性各方面都会比较好。 【大侠】上柯10:15:34  对使用者的要求也会很高。 【宗师】北张10:15:35  嗯，@【分】秦-刘 怎么看 【路人】四玖 10:15:55 

clip_image003

恩 这这样的 【大侠】大常 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 

clip_image004

【宗师】北张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 

clip_image005

【大侠】广张 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 

clip_image005[1]

回到刚才这个问题，这东西到底加到哪？ 【掌门】广立 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