[spider] 爬虫总体模型

最近只想把以前的小程序好好整理，改改简历，提高简历的魅力（至少也得减少一点排斥力，哈~）， 结果感觉动力不太明显，活干得不怎么利落，面对以前乱七八糟的东西，一下也拾不起来，生活习惯一下改变，也有一点不太习惯……。唉……

       WK说他要做一个企业内部的“信息搜索工具”，暂且就这么叫吧，^_^ 想和我讨论一下以前我写的爬虫模型，以及相关实现。于是就重新拿起未完善的spider 代码，重新研究。其实本来我也打算把这个改一下，好提前交了毕业设计。

       以前写得较急，说到总的模型，也曾经考虑过，不过没太具体，写代码时，总是基于方便，临时改变了许多，最后还是成了个大杂烩，哈~， 是该改改了，和WK花了一天时间讨论，终于讨论了个比较清晰的模型，看起来好象也挺不错，可以写代码了，因为WK只要求企业内部网页搜索，实在是很轻量级的数据，因此什么URL数据库，什么URL消重，页面保存啊几乎都不会成为瓶颈，不过我却想把URL数据存储结构先设计一下，哈~ 因为根据我21年的经验，如果我现在不设计，以后其他的全部写完了，我的动力周期就差不多到低谷了，肯定懒得写了。 因此…… 恩EH~··#￥ ，我还是要先设计一下具体的数据结构，以及如何优化，当然了，基本的思路已经定下：以trie 树为基本数据结构，目的是消重实在很快，尽管缺点是占用N大的额外空间。 ……

…………………………

只顾着改后面的结构，忘记把URL数据处理给分离开了……， spider_manager 负责的只有对各个 downloader 的控制 start stop suspend resume shutdown ... 。至于 URL 数据库和URL队列（功能同cash）应该组合为 UrlManager 这样就差不多了，

哈……

…………………………

关于分布式， 由于WK的企业内部检索要求不高，讨论时把这个给忘记了，我要的结果，当然是要加进去的，总的来说现在的模型改变应该不大。主要是加入一个新的网络模块deliver_manager，负责各个spider 之间的互动（当然是为了分压），如果能让每个spider 所下载的URL数量相差不大，那应该算较优吧， 至于如何deliver ，我打算先参考别人的论文，使用他们提供的经验函数，先进行尝试，以后有经验了，才进行修改。

至于deliver_manager 的工作，应该是介于html_parser  url_manager 之间。…… 还没想好 HOHO

…………………………

把IO_Writer 给放到Parser 之后了，觉得这样应该更好些（实现了再证实了！！），因为简化了PagebufferManager 的处理，同时让互斥分配的过程更加简单，减少因为互斥访问而让 Downloader  等待的时间。