简介在以前知道的问题和攀登答案的项目中遇到了很多问题，所以对这篇文章进行总结评论
项目文章http://blog.csdn.net/sinat _ 34200786/article/details/78770356项目地址https://github.com/dengqlbq/jdspils
1 .商品详情
2 .商品评论
3 .评论总结
要获取商品详细信息，首先需要商品详细信息页面的url。 然后进入页面获取数据
注意：商品url很容易做到。 这有助于以后攀登
https://item.jd.com/4624505.html？ JD _ pop=0e7d 3959-5331-45e1- a308-e 552908569 CCA Bt=0表示https://item.jd.com/4624505.html表示https://item.JD.JD
比较简化的url可知，在检索页面中商品url的密钥是商品id
所以要取得商品的详细信息先取得商品url，要取得商品url先取得商品id。 商品详细情况有详细页面，商品id有检索页面，而且一个检索页面有多个商品id。 将商品id和商品详细信息的获取整合到一个爬虫中不可避免地会导致代码肥大，因此将功能分为两个爬虫，最终框架如下。
JDUrlsSpider获取商品id，商品详细信息url和商品评论urlJDDetailSpider获取商品详细信息和评论，JDCommentSpider获取商品评论q。 为什么JDUrlsSpider需要构建商品评论url？ ()
答：简单来说，因为获取评论就像获取详细信息一样，需要门户url。 详细情况将在后面叙述
问：为什么详细信息和评论的总结分为JDDetailSpider？ ())为
a :一会儿再说
当获取商品ID商品ID在检索页面上时，首先分析检索页面的url
搜索页面的url
https://search.jd.com/Search？ keyword=电脑enc=utf-8wq=电脑pvid=5549914 a 587 D4 ab 2949557695960 da 56翻几页以上，就可以找到url中包含的几个重要参数。
keyword搜索关键字wq搜索关键字page由于当前页数s (这很难解释，page * 60 )，搜索页面url抽象为：
https://search.jd.com/Search？ 查看第ky word={0} enc=utf-8 qrst=1rt=1stop=1vt=2wq={1} page={2} s={3} click=0页的商品id，实际上还很容易查找都在沥标签里
虽然抽取后只获得了30个商品id，但在搜索页面上手动清点后却怎么也有60个商品id。 剩下的30个去了哪里？ 经验表明，它是异步加载的。 在搜索页面上手动滚动滚动条，确实如此。
开发人员工具networkxhr，只要找到异步请求网站就很容易了
您可以看到滚动条几乎到达底部后，异步请求被阻止。 请求的url非常长，请求的response证明这就是我们要找的url
请求url :
https://search.jd.com/s_new.php？ keyword=电脑enc=utf-8 qrst=1rt=1stop=1vt=2wq=电脑page=2s=27 scrolling=ylog _ id=1514895812.28592 TPL=1 5002534、5029717、4624543、4274539、5148309、1593516、5148275、3597544445 5025869、5148299、5352358、5020872、5005922
翻过几页，就可以找到url中的几个重要参数。
比较keyword搜索关键字page，首先获得当前搜索页面的页数1show_items
取的30个商品id所以请求url抽象为：
https://search.jd.com/s_new.php?keyword={0}&enc=utf-8&qrst=1&rt=1&stop=1&vt=2&page={1}&s=26&scrolling=y&log_id=1512092382.36606&tpl=1_M&show_items={2}所以要获取搜索页中后30个商品id只需要将几个重要参数填好再构造请求然后从response里提取就行了。
获取商品id步骤：
构造搜索页url获取前30个商品id构造异步请求获取后30个商品id 获取商品详情和评论总结 商品详情要获取的详情数据为：
1. name
2. num
3. price
4. owner（店铺名）
5. jd_sel （是否京东精选）
6. global_buy （是否全球购)
7. flag (自营标志）
如果你的爬虫直接将某个商品详情页直接下载下来进行数据提取，你会发现price永远都是返回空值，按照一般经验判断price是异步请求的。
开发者工具–>Network–>XHR，这时你会发现找不到相关的异步链接。怎么办？price数据一开始不在详情页说明它肯定是后面才请求的数据，既然请求数据那肯定是有相关链接的，XHR那里没有就全部数据找一遍。
开发者工具–>Network–>ALL，仔细找找就能发现请求price数据的链接
请求url：
https://p.3.cn/prices/mgets?callback=jQuery3162769&type=1&area=1_72_2799_0&pdtk=&pduid=525462493&pdpin=&pin=null&pdbp=0&skuIds=J_1378536&ext=11000000&source=item-pc简化为：https://p.3.cn/prices/mgets?skuIds=J_1378536抽象为：https://p.3.cn/prices/mgets?skuIds=J_{0}请求返回的是json数据，并且从图中可以看出 “p”所对应的就是price的数据
到这里商品详情的数据就全都获取了。
商品评论总结①这里解释一下为什么商品详情和商品的评论总结会放在一起，这是因为在获取商品详情price数据时，查找请求price数据的链接过程中发现了一个有意思的链接——获取评论总结的链接
请求url：
https://club.jd.com/comment/productCommentSummaries.action?referenceIds=1378536&callback=jQuery5056364&_=1514983166800简化为：https://club.jd.com/comment/productCommentSummaries.action?referenceIds=1378536抽象为：https://club.jd.com/comment/productCommentSummaries.action?referenceIds={0}可以看到请求返回的数据是非常详细的，对于这个意外收获当然是大方笑纳，所以在获取商品详情的时候就顺便把评论总结也搞定了。
获取商品详情和评论总结步骤：
下载商品详情页获取商品详情构造price的url获取price数据构造comment_excerpt的url获取comment_excerpt数据 商品评论一个商品有很多评论，所以商品评论肯定不会一下全部加载出来而是一部分一部分的加载，那么只需要先翻几页评论然后找请求链接就可以了。
开发者工具–>Network–>ALL
可以看到请求返回的数据包含10个评论和评论热词（每次都会返回），随便点开一个评论会发现数据也是很详细的
可以发现评论确实是对应的
请求url：
https://sclub.jd.com/comment/productPageComments.action?callback=fetchJSON_comment98vv34564&productId=1378536&score=0&sortType=5&page=1&pageSize=10&isShadowSku=0&rid=0&fold=1简化为：https://sclub.jd.com/comment/productPageComments.action?productId=1378536&score=0&sortType=5&page=1&pageSize=10抽象为：https://sclub.jd.com/comment/productPageComments.action?productId={0}&score=0&sortType=5&page={1}&pageSize=10②这里就可以解释一下为什么JDUrlsSpider需要构造评论url了，可以看到抽象后的评论url需要productId和page两个参数，productId在JDUrlsSpider中直接就有数据，然后将page设为1就可以构造出获取评论的入口url。
说下sortType这个参数，你可以改成其他值试试，你会发现有些值是返回json数据有些不是，这里选择值为5是为了请求返回json数据方便解析，不过实际上证明会有小概率出现返回的不是json数据的情况。
这里还有个问题需要说明——我怎么知道可以获取多少评论？其实在返回数据中都会有一个maxPage的值，根据这里就可以知道我们可以获取多少页的评论了。
获取商品评论步骤：
获取商品评论的入口url以maxPage构造循环构造url获取数据构造url... 优化框架划分好了，框架各个部分的思路也有了，接下来只要编码就能把项目完成。
可是想一想项目其实有挺多地方可以优化的，举几个例子：
1. 增加总控
2. 分布式
3. 代理池
在框架划分中各个功能已经独立出来：
1. JDUrlsSpider负责根据搜索页url获取该页所有商品id的获取并形成详情url和评论url
2. JDDetailSpider负责根据详情url获取商品详情和评论总结
3. JDCommentSpider负责根据评论url获取商品评论
结构图：
其实很明显的JDUrlsSpider需要根据搜索页url才能知道去哪里获取商品id，如果我们的项目只爬取一个或两三个指定关键词商品则可以写在JDUrlsSpider的配置文件中，但项目考虑的是爬取大量不同关键词商品信息，所以应该增加一个总控端并且总控端应该具备以下功能：
1. 可随时修改关键词
2. 可指定页面数量
优化后的思路就是：
总控端根据配置好的信息不断将搜索页url抛出，JDUrlsSpider不断接收搜索页url进行处理后抛出详情url和评论url，JDDetailSpider和JDCommentSpider则根据相应url进行数据获取
优化后结构图：
分布式分布式可以解决性能和带宽的瓶颈
试想一下多台机器的多个爬虫一起启动，那爬取速度肯定比单机快得多。
分布式的思路：
1. Master负责url去重，分发，数据存储（数据也可以直接存在Slave机）
2. Slave负责从Master处获取url然后执行自己的任务
这样处理的分布式优点除了快之外，Slave机还可以省去很多配置，只要把代码复制过去直接运行就可以了。
要做成这样的分布式也很简单，scrapy-redis就可以轻松搞定
分布式结构图：
代理池如果我们的爬虫爬取过于频繁就会触发京东的反爬虫机制，简单粗暴的的服务器会直接封禁IP，只要是这个IP的访问都会直接拒绝，所以我们需要构建一个代理池来应对。
构建代理池可以自己去IP代理商那里买，也可以直接爬取网上免费的代理存起来需要的时候就拿出来用。
买代理优点是方便快捷，只需要调用代理商的API就可以获取代理IP，缺点是贵并且IP的可用性不高。
自己爬代理优点当然是免费了但缺点同样明显——代理IP的可用性超低，还要定期更新存储的代理，识别无效代理并丢弃等等一系列维护。
怎么办好呢？其实万能的Github上已经有很多开源的代理池了，原理都是爬取网上的免费代理，只不过别人已经帮你做好维护工作了，装好就能用。
这里推荐一个Github上的代理池项目：
https://github.com/jhao104/proxy_pool
如果你使用推荐的代理池最好就用gunicorn部署这样可以提高并发性能
注意：使用代理会使爬虫明显变慢，尤其是遇到劣质代理的时候，所以一般最好不用代理