http、grpc、thrift 都没区别。。。重要的是这个服务的返回时间，时间快还行

如果你在 fpm 里面跑的话用 http 去调用别人的服务就阻塞了，流量一大就会死得很惨

顶一下，真的不想自己搞啊

文件修改可以有 inotify 来做

这样，你写一个脚本当 webhook 来的时候去 git pull 回来，然后脚本 git log 查看改了哪些文件，解析出你的提交文件，git blame 之，有别人改了就通知你

拿了这么多投资为何不开高点

@sagaxu 用一个命令行程序去刷新可以啊，可是逻辑写在一起比较好吧，而且增加运维复杂度。。

实际上 apcu 也有原子的设置一个 expire 的缓存的 apcu_add，用这个就可以实现只有一个请求去更新缓存的策略，而这一切完全可以封装到原来的缓存中不用改一行逻辑代码

@chenxytw 搜到这篇文章讲了这个问题： https://huoding.com/2015/09/14/463

🙄看来我干了 2 年全职爬虫还是有积累的

@drroot 你不考虑爬虫只是考虑代理和带宽的话，用异步或者半协程的确能提高速度，go 和 php 甚至有 fullstack 的协程 httpclient，在低 cpu 下打满带宽，但是一般情况下搞爬虫的精力还在和反爬搏斗，你这种瓶颈在代理 ip 上，直接堆机器吧

@swirling
不是我太聪明，是大家把问题复杂化了，爬东西本身就是个简单的问题，scrapy 封装太厉害了，比如实现 lz 这个更换代理 3 次你 scrapy 怎么搞？去读文档写 hook 么？我手写的直接写逻辑就 ok 了。。。算了，反正你用起来爽就行

@jhdxr php 的一堆框架的 cache 组建里都没考虑这种情况好吧

你输出到 csv 如何去重？结果需要保存到数据库，并且爬数据的时候去数据库看是否重复

首先 100w 数据量并不大，每个爬虫每 5s 访问一次的话只需要 65 个爬虫进程一天就能爬完 100w，假设我拿 200 个爬虫来爬，那这种程度的单机就能扛住，就阻塞的 requests 就 ok 了。。。so 大部分定制爬虫瓶颈不在 cpu

@ila 用 requests+bs4 就完了

要想自己定制就别用 scrapy

@tadtung 假的吧，怎么可能删用户数据