软件开发: 02 2007存档

        好像自从google发家，几乎所有技术人员都盯上了它“发”出来的那几篇论文，比如gfs的、mapreduce的。它的技术确实漂亮，因为这些技术和框架都是它根据自己实际需要量身定做的，用在它自己那里当然是非常合适，但却不一定能用在别人身上。比如它什么都用分布式，那是因为搜索引擎有那么大量的数据要实时处理故而不得不如此，并不是因为分布式真的是解决海量计算的灵单妙药，更不是包治百病的万金油。但现在大家似乎动辄就谈分布式，好像身在互联网行业，如果不搞点“分布式”跟别人见面都不好意思打招呼。
        前几天分猪肉（我们管分任务叫“分猪肉”），我领命处理大量数据（其实也不太大，估计也就几十G，和搜索引擎比真是小儿科了），马上就有同事提议用“分布式”，我倒不是反感分布式，我是心疼服务器和电费：我们的数据十天半个月才需要处理一次，就算是拿一台破点儿的服务器慢慢算也未尝不可；要是搞分布式，先得来个四五台服务器放着，平时都用不上，几个星期才让它算一次数据....太不环保了。没有最顶尖的技术，只有最合适的技术。

        我没有反感google的意思，像google这样的技术型公司平地崛起，是我等技术人员拍手称快的好事，但正因为google是英雄，所以我们更要识英雄重英雄，而不只是一个劲的膜拜。

        这次重构爬虫的过程中遇到了一个不小的麻烦，由于FreeBSD-4.11对线程的支持非常不佳（gethostbyname等系统函数不可重入），而使用多进程又太占内存，所以目标就定在“一个进程多个连接”。没有直接用socket而是用的libcurl中的multi_curl,当然“select()”还是免不了的。
        麻烦很快就来了，建立连接的时候会阻塞在gethostbyname调用上，如果是多进程爬虫这种阻塞只影响一个进程，而现在在多个连接初始化的时候，它浪费的却是大家的时间。
        为了让gethostbyname不再阻塞，我们试了dnscache、dnsmasq等DNS缓存软件，但问题还是存在，即对于一些不存在的域名dnscache不缓存，下次解析的时候程序还是会阻塞。这个cache有点名不符实。
        折腾了两天后，我们终于采取了最后的方案：把libcurl中调用gethostbyname的函数替换为自己写的一个内存cache，不存在的域名也留记录，免得又阻塞。虽然动作大了点，这最后一招终于起作用了。
        但很快发现虽然不阻塞了，但爬取速度连原来的一半都不到，而且如果curl数量太多，它们会都不返回（即用select始终问不到任何结果）。我郁闷之际，发现这个爬虫程序一跑，机器上的网络操作就无法进行。会不会是机器本身网络就有问题？问了问夏辉，原来开发机有400个连接数的限制。换用专门的测试机跑了一遍，搞定，速度够快且没有在DNS解析上阻塞。