爬虫是IO密集型，所以设计爬虫系统的时候必须考虑这一点。有几点需要注意：
- scrapy并不是并发数越高越好，这个完全取决于服务器带宽和代理IP的质量和数量。这里有篇文章写的很好：https://my.oschina.net/u/4402731/blog/3568083 ，CLOSESPIDER_ITEMCOUNT = 100，测试下不同参数的耗时即可
- 必须要考虑各个节点之间的网络通讯，我在用本地笔记本和远程服务器都跑过scrapy，但是主节点(redis调度和去重)是北京的腾讯云服务器，所以在本地跑爬虫速度明显慢很多，肉眼可见。毕竟大部分时间都耗在了网络通讯上。
- 小规模的爬虫不需要大规模的集群，瓶颈往往在代理池上。如果需求量大，自建代理池肯定是必须的。我自己搭建的代理池非常稳定，两个adsl vps轮播，20秒拨号一次，一次拨号耗时6秒，IP放到redis去重，如果是重复的可以删除。IP放入redis的时候需要加个时间戳，方便调用时知晓IP剩余存活时间。当然，也可以针对网站建立IP黑名单，实现起来很简单，每一次被封该IP的value增加1，要知道每个网站封IP的策略不同，需要探索。这个值越大，它的权重就越小（可以给每个IP打分），被调用的优先级越小（这只是对大的代理池，如果只有几台就没有必要了）。这个哈希表隔一段时间可以重置一次，毕竟网站不可能一直封掉IP，过一段时间往往会解封的，不然太容易误伤用户。
下面的几个测试都是基于2秒download_timeout, download_delay=0
{'downloader/exception_count': 290,
'downloader/exception_type_count/twisted.internet.error.TimeoutError': 290,
'downloader/request_bytes': 939629,
'downloader/request_count': 2612,
'downloader/request_method_count/GET': 2612,
'downloader/response_bytes': 4586610,
'downloader/response_count': 2322,
'downloader/response_status_count/200': 2322,
'elapsed_time_seconds': 228.855777, ######################
'finish_reason': 'closespider_itemcount',
'finish_time': datetime.datetime(2020, 12, 18, 5, 34, 52, 841964),
'httpcache/firsthand': 2322,
'httpcache/miss': 2612,
'httpcache/store': 2322,
'item_scraped_count': 104,
32并发数反而比16并发数耗时多了一倍！
{'downloader/exception_count': 47,
'downloader/exception_type_count/twisted.internet.error.TimeoutError': 47,
'downloader/request_bytes': 326088,
'downloader/request_count': 917,
'downloader/request_method_count/GET': 917,
'downloader/response_bytes': 1413362,
'downloader/response_count': 870,
'downloader/response_status_count/200': 870,
'elapsed_time_seconds': 94.203294, ######################
'finish_reason': 'closespider_itemcount',
'finish_time': datetime.datetime(2020, 12, 18, 5, 49, 1, 169299),
'httpcache/firsthand': 870,
'httpcache/miss': 917,
'httpcache/store': 870,
'item_scraped_count': 100,
8个并发数耗时比16个并发（120秒）还少了一点儿但是要注意这里的request_count明显降低了，正常情况5个request才会产生一个Item(调用了多个json接口)，降低并发数retry次数降低明显。slow is faster!
下面并发数改为16，download_time=5, download_delay=0:
{'downloader/exception_count': 7,
'downloader/exception_type_count/twisted.internet.error.TimeoutError': 7,
'downloader/request_bytes': 314651,
'downloader/request_count': 896,
'downloader/request_method_count/GET': 896,
'downloader/response_bytes': 1474882,
'downloader/response_count': 889,
'downloader/response_status_count/200': 889,
'elapsed_time_seconds': 69.643116, ######################
'finish_reason': 'closespider_itemcount',
'finish_time': datetime.datetime(2020, 12, 18, 5, 56, 11, 42312),
'httpcache/firsthand': 889,
'httpcache/miss': 896,
'httpcache/store': 889,
'item_scraped_count': 106,
'log_count/DEBUG': 1005,
'log_count/INFO': 184,
'memdebug/gc_garbage_count': 0,
'memdebug/live_refs/Product1Spider': 1,
'memdebug/live_refs/ProductItem': 7,
'memdebug/live_refs/Request': 1,
'memusage/max': 82305024,
'memusage/startup': 55525376,
'request_depth_max': 5,
'response_received_count': 889,
'retry/count': 7,
'retry/reason_count/twisted.internet.error.TimeoutError': 7,
'scheduler/dequeued/redis': 896,
'scheduler/enqueued/redis': 1147,
'start_time': datetime.datetime(2020, 12, 18, 5, 55, 1, 399196)}
咦，这里发现耗时70秒，看来增加download_timeout效果比较明显，retry次数已经降到了7次，耗时70秒！下面试试增加到32并发数，download_timeout保持5秒：
{'downloader/exception_count': 61,
'downloader/exception_type_count/twisted.internet.error.ConnectionRefusedError': 13,
'downloader/exception_type_count/twisted.internet.error.TimeoutError': 48,
'downloader/request_bytes': 454285,
'downloader/request_count': 1329,
'downloader/request_method_count/GET': 1329,
'downloader/response_bytes': 2199392,
'downloader/response_count': 1268,
'downloader/response_status_count/200': 1268,
'elapsed_time_seconds': 132.157984, ######################
'finish_reason': 'closespider_itemcount',
'finish_time': datetime.datetime(2020, 12, 18, 6, 4, 29, 718108),
'httpcache/firsthand': 1268,
'httpcache/miss': 1329,
'httpcache/store': 1268,
'item_scraped_count': 101,
'log_count/DEBUG': 1433,
'log_count/INFO': 229,
'log_count/WARNING': 6,
'memdebug/gc_garbage_count': 0,
'memdebug/live_refs/Product1Spider': 1,
'memdebug/live_refs/ProductItem': 52,
'memdebug/live_refs/Request': 2,
'memusage/max': 100614144,
'memusage/startup': 55521280,
'request_depth_max': 5,
'response_received_count': 1268,
'retry/count': 61,
'retry/reason_count/twisted.internet.error.ConnectionRefusedError': 13,
'retry/reason_count/twisted.internet.error.TimeoutError': 48,
'scheduler/dequeued/redis': 1329,
'scheduler/enqueued/redis': 1548,
'start_time': datetime.datetime(2020, 12, 18, 6, 2, 17, 560124)}
看来这次增加并发数到32效率反而降低了，重试次数61,耗时132秒，比16并发数2秒超时的组合还要差一点儿。下面试试并发数32，超时1秒，重试次数从前面的3增加到6：
{'downloader/exception_count': 669,
'downloader/exception_type_count/twisted.internet.error.TimeoutError': 669,
'downloader/request_bytes': 729406,
'downloader/request_count': 2021,
'downloader/request_method_count/GET': 2021,
'downloader/response_bytes': 2514467,
'downloader/response_count': 1352,
'downloader/response_status_count/200': 1352,
'elapsed_time_seconds': 181.738274, ######################
'finish_reason': 'closespider_itemcount',
'finish_time': datetime.datetime(2020, 12, 18, 6, 13, 34, 245444),
'httpcache/firsthand': 1352,
'httpcache/miss': 2021,
'httpcache/store': 1352,
'item_scraped_count': 101,
'log_count/DEBUG': 2125,
'log_count/ERROR': 2,
'log_count/INFO': 296,
'memdebug/gc_garbage_count': 0,
'memdebug/live_refs/Product1Spider': 1,
'memdebug/live_refs/ProductItem': 2,
'memdebug/live_refs/Request': 1,
'memusage/max': 112705536,
'memusage/startup': 55529472,
'request_depth_max': 5,
'response_received_count': 1352,
'retry/count': 669,
'retry/reason_count/twisted.internet.error.TimeoutError': 669,
'scheduler/dequeued/redis': 2021,
'scheduler/enqueued/redis': 2576,
'spider_exceptions/KeyError': 2,
'start_time': datetime.datetime(2020, 12, 18, 6, 10, 32, 507170)}
这次测试非常失败，主要是因为我只有两个VPS拨号，如果量大就不一样了。目前来看并发数16，download_time=5, download_delay=0是最佳组合。再测试下download_delay，试试并发数16，download_time=5, download_delay=0.1:
{'downloader/exception_count': 50,
'downloader/exception_type_count/twisted.internet.error.TimeoutError': 50,
'downloader/request_bytes': 281990,
'downloader/request_count': 802,
'downloader/request_method_count/GET': 802,
'downloader/response_bytes': 1189507,
'downloader/response_count': 752,
'downloader/response_status_count/200': 752,
'elapsed_time_seconds': 138.592611, ######################
'finish_reason': 'closespider_itemcount',
'finish_time': datetime.datetime(2020, 12, 18, 6, 20, 56, 171019),
'httpcache/firsthand': 752,
'httpcache/miss': 802,
'httpcache/store': 752,
'item_scraped_count': 102,
'log_count/DEBUG': 907,
'log_count/INFO': 298,
'memdebug/gc_garbage_count': 0,
'memdebug/live_refs/Product1Spider': 1,
'memdebug/live_refs/ProductItem': 3,
'memdebug/live_refs/Request': 2,
'memusage/max': 72540160,
'memusage/startup': 55529472,
'request_depth_max': 5,
'response_received_count': 752,
'retry/count': 50,
'retry/reason_count/twisted.internet.error.TimeoutError': 50,
'scheduler/dequeued/redis': 802,
'scheduler/enqueued/redis': 912,
'start_time': datetime.datetime(2020, 12, 18, 6, 18, 37, 578408)}
和预想的一样，这里增加download_delay没有意义，因为并发数16，download_time=5, download_delay=0本来重试次数就很少了，这里的重试次数反而增加应该是代理引起的波动。因为拨号是20秒一次，如果这里是0.1意味着每秒最多请求10次，和之前的最优组合16并发比少了一些，对性能影响较大。
再优化下，试试并发数20，download_time=5, download_delay=0
{'downloader/exception_count': 12,
'downloader/exception_type_count/twisted.internet.error.TimeoutError': 12,
'downloader/request_bytes': 323044,
'downloader/request_count': 908,
'downloader/request_method_count/GET': 908,
'downloader/response_bytes': 1302214,
'downloader/response_count': 896,
'downloader/response_status_count/200': 896,
'elapsed_time_seconds': 59.553894, ######################
'finish_reason': 'closespider_itemcount',
'finish_time': datetime.datetime(2020, 12, 18, 6, 45, 3, 462824),
'httpcache/firsthand': 896,
'httpcache/miss': 908,
'httpcache/store': 896,
'item_scraped_count': 105,
'log_count/DEBUG': 1016,
'log_count/INFO': 188,
'log_count/WARNING': 6,
'memdebug/gc_garbage_count': 0,
'memdebug/live_refs/Product1Spider': 1,
'memdebug/live_refs/ProductItem': 56,
'memdebug/live_refs/Request': 1,
'memusage/max': 55513088,
'memusage/startup': 55513088,
'request_depth_max': 5,
'response_received_count': 896,
'retry/count': 12,
'retry/reason_count/twisted.internet.error.TimeoutError': 12,
'scheduler/dequeued/redis': 908,
'scheduler/enqueued/redis': 941,
'start_time': datetime.datetime(2020, 12, 18, 6, 44, 3, 908930)}
看起来并发数20，download_time=5, download_delay=0比并发数16，download_time=5, download_delay=0组合耗时缩短了10秒！重试次数12，没有多少提高，这才是关键。那再试试并发数24，download_time=5, download_delay=0：
{'downloader/exception_count': 30,
'downloader/exception_type_count/twisted.internet.error.TimeoutError': 30,
'downloader/request_bytes': 310945,
'downloader/request_count': 876,
'downloader/request_method_count/GET': 876,
'downloader/response_bytes': 1312479,
'downloader/response_count': 846,
'downloader/response_status_count/200': 846,
'elapsed_time_seconds': 80.251456,
'finish_reason': 'closespider_itemcount',
'finish_time': datetime.datetime(2020, 12, 18, 6, 53, 0, 947113),
'httpcache/firsthand': 846,
'httpcache/miss': 876,
'httpcache/store': 846,
'item_scraped_count': 104,
'log_count/DEBUG': 983,
'log_count/INFO': 199,
'log_count/WARNING': 7,
'memdebug/gc_garbage_count': 0,
'memdebug/live_refs/Product1Spider': 1,
'memdebug/live_refs/ProductItem': 65,
'memdebug/live_refs/Request': 1,
'memusage/max': 86376448,
'memusage/startup': 55500800,
'request_depth_max': 5,
'response_received_count': 846,
'retry/count': 30,
'retry/reason_count/twisted.internet.error.TimeoutError': 30,
'scheduler/dequeued/redis': 876,
'scheduler/enqueued/redis': 989,
'start_time': datetime.datetime(2020, 12, 18, 6, 51, 40, 695657)}
其实第一次运行时用了100秒，这次80秒，后来测试70秒。因为IP代理波动和页面请求不同，波动比较大。但是可以看出来，并发数24相比于20已结没什么优势了。因为没有进行多次测试，上面的结论可能会有些误差，但是方法是没错的，scrapy就是需要这样迭代调优。这次测试的前提是我只有两台VPS拨号，每次重试获取的IP至少50%概率还是原来的IP，所以重试的失败率非常高。如果有大量IP，策略需要调整。这里的目标网站是京东，看来单IP也就上到并发数16，再高了短时间内频繁访问失败的概率陡升，而因为代理IP太少重试也没有意义。所以我说，爬虫很多时候瓶颈都在代理IP，如果IP足够多，一两个性能不错的服务器都能在1天内把京东500多万SKU爬下来，因为这里调用的json接口，对带宽要求很低的，一个json文件才几到十几个kb吧。
我看过很多文章，多数写的不痛不痒，满篇的复制粘贴。对于很多网站来说，IP代理量大是最佳的解决方式，除非每次访问都会弹个验证码，否则没有必要去死抠验证码。验证码终极破解难度很大，门槛不是一般的高，我知道很多js代码都是几千行而且加了混淆。有这功夫还不如多买几台拨号服务器呢。对于大规模爬虫，买上几十台轮拨，一个月也就45元/台*N台的费用，量大的话服务商都能做镜像，一劳永逸方便部署。
爬虫是个需要调优的过程，并发数很高看起来美好，实际上谁用谁知道。你并发数上去了IP被封得也很快，一个安全比较好的网站10-20秒可能就把你的高并发给封了，除非你用的高质量IP，比如腾讯云的IP，我测试过，爬京东并发16-32也可以撑2分钟，而且被封后sleep一会儿还能接着再用一段时间，当然我没有做太久测试，毕竟被封了不方便我测试。拨号IP基本上都是被大家用烂的了，这些之所以还能用都是因为过了禁闭期，这类IP并不能长效。