多多小虫 天行健

一个月前，fcicq邮件给我提供了一个Windows平台下的 memcached 类型的缓存软件 Cacheman。这是由微软旗下的 Popfly 项目组成员 Sriram Krishnan 的作品。是他用业余时间开发的。于是开始关注这个缓存项目。

最新的情况是，微软的 Popfly 网站已经“悄悄地”的做了更新，就是采用了 Krishnan 的 Cacheman，更新了缓存机制。该项缓存技术更新带来的性能提升非常显著，根据Popfly团队中的 John Montgomery 的说法：加载一个已有的Mashup应用时，可以带来2到6倍的性能提升。

这些说法也得到了 Krishnan 本人的确认 。他提到这是 Cacheman 的第一次的实际应用，并自豪的说 Cacheman 不费吹灰之力就拿下了 Popfly 的全部访问量。

有意思的是 Montgomery 说他很开心这玩意儿运行正常，然后他又画蛇添足的补充了一句“至少现在如此”，然后 Krishnan 调侃说“我喜欢你说‘至少现在如此’的方式”。

简单介绍一下 Cacheman 这个项目。资料主要来源于 Krishnan的博客对Cacheman的介绍。

Cacheman是一个基于Windows平台的快速分布式哈希表。是由纯托管代码实现。中间搁置了有几个月，直到最近(似乎是今年1月低2月初)才开始重新上马这个项目，极可能就是因为Popfly项目需要的缘故才开始着手的。

Krishnan本人对 memcached 很感兴趣，于是创建了 Cacheman。Cacheman上有很多 memcached 的影子，比如与memcached相似的文本通讯协议。Cacheman的通讯协议公开，任何人可以根据自己偏爱的语言环境写客户端。 Krishnan 在自己家用电脑（2.4GHz Intel Core 2 带2GB内存）上进入测试，达到了每秒16000次左右的请求，并且还是服务器与客户端都是在同一台服务器下完成的。

现这款产品还不太完善，作者自身也提到：在Cacheman做指定key的GET/SET/DELETE操作时，客户端需要弄清需要与哪一台Cacheman服务器通讯，为此要对该key做一个快速FNV哈希然后求余得到应该和几台服务器中的哪台服务器通讯。但该法的缺点在于新增或删除一个服务器节点时，缓存节点需要大规模迁移。修复该问题需要一致性的哈希算法，作者表示还没有时间解决此事。作者提出了采用中心架构的“主缓存服务器”的解决办法，让客户端轮询主缓存服务器来获取应该与那个缓存服务器通讯，但他也觉的这样做增加了复杂性，会带来些新问题。

可以感觉到，由于 Cacheman 这个个人项目已经介入到 Popfly 这个正式产品中，可能很快就会被微软吸纳为正式产品，因此如果有人采用这个产品做自己缓存的解决方案的话，应该不必太担心后续的产品升级及文档支持服务，它的未来前途值的期待。说不定 Krishnan 会从 Popfly 项目脱身出来专职负责这个 Cacheman 项目。

目前最新的版本是0.0.2版 下载：http://www.sriramkrishnan.com/projects/cacheman/Cacheman_0_0_2.zip 。虽然有人希望作者把它作为一个开源项目，遗憾的很，似乎作者并无此意，目前仅提供了二进制文件。

目前争论都认为微软收购Yahoo!是不明智的。就我而言，也很难把微软和Yahoo!两家公司形象等同起来。
Yahoo!对微软而言共同点似乎很少，极难整合，至少在短期内是这样，那么微软错了，但是问题在于微软直的错了吗？假如微软没有错呢？

看看微软2007年的两次大收购：
2007年5月 微软出价60亿美元收购在线广告商aQuantive 。
2007年10月　微软2.4亿美元收购Facebook的1.6%股份。

微软的收购行为已经明确表达出它认为互联网最大有盈利模式的市场是广告，互联网的斗争将围绕广告展开。收购Facebook部分股份的行为应该认为微软最主要的目的是其精准的广告服务。

同样的，回过头再来看看Yahoo!的收购。的确短期内两家公司确实很难整合，但是两家的互联网广告业务却可以联合起来对抗Google。
微软对Google在互联网广告业务的迅速发展是非常重视的。Google收购广告业务商DoubleClick公司时，引起了包括微软在内几家大型网络公司的紧张，联合指控Google搞垄断，反对其收购行为。Yahoo!同样也面对这样的压力，它和微软将面临共同的敌人。从这一点讲，这次收购就是合理的。

作为结尾，引用一下微软官方的新闻稿 http://www.microsoft.com/presspass/press/2008/feb08/02-01CorpNewsPR.mspx 中对互联广告市场的预测：
The online advertising market is growing at a very fast pace, from over $40 billion in 2007 to nearly $80 billion by 2010.

有趣的是，当年微软收购Facebook时也有类似的争论，看看这篇 关于微软入股Facebook

豆瓣的官方博客前几天发表了"豆瓣技术团队的指环王文化"，文中笔调谐趣地道出《指环王》渗透入豆瓣的方方面面的场景，不经意间也透露出些许网站的“指环王架构”信息。我稍微做了一下整理，对有些信息做一些适当推测。

两台Web服务器承担。一台可能负责读书、电影、小组等；另一台负责9点。这两台服务器应该不是在前端的，豆瓣的网址应该都经过反向代理Rewrite过的，因此放在前端的可能还有几台硬盘缓存服务器（Squid？）做静态文件缓存，数目不详。
原文：梅里(Merry)和山姆(Sam)这两个霍比特人挑起了大梁，承担起所有用户的请求，向豆友们展现丰富多彩的页面。

应该还有几台Web服务器运行豆瓣的英文版及官方博客。不过从注册用户分离上看豆瓣英文版架构与中文版架构间关联度不大。
原文：运行着英文版豆瓣和豆瓣blog的服务器在美国，由于它离我们比较远，因此我们用中土世界跑得最快的马命名它——甘道夫的坐骑影疾(Shadowfax)。）

四台数据库服务器。这四台服务器的职能如何切分的还不清楚。如果这四台服务器是采用主从的架构，难道双胞胎爱隆和爱洛斯这两台是Slave服务器，森林女王凯兰崔尔(Galadriel)和灰港之主瑟丹(Círdan)是Master服务器？呵呵，瞎猜。
原文：四个神仙级的精灵：双胞胎爱隆(Elrond)和爱洛斯(Elros)，森林女王凯兰崔尔(Galadriel)和灰港之主瑟丹(Círdan)用他们伟大的智慧和不死的生命保护着用户的所有数据。

一台服务器做整站的全文检索
原文：爱隆之女，美丽的亚玟公主(Arwen)帮助用户迅速搜索到想要的信息。

两台服务器做后台服务。可能是RSS抓取及爬虫搜索的服务。
原文：另一个霍比特人皮聘(Pippin)和英俊的精灵王子勒苟拉斯(Legolas)执行着一些后台任务。

三台数据挖掘服务器
原文：人皇阿拉贡(Aragorn)和刚铎摄政王的儿子波罗莫(Boromir)，这两个强壮的人类和矮人金雳(Gimli)一起，承担着数据挖掘的重担。

一台图片文件服务器。以后豆瓣用户的头像、图书、电影等的图片都会由这台服务器来存储维护。从更广的方面讲，可能所有的css、js角本这样的静态文本都会被存储在这台服务器上。
原文：而波罗莫的弟弟法拉墨(Faramir)则逐步接管起图片的显示。

以上豆瓣的服务器架构的分配，实际上从这个服务器架构上还很难了解到到豆瓣如何处理负载均衡的。这里仅做初步认识好了。下面是豆瓣团队的软件开发项目。

豆瓣现有的软件项目：
豆瓣主站、数据挖掘、搜索爬虫、RSS抓取(9点)、高性能分布式计算平台。

开发：
开发团队采用了SCRUM敏捷模型的开发方法，Sprint的周期7天（周一迭代），以迅速响应不断变化的需求。每周的进展都会有一个code name。

看看以后豆瓣官方能否透露出更多的“指环王架构”细节。比如那个高性能分布式计算平台（这个名字很邪恶，叫魔多），或者一些没有提到的功能超级无敌的项目（似乎豆瓣的命名规则是越邪恶功能越强大，因此这个项目可能是未知的“索伦之眼”:-D）等等

所谓“旁观者”，即未在现场之意。仅从一个全程看网络直播的参与者来谈一些想法。

这次年会赞助商中最成功的恐怕是jiwai.de。它的大屏幕互动提供了一种比手机短信更容易参与并且直观的展示形式。在场内场外恐怕互动是最为活跃的区域，从留言内容分类看极为广泛，有直接对正在进行的发言嘉宾提问、建议或评论的，有寻人的，有解释现场出现的某些问题的，有发布在会后召集的，不一而足。这极可能成为以后活动的标准样板形式。

现场的音频直播是采用某个语音聊天室进行的。在第一天上午有一段时间转播很容易断线，庄老师可能想上传几张现场照片给聊天室的参与者，但一上传就断线。后来得知是无线方式上网转播的，可能与无线方式转播不稳定有关。后来转播比较稳定。转播声音质量不是很好，听起来很吃力。在第二天zola自己在自己页面上发布了视频转播时况，声音效果很好。因此极可能语音聊天室的语音采集话筒离现场音箱距离很远，这造成直播质量的下降。2008南京的中文网志年会应该避免这一点，同时应该能提供视频直播。另外，在去年yupoo提供过照片直播，今年没提供。

官方指定了irc聊天频道和语音转播频道，irc进行的文字直播效果很不好，开头还有人会发出现场的情况文字，后来几乎没有人在上面了。官方指定的文字直播irc频道名存实亡了。从参与的容易程度而言，irc频道实在不适合进行文字直播。不过我想比较好的形式应该是聚合几个志愿参与转播的twitter或jiwai.de，把消息统一在一个页面实时显示应该会比irc效果好。因为大多数人活动区域主要集中在自己的“微博”上。比如本来参与主持irc直播者之一的zola，后来的更新主要集中在自己的twitter上了，甚至在嘉宾席上发言间隙还在更新自己的twitter。

虽然本次年会号称公益，先不提报名费用问题，其中有一个关于“Map服务”的议题，基本是主讲人在谈论展示自己公司的产品。我并不反对在这样的场合谈自己的产品，但是应该有所侧重。比如可以谈谈对于博客作者或一些创业者如何轻松整合自己公司的资源实现一些好的有前景的应用。毕竟参加年会的不是来此不是进行产品洽谈会，而是来进行思想交流的。赞助商可以在现场或网络等合适的位置发布广告信息，但是会议话题还是不要被“赞助”的好。在讲到“Map服务”这个话题时，语音聊天室主持人发出几个字“大家可以休息5分钟”。

说到会议话题，就想到了会议的日程安排。本来自己想参加现场的，但是现场离我住的地方距离实在太远，不能在会议指定时间前赶到现场，又想周末睡懒觉没去成。但是实际会议开始的时间仍然延时了。会议日程说是9:00开幕，但实际上10点以前现场一直在进行签到。在10点以后才开始。头天如此，第二天也延迟了。

关于中文网志年会的话题，有人认为话题应集中于“网志”上，围绕博客作者方方面面的话题进行。如果真这样我觉得这限制了年会的意义，而且随着发展年会发展议题会越来越窄。如果集中在互联网的草根技术方面的应用探讨，应该会有比较广泛的话题。

今年偷懒了，明年希望能去南京的年会现场。

Live Spaces新近在提供了的好友添加方式。尝试添加了一批好友，很容易，不过需要对方确认。这是延用了Live Messenger的交友方式。

如FaceBook这样的很多交友类网站都借用注册会员提供的Live Messenger帐号中的好友列表迅速建立起自己的好友圈子，本来如果Live Spaces去做这件事时应该更简单、容易一些的，因为还有什么网站能比Live Messenger与Live Spaces结合更紧密的吗？Live Messenger的帐号本身就是Spaces的帐号。但是很难理解的是，Spaces并没有直接把Messenger已经添加的好友列表直接加入到Spaces好友列表当中，而是需要单独添加。

其它交友类网站需要有一个导入Messenger好友列表的操作，但对于Spaces完全没必要，可以直接把Messenger好友列表拿出来直接用就是，但是Spaces偏偏也非要加入一个导入的操作，是不是有些画蛇添足。

Spaces中除了提供导入选择的Messenger好友为好友的功能外，还可以根据Spaces上好友的交友活动的简单记录随时加入一些新的好友，而这些好友不在你的Messenger列表当中，你既不认识，也不了解，更没有过交流，这使得Spaces好友的质量低于Messenger好友的质量。

这样实际上Spaces人为的造成了两套好友圈子，一套是Spaces的，一套是Messenger的，Spaces的好友不一定是Messenger的，Messenger的好友不一定是Spaces的，两个好友圈子相对独立。对Windows Live用户而言不能维护一个统一的好友圈子，却要维护两个好友圈子，这是怎么设计的？

总之，没看明白。

以上内容引自http://www.infoq.com/cn/news/2007/10/minwin-windows7

根据对微软周边消息的掌握，这里做一些对MinWin未来的猜想。

一、现在微软同时在在维护多个核心的Windows（参见上面引用链接），这在开发和产品一致性上会存在一些问题。MinWin将是统一核心的开始。以后，手持设备(PPC/Smartphone)、桌面设备(PC)的操作系统核心都将变成统一，对不同的硬件设备可能只需采取相应的编译开关即可。

二、MiniWin将会全面进军硬件嵌入式开发的主要操作系统。现有的路由器、硬件防火墙、网关、工控机等的主要核心Rom基本上是Linux内核。MinWin将会全面进入这个市场。

三、用MinWin的核，添加其他定制服务将更加容易。如果遇到类似欧盟要求移除Vista安全特性 这样的操作时，可以很容易完成，根据不同国家的法律制度要求来提供相应的功能服务模块。同时对服务器端用户与客户端用户定制也更容易。从开发上讲，最终用户版与服务器版的发布时间最终将趋向同步。

MinWin只是核心模块剥离外加一个简单Shell的小型化。我不信微软单纯会因为所谓的“广大用户的呼声”而这样做，更多的是对未来商业发展战略的考虑。

小区地处偏远，到了晚上11点几乎感受不到节日气氛，决定去天安门广场看看。外面天气太冷了，穿了厚外衣。

以为在这个时间段上广场游人会比较少，但是在车快到广场时就看到长安街两侧大量的游人。

从天安门西侧准备进入广场，但是似乎夜间清场已经开始了。守着西侧入口的警察只准游人出不准游人进了，后悔来晚了。警察告诉我们说明天早晨5点后来就可以进广场了。

这一张是刚到时拍的，很多游人正在涌出广场，我们进不去了。

没办法了，在外围拍了张背景是前门的照片。

倒霉的很，没拍几张相机没电了，要不应该可以拍到更多现场照片的。只好徒步由西走到东单然后返回。途间游人不断，有很多警察在维持秩序，广场上的广播也在循环播放着让游人注意的事项。延途马路一侧停造着很多移动公厕。在过地下通道时，还有武警也在指挥疏导地下通道的人流。在通道两侧有很多学生或躺或卧或玩在玩手机，极有可能是在准备看明天的升旗仪式。想起了我当年刚到北京上学，也是为了等凌晨升旗要在广场上等一宿。今年十一太冷了，在地下通道里相对来说还比较暖和些。

走到东单时，人流量已经逐渐减少了一些，看到王府井的麦当劳24小时店，准备进去坐坐吃点什么。走近一看，好家伙里面都是人啊，好些人还在排队，这可已经是晚上12点多了啊。不敢想象的是在明天天亮时广场人流量该多大啊。实在不敢出来了。

有消息说微软将以3到5亿美元收购Facebook的5%的股份。于是出现了几种观点，总体上是认为微软会把它与SharePoint产品整合，会让Facebook变成一个企业级的应用，不利于普通用户应用；微软的介入会让该产品失去创新；微软的投资行为可能会使投资人高估类似Facebook社区类网站的价值导致新一轮互联网泡沫化开始。

这几种观点都或多或少的存在着问题，只能说他们并不了解微软。IDC的分析师Mark Levitt只知道微软的SharePoint产品不知道微软还有面向互联网用户的Windows Live系列产品吗？Facebook有庞大的用户群，微软怎么可能仅仅为了企业应用的产品SharePoint而放弃这些普通用户呢？如果真的的放弃了，微软在8月份花了60亿美元收购网络广告商aQuantive，那么难道这些广告仅仅是给企业用户准备的吗？放弃巨大的普通用户的注意力资源，又白白花巨资买网络广告公司，微软会这么傻？微软没有放弃与Digg的广告合作，难道会放弃Facebook?

所以可以肯定的是Facebook对于微软而言绝不是把它自废武功般的整合成狭小的SharePoint企业级应用。微软未来的战场在向互联网上转移，在互联网上，微软最大的敌人是Google，可以说微软近期的一系列互联网动作都与Google有关，比如Windows Live Search 2.0的推出。Facebook也不例外。

对微软而言，Facebook约不仅仅是一个社区。Facebook是第一个抢占开发互联网资源开发API的网站，他把自己成功的变成了一个平台。Facebook对社区的未来发展方向，可以说正好契合微软的理想。微软在传统PC世界，努力把Windows打造成一个环境、一个生态，开放其系统资源调用、制订种种标准调用规范，让无数的开发者为其开发扩展其功能，无数使用Windows的用户因此获益。而在互联网世界，微软需要延续他的成功，他需要做的就是一个类似Facebook这样的平台，然后立足于这样一个平台，强化Facebook的现有API应用。这不仅不会限制Facebook而且会有利于Facebook的未来发展。

一个值的注意的相关事件，在微软收购Facebook股份消息公开的前后，也同时有另一则消息公布，即：Google将大规模公开API，将会比Facebook更将开放。这两则消息无论谁先谁后，至少表明一点微软和Google都意识到互联网开发平台建立的重要性。

关于会引起泡沫化的问题，我以为不会。请注意我上面对微软收购Facebook真实意图的分析。如果Facebook单纯是一个Myspace那样的社区是不会引起微软的如此兴师动重。在今年7月份一度有消息称微软准备以60亿美元收购Facebook，单纯一个社区的话微软的这笔钱应该有更好的选择方向。这倒会引发另一个潮流：一大批社区开始逐渐开发和开放自己的API调用，以吸引投资人的注意。

昨天下午陪老姐逛天坛，出发前认为天坛的游客会很少，因为是周一，不是周末，结果也是人山人海。说明：门票有15元、35元，这种价格绝对是陷阱，因为如果买了15元的票，在天坛里转，你无法游览圆丘、回音壁、祈年殿，如同在一个树比较多的普通公园散步，还不如玉渊坛。只有35元才包括上述三个景点。不幸的是我们买的就是前者，感觉很受骗。

拍了些照片，为避免大家看了照片产生误解，所以我再强调一下，以下照片拍摄时间不是十一国庆节拍的。

这是东侧古道上拍的，看看人多不多。

这是在上台阶上拍的

祈年殿门口。进不去只好在门外拍了。

相当部分的景点尚未开放还在施工，看看左侧的隔离铁皮及上面的标语。也许十一时能完全开放吧。

拍摄的这条古道没有开放，我是从围栏外拍摄的，道路上还有些民工在休息。

有一些古建筑已经包给一些纪念品小买部或照相馆之类商家，当时心想，如果这些商家是星巴克肯定有人会表示抗议了。但是现在这种场景下大家似乎重没有觉的有无不妥。

北天门下有三个门洞，两侧的门洞被两个票友“占据”。东侧门洞是一个胖胖的妇女拿着一个麦克高唱评戏，西侧的是一个男子也在唱不知道在唱什么戏，门洞的回响效果很好，但是正因如此就显得太吵了。之所以说“占据”，就是因为太吵了，游人都不敢从两侧门洞走，只从中间门洞走。这样的文化古迹里，外国人看到这样的场景也许会认为这也是天坛“文化”的一部分吧。

过一两周就到十一国庆了，我觉的就到北京来玩就千万别去这样的景点，那时人恐怕更多，抢一个合适的拍摄角度也会极难。我还不确定某些景点会否开放，但是可以肯定的是，这样的历史文化景观里，会增加一些与时俱进、符合现代特色的“景观”。因为我已经看到一些花坛之类的东东也在施工中，也许是拼一个庆祝国庆的文字，也许是拼成一个奥运五小强图案吧。

新浪博客首页已经开始投放大量的广告，从别人的文章里才注意到这个事实。但映像中博客作者页面实际上也早已经有一些商业性不是很强的广告了。

keso说放下Alexa，不过我这里仍然想引用Alexa有关新浪的一组相对数据：
blog.sina.com.cn - 15%
finance.sina.com.cn - 14%
news.sina.com.cn - 12%
sports.sina.com.cn - 10%
book.sina.com.cn - 8%

以上数据是新浪各频道访问百分比较高的前五名。可以看到博客所带来的访问量已经不知不觉的超过了新浪引以为傲的新闻频道，成了新浪的第一流量频道。这样的流量构成下，新浪在博客上放广告是迟早的事也是必然的事。但是如何在博客作者页面中投放商业广告，这值得关注。它不能引起博客作者的太大的反感，尤其有这么多明星驻博。而且在奥运新闻播报上，博客应该是新浪应对搜狐又不违反规则的重要一环。所以新浪应该会很慎重。比较现成的而且已经有案例的思路是广告与博客作者分成。这个思路如此简明，新浪不会没有看见，这么久没有采用这样的方式，也许他有别的打算吧。

新浪曾经下很大力度去推广的爱问居然在Alexa关于新浪流量前十名都没有排进去，失败。（流量低也许与它也用另一个域名www.iask.com有关吧，不过这个域名流量也很低。而且现在这个域名的搜索结果也由Google去处理了。）

以前新浪的访问量第一的绝对是新闻频道，而现在屈居第三让位于博客频道。这是否表明个人媒体正在逐渐崛起呢？

Update(2007-9-13 8:0:0):没注意到，原来新浪已经公布了博客作者广告分成办法。