说起采集，其实我是个外行，以前拔过阿里巴巴的客户数据，在我博客的文章：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！
快速发现问题并能有解决方案是很重要的一个方面。
方案整体代码不能提供，不过从百度拔的一些公共代码都在上面了，以及前面一篇文章中有介绍。其他都是细节问题，主要是这个方案过程比较曲折一点点。