关于爬虫系统图的几个问题？

系统设计
1

老师，请问

  1. 在系统设计图过程中，我发现从Fetcher出来以后，拿到的html要进入到html storage中，然后还有一路是要进入到URL Queue。我听您课上说这个Queue是按顺序记录被fetch过的url。我想问一下，这个url queue的动机是什么，保存顺序又是为了什么，然后que里面的url什么时候用？

我猜测的答案是url是要出队的，然后最好是和要解析的html同时到达HTML processor中，parse html的时候，如果手里有这个html来自于哪个url的话，可以避免，如果出现如果源的url的话，那么就不要了，防止陷入死循环。但是这里有个问题，怎么确保que中的url和html同时到达HTML processor，还是说虽然这个queue叫url queue，其实里面带着html的文本呢。还是说，它里面带着html的查询信息，等url到了processor，再从big table里面拉相关的网页？这样也有可能出现url到了，big table哪里还没存进来呢的潜在的弊端。咋整？

  1. 在HTML之后还会有一个URL processor的模块，这里会利用到domain table 和history table。对于domain table的更新，课上说了对于经验的更改可以用一个batch job进行上新。但是history table里面有一个field是上一次爬去的时间，这个field如果在课前估算的qps上来看，说明对于这个table的写也是相对频繁的，对于这部分压力怎么能化解呢？而且，这个field在这个业务场景里面，需要有一定及时性么？感觉这个取决于对方网站的政策和重要性，我觉得这个表单如果也一杆子变成异步更新，会有一定的影响，这个怎么处理？
2
  1. URL Queue 不存 HTML 信息，只存 URL id，目的是为了保证公平性和 BFS。短时间内的后续步骤需要处理的时候会去 Cache 里拿具体的 HTML，一定时间过去后需要去 BigTable 拿。不存在 URL Queue 排队排到了还没存好 HTML 的情况，URL Queue enqueue 的时候，HTML 存储应该已经完成了。
  2. History Table 实时更新，相对频繁，而 Domain Policy Table 异步更新，相对延迟大。History Table 读取压力可以通过 Cache 和分片来解决。Domain Policy Table 一般认为更新比较慢是可以接受的（这里的慢比如是 Daily Job)。这里做这个取舍的原因是一个网站的重要性不会在一天里变化太大。