再谈C#采集,一个绕过高强度安全验证的采集方案?方案很Low,慎入

    说起采集,其实我是个外行,以前拔过阿里巴巴的客户数据,在我博客的文章:C#+HtmlAgilityPack+XPath带你采集数据(以采集天气数据为例子) 中,介绍过采集用的工具,其实很Low的,分析Html,用开源的HtmlAgilityPack就很快解决问题了。我个人并不是技术特别深,所以只要是解决问题就OK了。但每一次需求并不是完全一致的,对上面那篇文章的采集,无需登录,是非常灵活的,但是这次碰到的稍微有点变态,虽然最后任务完成,但总结方案还是很low的,但觉得还是有必要分享出来,希望对以后碰到这个问题的人有用。

1.采集目目标特点与分析

    由于采集目标比较商业性,不便于透露。所以文字多一点。大家仔细看。

    目标网站特点以及初始需求:

    1) 要求登录,并且登录安全验证非常严,怎么严就不说了,就是非常困难,动不动还得手机验证。

    2) 网站数据经过分析,都是直接登录后通过https请求来获取JSON数据,解析就可以用,但是里面也有变态的地方,就是有些参数是加密的,直接扒历史数据有困难;

    3) 初期网站每天需要采集的URL类型超过60+左右,但总的采集链接数超过2000+,因为一个类型的URL,有很多不同的区域的数据需要采集;

  最需要说明的是该项目所有的页面分析,解析和采集入库工作由2个毕业生来做,我也没时间去做很深入的研究,他们C#语法还不是很熟练,所以技术方案上不能太复杂,越简单越好。

  先看看我这方案的过程,由于工作太多,刚开始想法是很好的,但是越做到后面,发现越麻烦。  

2.方案第一版-Low到爆,别笑话

    该采集最大的难点就是登录的问题,由于安全性太高,所以一开始我就彻底放弃了程序模拟登录的思路,虽然后面的过程有点曲折,但这也是新人很快能搞定所有采集的关键。否则在前面就不知道要花费多少时间。说说初步的想法:

    1.既然登录后就可以采集数据,那就人工登录一次,做一个asp.net web页面,点击开始,就可以使用WebClient请求JSON数据。因为在同一个浏览器,登录的session啥都可以共享,我是这么想的。

    2.请求数据后直接解析到数据库;

    3.大量的URL多线程执行应该速度很不错,So,没啥压力;

    大神一眼都能看出问题哈,想法很美好,现实是很残酷。

3.碰壁后的第二版方案

    基本JSON的解析工作差不多让新人完成后,自己做了个asp.net 的web测试,真是xxx,获取不到JSON数据,一调试,才知道,WebClient请求这样搞是不行的,在web页面直接请求url也是不行的,就是所谓的跨域问题,虽然没搞过前端,但也能理解。好吧,这么low的问题,真的不好意思拿出来说,谁叫没动手试一下呢。那怎么破?所以有了第二版方案:

    1.既然不能跨域,那就让你跨。在大石头和邱哥的提示下,用webbrowse来搞吧。

    2.使用webbrowse控件手动登录后,直接在控件中请求新的URL,获取JSON值;对,这样看你跨不跨过去。。。测试一个链接也是可行的。

    然后发现真的是 万事开头难,中间难,结尾更难。。。想法很美好,现实是很残酷!

  

4.最终方案第三版

4.1 该死的completed事件

    按照方案2,很快所有的链接加进去了,开始采集,又杯具了。只有第一个链接能执行。。。调试,很快发现问题,也怪学艺不精,以前没用过webbrowse啊:

    webbrowse请求url后,是不能马上获取到请求的html文本的,要在completed事件中处理获取到的html文本(JSON字符串)才行。怎么破?

    既然要用事件,那也挺好,不断请求,不断解析,把处理逻辑加到事件中就好了。很OK,继续进行中。。。

4.2 没想到URL请求太快

    没跑几个URL,xxx,问题又来了:当初由于采集的页面和链接太多,所以做了几个菜单,点击后分别采集不同的任务,但是点击后这个请求不断的发,这个事件执行是有问题的,很多没执行到,有一些中间变量值被覆盖了,请求太快啊。。。怎么破?那我就设置个长一点的时间,确保每次加载并处理完成才去请求下一次。好,说干就干,看了一下每个页面的解析,10秒足够了,那就搞10秒请求一次。。。。继续进行中

    还是xxx,过几天这个网站改版了,改动很多,很无奈啊,但生活还得继续。还好我们的解析都是利用工具生成的东西,改起来很快。具体可以参考这篇文章:C#+HtmlAgilityPack+XPath带你采集数据(以采集天气数据为例子)

    改版的一个主要变化是URL类型增加了很多,所以数据也增加了很多,以前是总共也就50-60个类型的链接需要采集,但是改版后,上升到2000+,增加了很多子类型的数据,你懂的。然后发现这个10秒一次,啥时候能采集完成啊。。。而且很明显,10秒对很多URL来说多很多,不是白白浪费吗。。。好吧,知道问题,那就想办法解决,如果连问题都不知道,那就杯具了。

    都搞10秒不公平,那就搞个timer吧,定时执行,但是在请求之前和解析之后,动态修改这个timer的间隔执行时间,一秒也不浪费啊。比如请求之前设置间隔是10秒,事件里面解析之后设置为1毫秒。。。哈哈,So easy 。。。。

4.3 想开得和飞机一样快,但火车的速度都没到

    xxx,跑了上百个之后,发现还是太慢,任务太多啊。。。每一个好几秒也hold不足。。。。那怎么破,分析一下原因,很明显请求加载速度很快,慢在处理那里,主要是事件处理那里不好加多线程。那怎么破,办法总比问题多。。。怕啥。。。

    反正就是每天采集下,那弄个中间缓存呗。当然本地缓存也是可以的啊,这里特意用了一个windows版的redis做了个测试,目的是有2个,因为我们组的项目中redis用的比较广泛,新的毕业生来虽然没玩过,但我们日常也在说,以后项目也会用到,所以特意在这个地方教他们使用了一下,比使用Oracle当然更简单,平时他们都是用Oracle,所以理解起来也不费劲。所以新的方案又来了:

    使用timer来控制发送请求的间隔,在完成事件中,把json值和相关解析要用到的变量缓存到redis中,然后开一个多线程从redis里面取值进行解析工作。。。所干就干,用了30行代码改造了一下,很快就测试。。。不得不说,Paralller.For好用啊,请求的速度提高到60-80个/秒,速度很快了,解析4个线程开起来,速度也杠杆的,没计算具体的时间,但是解析完也就比请求完多个几分钟。开发机安装东西太多,而且CPU比较鸡肋,所以开4个线程已经100%了,所以这个效率也够了。至此,整个系统的核心工作让2个新人折腾来折腾去,给他们思路,和简单的示例代码,就搞定了。

5.总结

    当然过程的细节还有很多要注意,特别是解析工作,在前一篇文章中说过了。

其实从分析页面链接,到解析,到最后数据入库,代码给他们过指导,但大部分工作是新人完成的。这个过程让他们也对项目和数据有了很深的了解,自己也会更轻松一些,毕竟从头接触,出了问题,他们可以排查。在从头到尾的过程中,还有很多细节,他们自己也排查和发现了很多bug,但总归要给他们试错的机会,能改正就好。在总体方案的变化下,从解决碰到的问题,要简单的优化,多线程,redis使用,都有了直观的了解和认识(为什么要用,什么时候要用,为什么一开始不考虑?),多几行代码,速度瞬间提升。。。

解决问题的方法比问题要多,思路决定出路,用简单的方法解决问题就OK!

快速发现问题并能有解决方案是很重要的一个方面。

  方案整体代码不能提供,不过从百度拔的一些公共代码都在上面了,以及前面一篇文章中有介绍。其他都是细节问题,主要是这个方案过程比较曲折一点点。

posted @ 2016-12-11 22:55 数据之巅 阅读(...) 评论(...) 编辑 收藏