多多小虫天行健: 技术总结

Cacheman —— .NET架构下的分布式缓存

Mon, 31 Mar 2008 06:15:33 GMT

一个月前，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 。虽然有人希望作者把它作为一个开源项目，遗憾的很，似乎作者并无此意，目前仅提供了二进制文件。

解读豆瓣的“指环王架构”

Thu, 20 Dec 2007 05:44:29 GMT

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

两台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）等等

Cookie的优化使用

Fri, 07 Sep 2007 17:25:38 GMT

最近IE项目经理EricLaw在微软官方的IEBlog上发了篇文章解释说明上个月（8月份）IE累积更新中MS07-045中关于Cookie Jar的部分的功能变化。

原来IE每个域限制cookie项目为20个，现在增到50个。以前为规避20个cookie的限制，很多编程者都是通过字典cookie的方式来解决。

但是有两个限制仍然没有改变：
1、DOM中的document.cookie属性只能检索客户端计算机上 cookie 的 4096 个字节。如果 cookie 字符串的长度超过 4096 个字节，则该属性将返回空字符串。
2、如果“Set-Cookie”头的长度超过 5118 个字节，则 Internet Explorer 和 HTTP Wininet API 将忽略“Set-Cookie”头。

虽然提升了cookie项目数量的限制，但是EricLaw出于功能和性能的原因考虑仍然建议尽量降低 cookie 的使用数量，并且要尽量使用小 cookie。另外，应用程序应能够处理 cookie 丢失。

他解释说：存在多个cookie时会增加HTTP请求次数，极大的降低浏览速度，如今的web用户上行/下行带宽是不对称的，通常下载速度要比上传速度快两到五倍。这意味着某些情况下，决定整体传输时间消耗时，HTTP的Request次数的影响比服务器端的Response次数的影响更大。

他提供了三种使用cookie的策略减少对站点性能的影响：
1、最小化cookie大小:使用最短的cookie名和cookie值
2、把静态内容发布到不同域上去：如果使用了许多静态资源（CSS、imgages、JS），它不会随cookie值变化，使用该法能取得良好的效果。比如你浏览Office Online clipart网站，你会注意到图片都来自http://officeimages.microsoft.com，而不是http://office.microsoft.com。这意味着大量设置在office.microsoft.com域的cookie不会发送到officeimage.microsoft.com站点上。
3、必要时用Path属性发送cookie：这类似于第2条。

文中还提到了如何保证cookie的安全性问题，他的建议是使用HttpOnly属性，说这样可以避免客户端跨站角本窃取cookie。根据我所了解的资料，HttpOnly属性是微软在IE上的一个功能扩展，这决定了这个功能可能受限于IE环境下。另外，如果有人用Flash内嵌的角本功能来窃取cookie，这个功能仍然是无能为力的，只能说这个属性有用，但作用有限。

凌晨服务器down机

Thu, 13 Jul 2006 04:22:41 GMT

　　今天早晨七点多，托管商机房客服务人员来电话说服务器down了，并做了Reboot。他们没有关于这次当机的详细记录。如果不是机房电源的问题，那服务器系统安全上可能存在问题，否则不会无缘无帮的当机。

　　分析了一下服务器日志，可以判定服务器在凌晨三点发生了一次reboot。在那个时间段内有一条日志：

事件类型: 信息
事件来源: USER32
事件种类: 无
事件 ID: 1074
日期:  2006-7-13
事件:  3:05:10
用户:  NT AUTHORITY\SYSTEM
计算机: ***-**0806
描述:
进程 winlogon.exe 已因下列原因为用户 NT AUTHORITY\SYSTEM 开始计算机 ***-**0806 的重新启动: 没有找到这个原因的标题
原因代码: 0x80020002
关机类型: 重新启动
注释:

有关更多信息，请参阅在 http://go.microsoft.com/fwlink/events.asp 的帮助和支持中心。
数据:
0000: 02 00 02 80

　　在微软技术支持网站上找不到事件ID为1074的解释记录。在查询原因代码0x80020002时，发现两篇文章提到了这个问题：

　　一篇微软的技术人员Tim Rain的　Is Windows Automatic Update Client rebooting your system unexpectedly? Read this to “fix” it…

　　另一篇发表在SecurityFocus.Com上的　RE: WSUS overriding GPO for reboot

　　Tim Rain解释的比较详尽些，虽然他说提XP应用，但是对服务器版本也应该同样适用的。可以断定的是，是因为Windows Automatic Update服务惹的祸，这几天微软确实发布了几个升级补丁。因为它导致了不可预期的重启动。不过这次自动重启却使服务器down机，就有些怪了。暂时只能假想系统升级时更新的补丁在生效前先停用了很多服务，自动重启时没能顺利恢复这些服务。需要观察几天。

　　Update（2006-8-8）:已经和机房工作人员确认，服务器的BIOS设置也存在问题。在重启动时，我的服务器需要按键盘F1键才能继续。这通常是在系统硬件自检时发现缺少必要的外设时系统会挂起。正好我的服务器安装系统升级更新自动重启动，但在硬件自检时发现没有键盘不能通过挂在当场。但是服务器一般不会专门提供一个键盘用于自检。已经要求机房人员在合适的时候重新设置BIOS跳过这项硬件自检。

随机提取access数据库记录的几种方法

Wed, 22 Mar 2006 15:31:03 GMT

　　前天有人在QQ群里问如何从Access数据库里随机抽取几条记录。这个问题如果放在SQL Server上就比较容易解决，比如随机抽取10条记录，采用的T-SQL语句是：
Select Top 10 * From [SomeTable] Order By NewID()
可以获得很好的效果，但是对于Access数据库而言就没有这么方便了。

　　在以前我也遇到过这样的问题，当时写一篇整理文字来讨论这个问题。这两天找到了这篇文字重新整理一下放在这里。

　　采用的Access数据库。总结了几种办法

　　方法一：有人用如下代码以记录总数为极大值来首先提取出指定数量的随机数，然后以这些随机数做为记录ID。

VBScript代码:

dim n,j
dim su()
dim a,b,k
b=myrs.RecordCount
Randomize
redim su(index_N)
su(1)=Int((b * Rnd) + 1)
for n=2 to index_N
a=Int((b * Rnd) + 1)
for j=1 to n
      do while a=su(j)
          a=Int((b* Rnd) + 1)
          j=1
      loop
next
su(n)=a
next

　　这种方式有一些问题，就是当主键ID不连续的话，有可能某些随机数不存在ID序列当中。另外ID的最大值与总的记录值不一定相等，这样有些记录ID会永远被忽略。

　　方法二：有人采用一条SQL语句解决此问题
　　select top 5 * From Table1 order by Rnd()*5
　　这条语句可以随机从Access数据库中摄取5条记录。但是实际操作中，其生成的记录结果是固定的，失去了随机摄取记录的意义。

　　方法三：有这样一种方法。
　　利用随机数生成主键的记录ID
　　yourstr="*1*3*4*6*12*...."
　　然后用
sql="select top 10 * form yourdb where instr('*'&id&'*','"&yourstr&"')<>0"
yourstr

　　可以生成随机数多一点大于所限定抽取的随机数为好。这样可以排除记录不足的情况。

　　此方法也不太好，而且采用InStr语句，不能利用索引优化，对资源有一定的消耗。

　　方法四：
　　代码实现如下：
<%
   n=10    ''取任意10条记录
   set rs = server.CreateObject ("adodb.recordset")
      sql = "select * from table"
      rs.open sql,conn,1,1
      count=rs.recordcount   ''记录总数
      IF Count<>empty Then
         Randomize
        for i = 1 to n       ''循环n次
           num=Fix(Rnd*count) ''num便是随机产生的记录行数，用Fix()，使其不会大于count值。
           rs.move num    ''移到改随机行
           Response.write rs(0)   ''出该条记录
        rs.movefirst     ''别忘了再把指针移到第一条
        next
      End IF
      rs.close
   set rs = nothing
%>
这个方式感觉上比较好些。

　　方法五：
　　此方法应该算是比较接近于SQL Server的用法了。
　　代码：
randomize '得到随机的种子，9999根据你的记录数量级调整，具体调到你出来的记录集随机序列均化
seed=round(rnd*9999)
'以下两种方法都可以，id是主键自增字段
Sql="select id,分值 from table where order by rnd(-"&seed&"-id-"&seed&")"

……

　　如果还有更好的方法也可以提出来。

　　看到一篇文章，也转链接于此：http://www.blueidea.com/bbs/NewsDetail.asp?DaysPrune=0&lp=1196&id=923452

服务器Web日志的分析

Fri, 10 Mar 2006 18:33:14 GMT

　　把代码又看了一下，核心类对搜索引擎识别的关键字不全，目前的列表是：
Google,Isaac,SurveyBot,Baiduspider,yahoo,yisou,3721,ia_archiver,P.Arthur,FAST-WebCrawler,Java,Microsoft-ATL-Native,TurnitinBot,WebGather,Sleipnir

　　这个列表不完整，停下手头工作分析了一下头天的服务器日志访问情况，检查UserAgent的记录出现了这样的记录：

　　msnbot/1.0+(+http://search.msn.com/msnbot.htm)
　　这个自然是微软的msn的搜索引擎，今日msn的spider超过了其它的任何搜索引擎，看得出它的确很卖力。

　　Baiduspider+(+http://www.baidu.com/search/spider.htm)
　　百度的

　　Mozilla/5.0+(compatible;+iaskspider/1.0;+MSIE+6.0)
　　iaskspider
　　这两条是来自新浪的。来自新浪的搜索机器人useragent标识有两个，从IP看都来自于相同的B类网段，似乎搜索作用有所不同作用有所不同，后一个标识记录数非常少。

　　Mozilla/5.0+(compatible;+Googlebot/2.1;++http://www.google.com/bot.html)
Mediapartners-Google/2.1
　　均来自google，虽然标识不同，但从来访IP看都是一个。

　　InetURL:/1.0
　　这个标识没见过，检查它访问的网址，NND，可以断定这绝对是一个黑客扫描软件。在扫描漏洞。记下这家伙的IP。

　　mp3Spider+cn-search-devel+at+yahoo-inc+dot+com
　　标识上看应该是yahoo中国的mp3的搜索机器人

　　Mozilla/3.0+(Macintosh;+I;+PPC)
　　哈，这个别致，象是用苹果公司的电脑在访问，或者用苹果出的PPC智能手机设备在浏览网站，真如此这也太cool了点吧。

　　根据上述记录分析，增加"iaskspider"的和"msnbot"两个词。看来新浪搜索力度也不小，不过这天日志没有搜狗网的搜索引擎来访记录确实有些不应该。

　　来访的搜索引擎中，google、msn、yahoo、baidu中国都抓取了robots.txt文件，唯独新浪的iaskspider没做此项操作，因此对新浪搜索引擎不按规则办事要注意，省得一不小心一大堆不想被检索的东东被它搜索出来发布出去。

关于内存不可读

Wed, 23 Nov 2005 01:57:26 GMT

一般内存不可读多是因为系统自身不稳定的问题，以前windows 9X/ME的系统中经常出现这样的问题，通常是IE浏览器出现的问题最多。但是自从系统进入Windows 2000以后的系统后，出现这样问题的机会很少。

但是出现这样的问题后有些人的解决思路就是想当然的认为硬件内存出了问题，甚至有些技术人员也有这样的想法。其实这种可能性非常小，大部分原因是在操作系统内存读写安全的保护机制上。经常用一些未经严格测试的所谓系统优化工具也会人为造成这样的后果。

由于测试需要，我的操作系统由Win2K Server更新成了Windows Server 2K3。基本上还算顺利，但是出现了一个问题就是我题目说的内存不可读问题。影响的程序有两个，一个是skype，一个是资料收藏大师（功能受限的未注册版本）。这两个软件以前在Win2K Server上一直运行很正常，但升级成2K3为什么就不行了呢？在网上搜索了很久也没有得到答案，包括在微软官方提供的文档对于内存不可读问题也都不能对我的这个问题进行有效解决。

甚至我还发现，金山词霸2005版不能动态取词了，还有QQ的取IP外挂也不能运行。

以上这些问题一直困扰了我近一个月，今天突然意外幸运的解决了，让我开心不已把解决方法总结如下。

因为最近刚买了一款Motorola的Smart Phone，装有微软的Smart Phone2003操作系统，所以特想了解一下Smart Phone的开发技术，就从微软网站上下载了Smart Phone 2003的SDK，安装Active Sync。系统会自动安装一个Virtual Emulator，重启动后这个虚拟设备会提示报错不能启用。根据错误提示找到这个微软支持网站相应链接：

http://support.microsoft.com/default.aspx?scid=kb;en-us;883989

根据页面说明，出现这种问题原因是由于PAE（ Physical Address Extension）模式被启用所致，仅影响基于Windows XP以上的系统。只要将boot.ini中的/PAE选项删除即可。

但是并没有在我的boot.ini文件中发现有这个选项。我的boot.ini文件：

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Enterprise" /noexecute=optout /fastdetect

但是由这个页面找到了另一个相关的解决思路：

http://support.microsoft.com/kb/891667/

这个页面提到了DAE（Data Execution Prevention）硬件错误，并提到受影响的操作系统是Windows XP SP2以上级别的电脑，受影响的硬件主要是64位的CPU系统（Intel IA-64,AMD Athlon 64, AMD Opteron processors）。这与我的Win Server 2K3 SP1大致相近，我的CPU是AMD64位的。文中提到一个建议的修改方式：

1. Click Start, click Run, type sysdm.cpl, and then click OK.
2. In the System Properties dialog box, click the Advanced tab.
3. Under Start and Recovery, click Settings.
4. In the Startup and Recovery dialog box, click Edit.
5. Disable PAE mode by removing the /pae option if it exists.
6. Remove the /noexecute option if it exists.
7. Add the /execute option.
8. On the File menu, click Save.
9. To exit Notepad, click Exit on the File menu.
10. To close System Properties, click OK two times.
11. Restart your computer

之所以采用数据执行保护（DAE）是微软为了加强系统安全最大限度减少对系统的恶意攻击所采取的措施。如果按照上述过程取消了DAE保护机制，按照微软的说法，你必须仔细评估所面临的风险。

经过上述步骤我的boot.ini文件变成：

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Enterprise" /execute /fastdetect

重启动后恢复正常。上面提到的所有问题都解决了。

多多小虫 天行健: 技术总结