昨天的架构基本确定成如下图所示：
针对此架构，大家分别提了不同的看法：
【大侠】秦刘 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
看具体情况
讨论还在继续……
项目地址
