@@ -22,17 +22,11 @@ HttpURLConnection:本身的 API 不够友好,所提供的功能也有限
2222HttpClient:功能强大
2323OkHttp:是一个专注于性能和易用性的 HTTP 客户端。OkHttp 会使用连接池来复用连接以提高效率。OkHttp 提供了对 GZIP 的默认支持来降低传输内容的大小。OkHttp 也提供了对 HTTP 响应的缓存机制,可以避免不必要的网络请求。当网络出现问题时,OkHttp 会自动重试一个主机的多个 IP 地址
2424
25- ### 为什么用Vector
26- ** 多线程爬虫要保证线程安全,还可以控制容量扩充的大小 **
25+ ### 如何保存URL
26+ 封装一个包含同步的添加、移除方法LinkedList来作为存储URL的集合
2727
28- ArrayList,Vector主要区别为以下几点:
29-
30- 1 . Vector是线程安全的,源码中有很多的synchronized可以看出,而ArrayList不是。导致Vector效率无法和ArrayList相比;
31- 2 . ArrayList和Vector都采用线性连续存储空间,当存储空间不足的时候,ArrayList默认增加为原来的50%,Vector默认增加为原来的一倍;
32- 3 . Vector可以设置capacityIncrement,而ArrayList不可以,从字面理解就是capacity容量,Increment增加,容量增长的参数。
33-
34- ### 为什么用ConcurrentHashMap做爬虫深度控制
35- 因为需要保存的是一个【URL -> 深度】的键值对,在爬虫下载的过程中需要通过多个线程高频地对这个键值对集合进行操作,所以在增加元素的时候需要进行同步操作以免元素被覆盖,还需要避免多线程reset导致的循环依赖问题
28+ ### 如何做爬虫深度控制
29+ 用ConcurrentHashMap保存【URL -> 深度】的键值对,在爬虫下载的过程中同时记录下深度,所以需要通过多个线程高频地对这个键值对集合进行操作,还要在增加元素的时候需要进行同步操作以免元素被覆盖,还需要避免多线程reset导致的循环依赖问题
3630
3731### URL如何解析并保存
3832在下载到网页源码之后,将其中的所有URL通过Jsoup或者对每行内容进行正则表达式提取出来,如果符合预设值的正则表达式就添加到下载集合中。
@@ -91,44 +85,6 @@ timeout = timeUnit.toNanos(timeout);
9185
9286```
9387
94-
95-
96- ### [ 如何存储查询大量的HTML文件] ( https://www.zhihu.com/question/26504749 )
97-
98- 因为下载下来的HTML文件都是小文件,所以使用HDFS存储需要考虑一下,但为了分布式与扩展还是使用。
99-
100- 由于小文件会导致大量元数据的产生,那么变通的方法就是在文件中再创建文件,比如一个64MB的大文件,比如其中可以包含16384个4KB的小文件,但是这个64MB的大文件只占用了1个inode,而如果存放4KB的文件的话,就需要16384个inode了。
101-
102- 那么如何寻址这个大文件中的小文件呢?方法就是利用一个旁路数据库来记录每个小文件在这个大文件中的起始位置和长度等信息,也就是说将传统文件系统的大部分元数据剥离了开来,拿到了单独的数据库中存放,这样通过查询外部数据库先找到小文件具体对应在哪个大文件中的从哪开始的多长,然后直接发起对这个大文件的对应地址段的读写操作即可。
103-
104- 我们需要两种节点,namenode节点来管理元数据,datanode节点来存储数据。
105-
106- ![ ] ( https://github.com/xbox1994/2018-Java-Interview/raw/master/images/j6.jpg )
107-
108- #### 实现思路
109-
110- * 文件被切块存储在多台服务器上
111- * HDFS提供一个统一的平台与客户端交互
112- * 每个文件都可以保存多个副本
113-
114- #### 优点
115- 1 . 每个数据的副本数量固定,直接增加一台机器就可以实现线性扩展
116- 2 . 有副本让存储可靠性高
117- 3 . 可以处理的吞吐量增大
118-
119- ## 解析HTML
120- * 抽取网页数据放入索引表中,插入待建立索引的信息,等待建立索引
121- * 剪切源文件到配置的路径,建立百度快照
122-
123- 所以这里涉及到MySQL的使用,建立这样的一些表:
124-
125- * S_column:栏目表
126- * S_index:配置索引然后创建索引产生的索引表,仅用于Lucene,对Lucene的查询是通过根据columnId来查数据库得到所在索引路径来查找,所以必须要把不同的栏目放在不同的文件夹中
127- * S_index_column:上面两个表的多对多关联表
128- * S_news:新闻业务表,存放新闻信息和某栏目的外键
129- * S_user:用户表
130- * T_index:保存仅用于Solr的索引信息,便于myfullretrieve建立Solr索引,对Solr的查询是通过用columnId来过滤得到的所有相关信息
131-
13288### TF-IDF
13389#### 原理
13490如果某个词或短语在一篇文章中出现的频率TF高,并且在其他文章中很少出现,则认为此词或者短语具有很好的类别区分能力,适合用来分类。TF-IDF是一种统计方法,用以评估一字词对于一个文件集或一个语料库中的其中一份文件的重要程度。
@@ -141,7 +97,7 @@ timeout = timeUnit.toNanos(timeout);
14197去掉网页内容相同或相似的网页
14298
14399#### 用法
144- 用TF-IDF统计每个文章中少数重要词 (排序后的前几个),用MD5算法把每个词算出一个16进制的数全部加在一起然后比较两个总数,如果相同,那么两篇文章中重要的词就相同的,去掉。
100+ 用TF-IDF(term frequency–inverse document frequency)统计每个文章中少数重要词 (排序后的前几个),用MD5算法把每个词算出一个16进制的数全部加在一起然后比较两个总数,如果相同,那么两篇文章中重要的词就相同的,去掉。
145101
146102## Lucene原理
147103### 搜索原理
0 commit comments