/ 详情

关于URL去重的思路

Done
owner
Opened this issue  
2016-01-05 00:15
  1. 统一提供一个去重服务或包含去重的KVDb服务,要求高性能,高并发,持久化+内存,可集群
  2. 需要讨论下是否需要单独队列将去重请求异步化,这样会带来吞吐量的提升,但是也会带来空间浪费和有效路径放大的问题。如果将去重服务做成同步请求响应,则可以降低有效路径,提高正确处理效率,但是相应的资源利用率会降低,整体吞吐量将会减少。
  3. 若采用同步请求响应的方式,还需要考虑连接方式,选择长连接还是短连接?最后还有一个请求超时的处理。

个人想法:

  1. 统一提供KVDb服务,直接用于去重,还可以持久化保存下载数据(这里隐含了只有下载任务才需要去重的约定,其他任务诸如解析,结果处理等都可以重复执行)。
  2. 采用长连接同步RPC的方式,若超时则不断重试,没有重试次数限制,但是超过阀值可报警通知。
    具体产品可以选择ZBus来提供RPC,初期使用Mapdb来提供存储,中后期使用Redis代替。

Comments (2)

已处理。

  1. 单机版放弃MapDb,使用BDb存储,效果非常理想。
  2. 分布式版本地不做去重,ZBus已实现,只需要提供MsgKey即可。

Status changed to closed

Sign in to comment

状态
Assignees
Milestones
Pull Requests
关联的 Pull Requests 被合并后可能会关闭此 issue
Branches
Planed to start   -   Planed to end
-
Top level
Priority
参与者(1)
117 l weiwei 1578913730