这是一个创建于 2750 天前的主题，其中的信息可能已经有所发展或是发生改变。
现在有这样一个场景, 就是说要去抓取数据, 但是由于一些限制, 抓取次数不能太多
所以当有多个相同的请求进来的时候, 希望能像 guava cache 那样, 只有其中一个去 load, 剩下的全部阻塞等待就可以了
请求打到单机的话比较容易, 映射到本地的同一个 CountDownLatch 就可以
多个机器的话, 想过用 redis 做分布式锁, 当有一个线程在抓的时候就加锁, 其它线程阻塞等待锁, 使用短时间睡眠+轮询来等待, 但感觉这个方案好像太挫了...
想要实现的东西类似一个分布式 CountDownLatch, 看了 redis 的 api, 没有想到特别好的方式
看了下 CountDownLatch 的实现, 好像也是类似轮询的东西
大佬们, 有没有优雅一点的, 性能好一点的方案呢
所以当有多个相同的请求进来的时候, 希望能像 guava cache 那样, 只有其中一个去 load, 剩下的全部阻塞等待就可以了
请求打到单机的话比较容易, 映射到本地的同一个 CountDownLatch 就可以
多个机器的话, 想过用 redis 做分布式锁, 当有一个线程在抓的时候就加锁, 其它线程阻塞等待锁, 使用短时间睡眠+轮询来等待, 但感觉这个方案好像太挫了...
想要实现的东西类似一个分布式 CountDownLatch, 看了 redis 的 api, 没有想到特别好的方式
看了下 CountDownLatch 的实现, 好像也是类似轮询的东西
大佬们, 有没有优雅一点的, 性能好一点的方案呢
 |
1
hand515 2017-05-04 08:23:42 +08:00  1
如果请求不需要同步返回的话，扔到消息队列处理就好了。简单点就用 redis 可以实现。
消费进程用 BLPOP/BRPOP 进行阻塞等待。 需要同步返回的话，阻塞等待的时候，通过 pub/sub 订阅也可以实现不用轮询 |
 |
2
troycheng 2017-05-04 09:39:44 +08:00 1
可以考虑队列，生产者消费者的方式，将要抓取的 url 扔进队列（可以多队列，也可以单队列里去重），抓取的事情交给消费者做。具体实现，简单处理的话，同楼上，redis 订阅发布机制就可以搞。
多阶段协同性质的任务很多时候不需要用锁的机制，合理解耦任务，用队列的方式进行异步处理，是非常高效且容易实现的方式 |
Select Language