十年前 我在抓虾(3)

导语：这样的经历还有不少。2006年有一天晚上我和韩磊、霍炬、朱辉龙一起在簋街喝酒到很晚，这时候来了两位流浪歌手，于是我们也跟着一起唱。唱着唱着，店家又给上了很多啤酒。我们都觉得很奇怪，一问才知道，大堂对侧另

这样的经历还有不少。2006年有一天晚上我和韩磊、霍炬、朱辉龙一起在簋街喝酒到很晚，这时候来了两位流浪歌手，于是我们也跟着一起唱。唱着唱着，店家又给上了很多啤酒。我们都觉得很奇怪，一问才知道，大堂对侧另一桌的朋友虽然不认识我们，但觉得唱得不错，所以给我们点了一打啤酒。于是，大家端杯走向那桌不认识的朋友，一边连声说“谢谢”，一边喝了几杯，这样就算尽了礼数。

2007年夏天我设了个饭局，谁会来完全不知道，只靠朋友口耳相邀。结果，一开始来了个挺斯文的年轻人，自我介绍说“我松鼠会的姬十三”……过会儿又来了个家伙，一问原来是DBA Notes的冯大辉。过会儿，李笑来老师、博文视点的周筠老师也陆续来了。很多朋友之前都没有见过面，只是在网络上听说过。当面见了，轮流做个自我介绍，谁也没什么架子，大家一边吃一边聊。现在我已经离开北京很多年了。

回来说抓虾的团队。这个团队就是在那样的年代，由一群热情洋溢的年轻人组成，所以虽然说不上多么严谨专业，但感觉是幸福的。办公室的二楼有供加班休息用的房间和小床，虽然卫生很糟总是臭气熏天，但大伙就靠这张床（还有漱口水），熬过了很多不眠之夜。

吃午饭这件事也很能体现团队的风格。当时抓虾是包午饭的，定点在华清嘉园附近的一个饭店，从保福寺走过去大概要二十分钟。每天吃饭的程序都是异步沟通，确保高效：首先打电话过去点菜，然后等电话通知上菜时间，估摸着快到了，组队去吃饭。走进饭店通常所有菜刚刚摆上桌，大家就坐之后一顿猛吃，通常桌子刚转两圈就吃完了，前后不到10分钟。有一次，徐易容有事来晚了五六分钟，结果被告知“你们的人都走了，桌子都收拾完了”。这种作风有深刻的后遗症，我离开抓虾之后，陆续被很多人说起“吃饭速度好快”。

同样有意思的是团建。2007年组织了一次自驾去河北涞源和空中草原，露营的那天晚上，男生挤的那张帐篷里臭气弥漫，等我早上起来已经有好几个人受不了气味，跑去看日出了。那天晚上易容也没仔细看防潮垫下面的情况，据他说睡的那块地方下面正好有一大块马粪，导致他胃受寒了好些天。回程我们在八达岭高速遇上特大堵车，从中午12点到夜里8点基本没动地方。

这是我第一次在高速上的汽车里过夜，半夜我还拿三脚架和单反出来拍了不少高速夜景。夜里有好几次前面疏通了一两公里，坐在副驾驶的我醒来就喊“易容，可以走了”，于是他发动汽车往前开一段，接着又睡着。第二天早上8点多我们才回到北京，结果是皆大欢喜：当天不上班，全员多休息一天。我还追问易容记不记得前天晚上我叫他开车的事情，他竟然完全没有印象。

当然，对于公司来说，团队年轻，气氛好，只是一个方面。团队年轻就意味着可能犯错，需要严格要求、反复锤炼。尤其是因为没有大公司成套的规章制度，这方面需要付出的努力就更多。后来我每次回想，都觉得这方面易容和振宇肯定花了很多心思，没有靠打鸡血也没有靠蛮力逼迫，就能保持整个团队的技术追求和信任保持在很高的水平。就我所见，真正能做到这一点的人，着实不多。

我记得有一次偷空看到海鹏的代码，惊异发现内部管理系统也写得那么漂亮，真是自愧不如，这才相信他之前呆的IBM并不只有笨拙死板的流程，还会培养良好的规范意识和职业素养，自己之前真是知道得太少了。当然我也是只有佩服其他人的份，有次我花了些心思写了个周边的小模块，也被同事称赞“写得真漂亮”，当时真是心花怒放。

滋养技术追求，并且这种追求会被明确肯定，对良好的技术氛围功不可没。实习生陈拓来的第一天就说，他的电脑不要装Windows，直接装Linux，真是让我吃了一惊。许多年后我和他在长沙见面聊起此事，他嘿嘿一笑说：“其实我对Linux不怎么熟悉的，但是当时看身边的人一个个都用命令行，再用Windows肯定说不过去。”

或许正是因为有这样的团队和这样的气氛，所以后来我回忆起自己在抓虾的经历，也深刻觉得在技术上获益匪浅。有几个例子我印象很深。

第一是整个抓取的任务分派系统。因为要抓取的RSS Feed（内容源，也可以理解为某个URL地址对应的XML）很多很多，如何高效调度它们，保证尽快抓到更新，又不能做太多的无用功，就成了大问题。新闻的更新时间比较好预测，但还有大量的RSS来自博客，博客的更新时间往往取决于作者心情，完全没有规律，什么算法都不好用。这个问题采取了一个非常取巧的办法来解决：从读者出发。只要发生读者登录事件，就检查这个读者订阅的RSS Feed，如果对应的Feed上次的抓取时间在半小时之前，就立刻触发再抓一次。

换句话说，重要的不是技术要做到无所不能，而是要给读者“抓得够多够快”的感觉，真正的问题是用有限的资源实现最佳的效果。后来在很多工作中我发现，技术人员往往忽略了这点，明明可以用很低成本实现的效果，非要去钻牛角尖。或许，这并不是因为他们笨，只是因为没有见过让人“开窍”的例子。

第二是抓虾的存储。为了保证阅读效果，抓虾抓来的内容都需要存储在本地，几百万Feed每天产生的数据量相当可观。那时候HDFS之类的东西根本没有成气候，更谈不上云计算、云存储了。如果数据量大了，充其量是使用Tokyo Cabinet之类的类库来完成，但这种东西本身又不甚可靠，工业上使用总是问题多多。

抓虾解决这个问题也是用的简单粗暴的方式。把内容用Gzip压缩成二进制存到MySQL的表里，只提供ID和GUID的查询。这样单张表可以存放3亿的数据，分表的规则也相当简单。

这种方案听起来有些土也不可思议，但当时确实解决了问题，而且依托MySQL现成的主从复制，数据的一致性也有很好的保障。正好那一年《容量规划的艺术》中文版面世，我找来一边读，一边思考MySQL的存储方案，深刻体会到一个道理：方案本身并没有绝对的优劣， 根据实际情况提炼关键指标，综合考虑各种变量，通过分析、估算、设计、验证，得出合适的方案，到后来能把各种约束、条件、关注点烂熟于胸，这才是工程的真正含义。