老师课件里面的设计是从craw下来的web page里面提取出很多url，对每一个处理的时候会query一下web page crawl history db看看这个url是不是最近craw过如果没有就送到url frontier里面进行处理。
我的问题是由于craw下来的web page中提取的url是比较随机的，所以可能对于某一个url，你提取到的时候发现他最近craw过于是丢弃了，但之后可能很久都没有再遇到过他，所以这个网页可能很久（1个月）没有重新craw，但可能网站的policy是说让一周craw一次。还有一些web page，也可能由于一直没再遇到他的url，所以我的一直没有重新craw他，这个没关系吗？
我看到过另一个做法是在crawl history db里存了url最近craw的时间，以及下次需要craw他的timestamp，然后url frontier每次就根据下次需要craw的timestamp以及url的优先级来query 这个db提取出很多需要craw的url进行处理。而url processor则不会把url送给url fronteir而只是update这个url craw history的db。
- 还有一个关于url去重的问题，加入某网页爬的frequency是1周，然后当我遇到这个url的时候我query craw history table发现上次爬已经过了一周，那么我吧这个url放到url frontier里面等待爬，这个时候我如果又遇到了这个url怎么办？如果query craw history table会发现上次爬取式一周前了，但我刚刚已经把一个url放到了queue里面等待爬取了。
- url frontier中不同的component是在同一个server里面吗？还是说url prioriizer一写server， front queue一些server，queue selecor一些server，back queue一些server？如果是前者，我能想到的scale的办法可能是不同的server 按照url domain来分配traffic，如果是后者感觉就不太容易scale，比如back queue selector可能就不是从几万个host queue里选，而是几十万几百万个host queue里选了
- 容灾设计里面的queue persistence是吧queue里面的东西写到log存在disk里吗？
- 确实有你说的这个问题。这种短时间内出现多次，但是之后又很长时间不出现的情况应该不常见。如果需要解决这个问题的话，可以像你说的，按照固定的频率来爬取。这两种方案应该要结合在一起用，否则只按固定频率爬取就没办法发现新的 URL 了。
- 在真正爬之前再 check 一下
- 我觉得 URL Frontier 里存的 URL 的量级应该不是很大的，毕竟只是暂存一下，所以组件放在同一个 server 里我觉得比较合理。
- 是。
- 所以url frontier并不是stateless的manchine，url frontier是不是也类似做了sharding？就是指定的机器只处理指定domain的url？
可以根据 Domain 来 Shard，这样 Single Host Queue 会分散到不同的 Shard。
那这样server就不是stateless了，一般常见的是对db做sharding而server是stateless的对吧？上有send url的时候需要把url send给正确的server这个通过什么来实现？
服务器可以是 Stateful 也可以是 Stateless 的，比如说 Uber 的 Ringpop 就是 Stateful 的。只要有数据存在服务器上服务器就是 Stateful 的，需要考虑如何 Shard. 在按照 domain shard 的情况，发送 URL 时找到对应的 Domain 并且根据 Sharding algorithm 算出哪台 server 就可以了。
1 个赞