可以使用以下命令来清空squid的缓存：

代码:
/usr/bin/wget -O squid.log -S –header=”ragma: no-cache”  url

代码:

squidclient -m PURGE -p 80 “http://you.video.sina.com.cn/index.html”

代码:

http://www.cdn.com/api/purge.php?action=purge&host=61.55.111.111&url=http://www.md5.cn/

一款老外的程序，可以批量清除某类URL的Squid缓存，支持正则表达式。

　　下载网址：http://www.wa.apana.org.au/~dean/squidpurge/

　　编译：
代码:
wget http://www.wa.apana.org.au/~dean … 20040201-src.tar.gz
tar zxvf purge-20040201-src.tar.gz
cd purge
make
　　清除Squid缓存示例：
　　1、清除 URL 以“.mp3”结尾的缓存文件（例如 http://www.s135.com/abc.mp3、http://www.s135.com/01/a.mp3）
代码:
./purge -p localhost:80 -P 1 -se ‘\.mp3$’
　　2、清除URL中包含s135.com的所有缓存：
代码:
./purge -p localhost:80 -P 1 -se ‘s135.com’
　　我喜欢将程序推到后台去执行，让它慢慢地去清Squid缓存，同时将输出内容记录到purge.log文件：
代码:
./purge -p localhost:80 -P 1 -se ‘s135.com’ > purge.log 2>&1

　Squid web缓存加速软件目前已经是新浪、搜狐、网易等各大网站广泛应用。Squid会在设置的缓存目录下建立多个目录，每一个目录下又建立多个目录，然后才在最里层的目录中存放缓存文件（object）。squid会根据用户请求网页的URL进行哈希，生成缓存文件，存放在某一个目录中。squid启动之后，将在内存中建立一个哈希表，记录硬盘中缓存文件配置的情形。

　　对于类似http://you.video.sina.com.cn/index.html之类的网页，squid只会生成一个缓存文件。可以用squid附带的squidclient工具清除：

代码:
squidclient -m PURGE -p 80 “http://you.video.sina.com.cn/index.html”
　　而对于带有参数的网页，例如新浪播客的Flash播放器http://vhead.blog.sina.com.cn/pl … 9852&uid=1278987704，因“?”后面的参数不同，导致URL也不同，squid会生成多个缓存文件，哈希分散存放在不同的目录。如果修改了这个outer_player.swf文件，要更新squid缓存就要去清除不同目录下及内存中的很多个缓存文件，十分麻烦，于是我编写了一个Linux下的shell脚本，去完成这件麻烦的事：

　　脚本文件名：clear_squid_cache.sh（8月2日修正了UC网友“城市中的寂寞”反馈的BUG）

代码:
#!/bin/sh
squidcache_path=”/data1/squid/var/cache”
squidclient_path=”/usr/local/squid/bin/squidclient”
grep -a -r $1 $squidcache_path/* | strings | grep “http:” | awk -F’http:’ ‘{print “http:”$2;}’ > cache_list.txt
for url in `cat cache_list.txt`; do
$squidclient_path -m PURGE -p 80 $url
done
　　注意：请赋予clear_squid_cache.sh可执行权限（命令：chmod +x ./clear_squid_cache.sh）。请确保脚本所在目录可写。

　　设置：
　　squidcache_path= 表示squid缓存目录的路径
　　squidclient_path= 表示squidclient程序所在的路径，默认为squid安装目录下的bin/squidclient

　　用法：
　　1、清除所有Flash缓存（扩展名.swf）：
　　
代码:
./clear_squid_cache.sh swf
　　2、清除URL中包含sina.com.cn的所有缓存：
　　
代码:
./clear_squid_cache.sh sina.com.cn
　　3、清除文件名为zhangyan.jpg的所有缓存：
　　
代码:
./clear_squid_cache.sh zhangyan.jpg
　　效率：
　　经测试，在DELL 2950上清除26000个缓存文件用时2分钟左右。平均每秒可清除缓存文件177个。

相关文章

• PHP & memcached (0)
• google背后的分布式架构 (0)
• 大型高并发高负载网站的系统架构 (0)
• 免费软件套装 (0)
• 使用memcached进行内存缓存 (0)

从外部加载媒体（Media）
Heider提到了一个常用的Flex最佳实践——限制嵌入到应用/SWF文件中的媒体的数量，如图像、影片及mp3等资源都可以从外部的SWF文件加载。 Flex框架可以直接将图片、mp3及字体等资源编译到SWF中。当你想让最终用户获得全部资源时，这种方式确实能派上用场，但是这会导致你的应用长时间停留在“Loading”阶段。中国最大的RIA分享社区-与中国闪客一起成长和发展！

在嵌入式字体中限制字符集
Heider建议在嵌入式字体中限制字符集以降低SWF文件的总下载时间： 当你在Flex中嵌入一种字体时，你就会获得该字体的全部字符的支持。尽管这可能是你想要的，但你确信你需要全部字符么？例如，在一个只面向英文的应用中，你确信你真的想花时间下载中文字符数据么？
缓存框架

Heider回顾了Flex 3 support for runtime-shared-libraries （RSL）这篇文章：从Flex 3开始，你可以将Adobe签名的框架——RSLs缓存到Flash Player的cache中。这有两个好处。首先，缓存在Flash Player cache中的签名的框架RSLs可由所有配置好的Flex应用共享。换句话说，如果某人的应用已经下载了500k的签名的框架RSL，并且该RSL仍旧 在Flash Player cache中，那么你的应用就可以使用缓存下来的RSL。其次，即使某人清空了其浏览器缓存，对Flash Player cache也没有任何影响。

考虑模块化
Heider谈到了将Flex应用划分成模块的好处：减少字体加载时间的另一种方式就是将你的Flex应用划分成模块。使用模块的一个好处在于当加载和卸载模块时你能完全操控它。
之所以要划分成模块的最后一个原因是他们更快，而且我能即时加载它们。换句话说，在启动时唯一需要加载的模块就是 Step1.swf模块。因此，在使用模块的情况下，最终用户节省了启动时间，但是当他从一个模块切换到另一个模块时却需要花更多时间，因为每个模块都需 要以JIT形式加载。在我的应用中，只有当用户首次在steps 1-5之间切换时需要花更多时间。

推迟实例化
Heider围绕着Flex组件的“creationPolicy”属性及何时实例化应用的不同部分给出了很多建议。如果你想减少从数据下载到用户真正可以使用的总时间，当务之急就是推迟实例化。这项技术背后的理念就是直到应用真正使用的时候才在内存中创建对象。尽管推迟实例化技术会在应用的整个使用过程中导致少许——通常不那么明显——的延迟，但与长时间的启动延迟相比，它还是可接受的。推迟实例化的另一个好处在于内存使用的优化。 Heider还谈到了一个“实验性”的条款——“使用流”，这是他在讨论Dirk Eismann的帖子（Building monolithic Flex SWFs that still startup quickly.”）时谈及的。Eismann提出一项技术以利用Flash Player中的多个frames以在部分应用中达到流的目的。查看所有的帖子以更多地了解该技术及关于加快Flex启动速度的建议。中国最大的RIA分享社区-与中国闪客一起成长和发展！)

原文出处：http://www.infoq.com/cn/news/2008/05/flex-startup-time

相关文章

• flickr对javascript干的好事 (0)
• 清除指定squid缓存文件的脚本 (0)
• 大型高并发高负载网站的系统架构 (0)
• google背后的分布式架构 (0)
• 应用加速 (0)

　　加利福尼亚州山景城(Mountain View)Google公司(Google，下称Google)总部有一个43号大楼，该建筑的中央大屏幕上显示着一个与Google地球(Google Earth)相仿的世界地图，一个转动的地球上不停地闪动着五颜六色的光点，恍如罗马宫廷的千万烛灯，每一次闪动标志着地球的这个角落一名Google用 户发起了一次新的搜索。

　　这同时意味着Google又一次满足了人们对未知信息的好奇与渴望。

　　Google是与众不同的。它的独特不仅仅表现于革新的思维和充满创意的应用 (比如那个大堂里的地球模型)，更在于其有别常规的IT策略。从人们的常理来看，简单的硬件商品和免费软件是无法构建出一个帝国的，但是Google做到 了。在性能调整后，Google把它们变成一个无可比拟的分布式计算平台，该平台能够支持大规模的搜索和不断涌现的新兴应用。我们原本认为这些应用都是个 人消费级别的，但是Google改变了这一切。现在商业世界也在使用它们，这就令这家搜索公司显得那么与众不同。

　　GoogleWeb 服务背后的IT架构对无数使用搜索引擎的用户来说也许并不是非常重要，但它是Google几百位致力于把全球信息组织起来，实现“随处可达，随时可用”目 标的工程师们的最核心工作。这就需要一个在覆盖范围和野心上都与Google的商业愿景完全相符的IT蓝图作为支撑。

　　Google 的经理们一直对公司的IT策略话题保持沉默，他们厌恶谈及特定的厂商或者产品，当被问到他们的服务器和数据中心时，他们总是闭口不谈。但与几位 Google的IT领导一起呆了一天后，我们最终得以揭示该公司的IT是如何运作的，那可不仅仅是一个运行在无数服务器集群上的、表面看来非常简单的搜索 引擎。在其简单的外表下，蕴涵着许多内部研发软件、定制硬件、人工智能，以及对性能的执着追求和打破常规的人力管理模式。

　　IT理念方面，Google对同行有一条建议：尽量避免那些人人都在使用的系统和软件，以自己的方式做事会更有独特的竞争优势。

　　“企业文化决定了你的做事方式。”道格拉斯”美林(Douglas Merrill)，这位Google工程副总裁和事实上的首席信息官(CIO) 指出，“到了我们这样的发展阶段，企业观念和文化非常与众不同，这也反过来鞭策我们必须要采用与众不同的方式来运行那些他人看来很常规的系统。”
　　Google 最大的IT优势在于它能建造出既富于性价比(并非廉价)又能承受极高负载的高性能系统。因此IT顾问史蒂芬”阿诺德(Stephen Arnold)指出，Google与竞争对手，如亚马逊网站(Amazon)、电子港湾公司(eBay)、微软公司(Microsoft，下称微软)和雅 虎公司 (Yahoo，下称雅虎)等公司相比，具有更大的成本优势。Google程序员的效率比其他Web公司同行们高出50%～100%，原因是Google已 经开发出了一整套专用于支持大规模并行系统编程的定制软件库。据他估算，其他竞争公司可能要花上四倍的时间才能获得同等的效果。

　　打造服务器

　　Google 究竟是怎样做到这点的呢?其中一个手段，美林认为，“是因为我们自己动手打造硬件。”Google并不制造计算机系统，但它根据自己的参数定制硬件，然后 像MTV的节目“靓车打造”(Pimp My Ride)那样自己安装和调整硬件系统。开源程序经理克里斯”迪博纳(Chris DiBona)评论道：“我们很善于购买商业服务器，并且改造他们为我们所用，最后把性能压榨和发挥到极致，以致有时候他们热得像要融化了似的。”

　　这种亲手打造的方式，来源于Google从车库诞生时与生俱来的节俭风格，更与Google那超大型的系统规模息息相关，良好的习惯一直延续至 今。据说 Google在65个数据中心拥有20万～45万台服务器—这个数目会有偏差(取决于你如何定义服务器和由谁来做这项统计)。但是，不变的是持续上升的趋势。

　　Google不会去讨论这些资产，因为它认为保密也是一种竞争优势。事实上，Google之所以喜欢开源软件也是因为它的私密性。“如果我们购 买了软件许可或代码许可，人们只要对号入座，就可以猜出Google的IT基础架构。”迪博纳分析说， “使用开源软件，就使我们多了一条把握自己命运的途径。”

　　Google喜欢规模化的服务器运行方式。当有成百上千台机器时，定制服务器的优势也会成倍增加，效果也会更趋明显。Google正在俄勒冈州 哥伦比亚河边的达勒斯市建造一个占地30亩的数据中心，在那儿它可以获得运算和降温需要的低价水力电力能源(参见边栏《Google数据中心自有一套》)。

　　Google以“单元”(Cell)的形式组织这些运行 Linux操作系统的服务器，迪博纳把这种形式比喻成互联网服务的“磁盘驱动器”(但别和一直谣传的Google存储服务Gdrive混淆了，“并没有 Gdrive这回事。”一位Google女发言人明确表示。)，公司的软件程序都驻扎在这些并不昂贵的电脑机箱里，由程序员决定它们的冗余工作量。这种由 很多单元组成的文件系统代替了商业存储设备;迪博纳表示Google这些单元设备更易于建造和维护，他还暗示他们能处理更大规模的数据。

　　Google 不会漏过对任何技术细节的关注。多年来，公司的工程师就在研究微处理器的内部工作机制，随着Google规模的持续壮大，必然会用到特别定制和调节过的芯 片。知名工程师路易斯”巴罗索(Luiz Barroso)去年在一篇发表在工业杂志上的论文中证实，近年来Google的主要负荷都由单核设计的系统承担着。但许多服务器端的应用，如 Google搜索索引服务，所需的并行计算在单核芯片的指令级别上执行得并不好。

　　曾在数据设备公司(Digital Equipment)和康柏公司(Compaq)当过芯片设计师的巴罗索认为，随着AMD公司、英特尔公司(Intel)、太阳计算机系统公司(Sun)开始制造多核芯片，必将会出现越来越多芯片级别的并行计算。

　　Google 也曾考虑过自己制造计算机芯片，但从业界潮流来看，这个冒险的举动似乎不是很必要。“微处理器的设计非常复杂而且成本昂贵，”运营高级副总裁乌尔斯”霍尔 茨勒(Urs Holzle)表示。Google宁愿与芯片制造商合作，让他们去理解自己的应用并设计适合的芯片。这是一种客户建议式的设计，其关注点在于总体吞吐量、 效能，以及耗电比，而不是看单线程的峰值性能。霍尔茨勒表示，“这也是最近多核CPU的设计潮流与未来方向。”
裁缝般地定制软件

　　为了能尽量压榨硬件性能，Google开发了相当数量的定制软件。创新产品主要包括用于简化处理和创建大规模数据集的编程模型 MapReduce;用于存储和管理大规模数据的系统BigTable;分析分布式运算环境中大规模数据集的解释编程语言Sawzall;用于数据密集型 应用的分布式文件系统的 “Google文件系统”(Google File System);还有为处理分布式系统队列分组和任务调度的“Google工作队列”(Google Workqueue)。

　　正是从Sawzall这些工具里体现出Google对计算效率的执著关注。并不是每家公司都能从底层去解决效率问题，但是对Google来说， 为常规关系型数据库无法容纳的大规模数据集专门设计一种编程语言是完全合理的。即使其他编程工具可以解决问题，Google的工程师们仍然会为了追求效率 而另外开发一套定制方案。Google工程师认为，Sawzall能与C++中的MapReduce相媲美，而且它更容易编写一些。

　　Google 对效率的关注使它不可能对标准Linux内核感到满意;Google会根据自己的需要运行修改过的内核版本。通过调整Linux的底层性能，Google 工程师们在提高了整体系统可靠性的基础上，还一并解决了数据损坏和数据瓶颈等一系列棘手问题。对内核的修改也使Google的计算机集群系统因为通信效率 的提高而运行得更快。

　　当然，Google偶尔也会出现系统故障，情况一旦发生，无数的用户就会受到影响了。三年前一次持续30分钟的系统故障使20%的搜索流量受到影响。

　　Google 开发了自己的网站服务器却没有使用开源的Apache服务器，尽管它在网站服务器的市场占有率超过60%。迪博纳认为，Google的网站服务器可以运行 在更多数量的主机上，对Google站点上内容庞大又彼此互相依赖的应用程序来说，这种服务器的负载均衡能力远比Apache的能力更高。同时，在用标准 公共网关接口(CGI)访问数据库动态网页方面，Google服务器的编程难度要比 Apache更高，但是最终运行速度却更快。“如果我们能够压榨出10%～20%的性能，我们就可以节省出更多系统资源、电量和人力了。”迪博纳在总结中指出。

　　Google还设计了自己的客户关系管理(CRM)系统用于支持自己基于竞价和点击的互联网广告收费业务。但对是否需要设计自己的工具，Google的态度也不是一成不变的。比如在财会软件上，它就使用了甲骨文公司(Oracle)的Financials软件。

　　美林拿着一只叉子举例说明现成的产品也可以带来价值。但在有些场合现成的软件产品就不一定适用了。“我们的文化在各个层面对我们的运作都有深远影响，”他表示，“所以我们不想让购买所得的工具改变我们的工作方式和文化层面。”
Google’s BigTable 原理 （翻译）

题记：google 的成功除了一个个出色的创意外，还因为有 Jeff Dean 这样的软件架构天才。
—— 编者

官方的 Google Reader blog 中有对BigTable 的解释。这是Google 内部开发的一个用来处理大数据量的系统。这种系统适合处理半结构化的数据比如 RSS 数据源。 以下发言 是 Andrew Hitchcock 在 2005 年10月18号 基于： Google 的工程师 Jeff Dean 在华盛顿大学的一次谈话 (Creative Commons License).

首先，BigTable 从 2004 年初就开始研发了，到现在为止已经用了将近8个月。（2005年2月）目前大概有100个左右的服务使用BigTable，比如： Print,Search History,Maps和 Orkut。根据Google的一贯做法，内部开发的BigTable是为跑在廉价的PC机上设计的。BigTable 让Google在提供新服务时的运行成本降低，最大限度地利用了计算能力。

BigTable 是建立在 GFS ，Scheduler ，Lock Service 和 MapReduce 之上的。

每个Table都是一个多维的稀疏图 sparse map。Table 由行和列组成，并且每个存储单元 cell 都有一个时间戳。在不同的时间对同一个存储单元cell有多份拷贝，这样就可以记录数据的变动情况。在他的例子中，行是URLs ，列可以定义一个名字，比如：contents。Contents 字段就可以存储文件的数据。或者列名是：”language”，可以存储一个“EN”的语言代码字符串。

为了管理巨大的Table，把Table根据行分割，这些分割后的数据统称为：Tablets。每 个Tablets大概有 100-200 MB，每个机器存储100个左右的 Tablets。底层的架构是：GFS。由于GFS是一种分布式的文件系统，采用Tablets的机制后，可以获得很好的负载均衡。比如：可以把经常响应 的表移动到其他空闲机器上，然后快速重建。

Tablets在系统中的存储方式是不可修改的 immutable 的SSTables，一台机器一个日志文件。当系统的内存满后，系统会压缩一些Tablets。由于Jeff在论述这点的时候说的很快，所以我没有时间把听到的都记录下来，因此下面是一个大概的说明：

压缩分为：主要和次要的两部分。次要的压缩仅仅包括几个Tablets，而主要的压缩时关于整个系统的压缩。主压缩有回收硬盘空间的功能。Tablets的位置实际上是存储在几个特殊的BigTable的存储单元cell中。看起来这是一个三层的系统。
客户端有一个指向METAO的Tablets的指针。如果METAO的Tablets被频繁使用，那个这台机器就会放弃其他的tablets专门支持 METAO这个Tablets。METAO tablets 保持着所有的META1的tablets的记录。这些tablets中包含着查找tablets的实际位置。（老实说翻译到这里，我也不太明白。）在这个系统中不存在大的瓶颈，因为被频繁调用的数据已经被提前获得并进行了缓存。

现在我们返回到对列的说明：列是类似下面的形式： family:optional_qualifier。在他的例子中，行：www.search-analysis.com 也许有列：”contents:其中包含html页面的代码。 “ anchor:cnn.com/news” 中包含着 相对应的url，”anchor:www.search-analysis.com/” 包含着链接的文字部分。列中包含着类型信息。
(翻译到这里我要插一句，以前我看过一个关于万能数据库的文章，当时很激动，就联系了作者，现在回想起来，或许google的 bigtable 才是更好的方案，切不说分布式的特性，就是这种建华的表结构就很有用处。)

注意这里说的是列信息，而不是列类型。列的信息是如下信息，一般是：属性/规则。 比如：保存n份数据的拷贝或者保存数据n天长等等。当 tablets 重新建立的时候，就运用上面的规则，剔出不符合条件的记录。由于设计上的原因，列本身的创建是很容易的，但是跟列相关的功能确实非常复杂的，比如上文提到 的 类型和规则信息等。为了优化读取速度，列的功能被分割然后以组的方式存储在所建索引的机器上。这些被分割后的组作用于 列 ,然后被分割成不同的 SSTables。这种方式可以提高系统的性能，因为小的，频繁读取的列可以被单独存储，和那些大的不经常访问的列隔离开来。

在一台机器上的所有的 tablets 共享一个log，在一个包含1亿的tablets的集群中，这将会导致非常多的文件被打开和写操作。新的log块经常被创建，一般是64M大小，这个GFS的块大小相等。当一个机器down掉后，控制机器就会重新发布他的log块到其他机器上继续进行处理。这台机器重建tablets然后询问控制机器处理结构的存储位置，然后直接对重建后的数据进行处理。这个系统中有很多冗余数据，因此在系统中大量使用了压缩技术。

Dean 对压缩的部分说的很快，我没有完全记下来，所以我还是说个大概吧：压缩前先寻找相似的 \行，列，和时间数据。

他们使用不同版本的： BMDiff 和 Zippy 技术。

BMDiff 提供给他们非常快的写速度： 100MB/s – 1000MB/s 。Zippy 是和 LZW 类似的。Zippy 并不像 LZW 或者 gzip 那样压缩比高，但是他处理速度非常快。

Dean 还给了一个关于压缩 web 蜘蛛数据的例子。这个例子的蜘蛛 包含 2.1B 的页面，行按照以下的方式命名：“com.cnn.www/index.html:http”.在未压缩前的web page 页面大小是：45.1 TB ，压缩后的大小是：4.2 TB ， 只是原来的 9.2%。Links 数据压缩到原来的 13.9% , 链接文本数据压缩到原来的 12.7%。

Google 还有很多没有添加但是已经考虑的功能。
1. 数据操作表达式，这样可以把脚本发送到客户端来提供修改数据的功能。
2. 多行数据的事物支持。
3. 提高大数据存储单元的效率。
4. BigTable 作为服务运行。
好像：每个服务比如： maps 和 search history 历史搜索记录都有他们自己的集群运行 BigTable。
他们还考虑运行一个全局的 BigTable 系统，但这需要比较公平的分割资源和计算时间。

大表(Bigtable):结构化数据的分布存储系统

http://labs.google.com/papers/bigtable-osdi06.pdf

｛中是译者评论,程序除外｝
{本文的翻译可能有不准确的地方,详细资料请参考原文.}

摘要
bigtable是设计来分布存储大规模结构化数据的，从设计上它可以扩展到上２^50字节，分布存储在几千个普通服务器上．google的很多项目使用 bt来存储数据，包括网页查询，google earth和google金融．这些应用程序对bt的要求各不相同：数据大小（从URL到网页到卫星图象）不同，反应速度不同（从后端的大批处理到实时数 据服务）．对于不同的要求，bt都成功的提供了灵活高效的服务．在本文中，我们将描述bt的数据模型．这个数据模型让用户动态的控制数据的分布和结构．我 们还将描述BT的设计和实现．
１．介绍
在过去两年半里，我们设计，实现并部署了BT．BT是用来分布存储和管理结构化数据的．BT的设计使它能够管理2^50 bytes(petabytes)数据，并可以部署到上千台机器上．BT完成了以下目标：应用广泛，可扩展，高性能和高可用性（high availability）. 包括google analytics, google finance, orkut, personalized search, writely和google earth在内的60多个项目都使用BT.这些应用对BT的要求各不相同，有的需要高吞吐量的批处理，有的需要快速反应给用户数据．它们使用的BT集群也各不相同，有的只有几台机器，有的有上千台，能够存储2^40字节(terabytes)数据．
BT在很多地方和数据库很类似：它使用了很多数据库的实现策略．并行数据库[14]和内存数据库[13]有可扩展性和高性能，但是BT的界面不同．BT不支持完全的关系数据模型；而是为客户提供了简单的数据模型，让客户来动态控制数据的分布和格式{就是只存储字串，格式由客户来解释}，并允许客户推断底层存储数据的局部性｛以提高访问速度｝．数据下标是行和列的名字，数据本身可以是任何字串．BT的数据是字串，没有解释｛类型等｝．客户会在把各种结构或者半结构化的数据串行化｛比如说日期串｝到数据中．通过仔细选择数据表示，客户可以控制数据的局部化．最后，可以使用BT模式来控制数据是放在内存里还是在硬盘上．｛就是说用模式，你可以把数据放在离应用最近的地方．毕竟程序在一个时间只用到一块数据．在体系结构里，就是：locality, locality, locality｝
第二节描述数据模型细节．第三节关于客户API概述．第四节简介BT依赖的google框架．第五节描述BT的实现关键部分．第6节叙述提高BT性 能的一些调整．第7节提供BT性能的数据．在第8节，我们提供BT的几个使用例子，第9节是经验教训．在第10节，我们列出相关研究．最后是我们的结论．
２．数据模型
BT是一个稀疏的，长期存储的｛存在硬盘上｝，多维度的，排序的映射表．这张表的索引是行关键字，列关键字和时间戳．每个值是一个不解释的字符数组．｛数据都是字符串，没类型，客户要解释就自力更生吧｝．
(row:string, column:string,time:int64)->string {能编程序的都能读懂，不翻译了}
我们仔细查看过好些类似bigtable的系统之后定下了这个数据模型。举一个具体例子（它促使我们做出某些设计决定）， 比如我们想要存储大量网页及相关信息，以用于很多不同的项目；我们姑且叫它Webtable。在Webtable里，我们将用URL作为行关键字，用网页 的某些属性作为列名，把网页内容存在contents:列中并用获取该网页的时间戳作为标识，如图一所示。
图一：一个存储Web网页的范例列表片断。行名是一个反向URL｛即com.cnn.www｝。contents列族｛原文用 family，译为族，详见列族｝ 存放网页内容，anchor列族存放引用该网页的锚链接文本。CNN的主页被Sports Illustrater｛即所谓SI，CNN的王牌体育节目｝和MY-look的主页引用，因此该行包含了名叫“anchor:cnnsi.com”和 “anchhor:my.look.ca”的列。每个锚链接只有一个版本｛由时间戳标识，如t9，t8｝；而contents列则有三个版本，分别由时间 戳t3，t5，和t6标识。
行
表中的行关键字可以是任意字符串（目前支持最多64KB，多数情况下10－100字节足够了）。在一个行关键字下的每一个读写操作都是原子操作（不管读写这一行里多少个不同列），这是一个设计决定，这样在对同一行进行并发操作时，用户对于系统行为更容易理解和掌控。
Bigtable通过行关键字的字典序来维护数据。一张表可以动态划分成多个连续行。连续行在这里叫做“子表”｛tablet｝，是数据分布和负载 均衡的单位。这样一来，读较少的连续行就比较有效率，通常只需要较少机器之间的通信即可。用户可以利用这个属性来选择行关键字，从而达到较好数据访问地域 性｛locality｝。举例来说，在Webtable里，通过反转URL中主机名的方式，可以把同一个域名下的网页组织成连续行。具体来说，可以把 maps.google.com/index.html中的数据存放在关键字com.google.maps/index.html下。按照相同或属性相 近的域名来存放网页可以让基于主机和基于域名的分析更加有效。
列族
一组列关键字组成了“列族”，这是访问控制的基本单位。同一列族下存放的所有数据通常都是同一类型（同一列族下的数据可压缩在一起）。列族必须先创 建，然后在能在其中的列关键字下存放数据；列族创建后，族中任何一个列关键字均可使用。我们希望，一张表中的不同列族不能太多（最多几百个），并且列族在 运作中绝少改变。作为对比，一张表可以有无限列。
列关键字用如下语法命名：列族：限定词。 列族名必须是看得懂｛printable｝的字串，而限定词可以是任意字符串。比如，Webtable可以有个列族叫language，存放撰写网页的语 言。我们在language列族中只用一个列关键字，用来存放每个网页的语言标识符。该表的另一个有用的列族是anchor；给列族的每一个列关键字代表 一个锚链接，如图一所示。而这里的限定词则是引用该网页的站点名；表中一个表项存放的是链接文本。
访问控制，磁盘使用统计，内存使用统计，均可在列族这个层面进行。在Webtable举例中，我们可以用这些控制来管理不同应用：有的应用添加新的基本数据，有的读取基本数据并创建引申的列族，有的则只能浏览数据（甚至可能因为隐私权原因不能浏览所有数据）。
时间戳
Bigtable表中每一个表项都可以包含同一数据的多个版本，由时间戳来索引。Bigtable的时间戳是64位整型。可以由Bigtable来 赋值，表示准确到毫秒的“实时”；或者由用户应用程序来赋值。需要避免冲突的应用程序必须自己产生具有唯一性的时间戳。不同版本的表项内容按时间戳倒序排 列，即最新的排在前面。
为了简化对于不同数据版本的数据的管理，我们对每一个列族支持两个设定，以便于Bigtable对表项的版本自动进行垃圾清除。用户可以指明只保留表项的最后n个版本，或者只保留足够新的版本（比如，只保留最近7天的内容）。
在Webtable举例中，我们在contents:列中存放确切爬行一个网页的时间戳。如上所述的垃圾清除机制可以让我们只保留每个网页的最近三个版本。
3.API
BT的API提供了建立和删除表和列族的函数．还提供了函数来修改集群，表和列族的元数据，比如说访问权限．
// Open the table
Table *T = OpenOrDie(”/bigtable/web/webtable”);
// Write a new anchor and delete an old anchor
RowMutation r1(T, “com.cnn.www”);
r1.Set(”anchor:www.c-span.org”, “CNN”);
r1.Delete(”anchor:www.abc.com”);
Operation op;
Apply(&op, &r1);
图 2: 写入Bigtable.
在BT中，客户应用可以写或者删除值，从每个行中找值，或者遍历一个表中的数据子集．图2的c++代码是使用RowMutation抽象表示来进行一系列的更新（为保证代码精简，没有包括无关的细节）．调用Apply函数，就对Ｗebtable进行了一个原子修改：它为http://www.cnn.com/增加了一个锚点，并删除了另外一个锚点．
Scanner scanner(T);
ScanStream *stream;
stream = scanner.FetchColumnFamily(”anchor”);
stream->SetReturnAllVersions();
scanner.Lookup(”com.cnn.www”);
for (; !stream->Done(); stream->Next()) {
printf(”%s %s %lld %s\n”,
scanner.RowName(),
stream->ColumnName(),
stream->MicroTimestamp(),
stream->Value());
}
图3: 从Bigtable读数据.
图3的C++代码是使用Scanner抽象来遍历一个行内的所有锚点．客户可以遍历多个列族．有很多方法可以限制一次扫描中产生的行，列和时间戳． 例如，我们可以限制上面的扫描，让它只找到那些匹配正则表达式*.cnn.com的锚点，或者那些时间戳在当前时间前10天的锚点．
BT还支持其他一些更复杂的处理数据的功能．首先，BT支持单行处理．这个功能可以用来对存储在一个行关键字下的数据进行原子的读-修改-写操作． BT目前不支持跨行关键字的处理，但是它有一个界面，可以用来让客户进行批量的跨行关键字处理操作．其次，BT允许把每个表项用做整数记数器．最后，BT 支持在服务器的地址空间内执行客户端提供的脚本程序．脚本程序的语言是google开发的Sawzall[28]数据处理语言．目前，我们基于的 Sawzall的API还不允许客户脚本程序向BT内写数据，但是它允许多种形式的数据变换，基于任何表达式的过滤和通过多种操作符的摘要．
BT可以和MapReduce[12]一起使用．MapReduce是google开发的大规模并行计算框架．我们为编写了一套外层程序，使BT可以作为MapReduce处理的数据源头和输出结果．
4.建立BT的基本单元
BT是建立在其他数个google框架单元上的．BT使用google分布式文件系统(GFS)[17]来存储日志和数据文件{yeah, right, what else can it use, FAT32?}．一个BT集群通常在一个共享的机器池中工作，池中的机器还运行其他的分布式应用{虽然机器便宜的跟白菜似的，可是一样要运行多个程序，命苦的象小白菜}，BT和其他程序共享机器｛BT的瓶颈是ＩＯ/内存，可以和CPU要求高的程序并存｝．BT依赖集群管理系统来安排工作，在共享的机器上管理资源，处理失效机器并监视机器状态｛典型的server farm结构，BT是上面的应用之一｝．
BT内部存储数据的格式是google SSTable格式．一个SSTable提供一个从关键字到值的映射，关键字和值都可以是任意字符串．映射是排序的，存储的｛不会因为掉电而丢失｝，不可改写的．可以进行以下操作：查询和一个关键字相关的值；或者根据给出的关键字范围遍历所有的关键字和值．在内部，每个SSTable包含一列数据块（通常每个块的大小是64KB,但是大小是可以配置的｛索引大小是16 bits，应该是比较好的一个数｝）．块索引（存储在SSTable的最后）用来定位数据块；当打开SSTable的时候，索引被读入内存｛性能｝．每次查找都可以用一个硬盘搜索完成｛根据索引算出数据在哪个道上，一个块应该不会跨两个道，没必要省那么点空间｝：首先在内存中的索引里进行二分查找找到数据块的位置，然后再从硬盘读去数据块．最佳情况是：整个SSTable可以被放在内存里，这样一来就不必访问硬盘了．｛想的美，前面是谁口口声声说要跟别人共享机器来着？你把内存占满了别人上哪睡去？｝
BT还依赖一个高度可用的，存储的分布式数据锁服务Chubby[8]｛看你怎么把这个high performance给说圆喽｝．一个Chubby服务由5个活的备份｛机器｝构成，其中一个被这些备份选成主备份，并且处理请求．这个服务只有在大多数备份都活着并且互相通信的时候才是活的｛绕口令？去看原文吧，是在有出错的前提下的冗余算法｝．当有机器失效的时候，Chubby使用Paxos算法[9,23]来保证备份的一致性｛这个问题还是比较复杂的，建议去看引文了解一下问题本身｝．Chubby提供了一个名字空间，里面包括了目录和小文件｛万变不离其宗｝．每个目录或者文件可以当成一个锁来用，读写文件操作都是原子化的．Chubby客户端的程序库提供了对Chubby文件的一致性缓存｛究竟是提高性能还是降低性能？如果访问是分布的，就是提高性能｝．每个Chubby客户维护一个和Chubby服务的会话．如果一个客户不能在一定时间内更新它的会话，这个会话就过期失效了｛还是针对大server farm里机器失效的频率设计的｝．当一个会话失效时，其拥有的锁和打开的文件句柄都失效｛根本设计原则：失效时回到安全状态｝．Chubby客户可以在文件和目录上登记回调函数，以获得改变或者会话过期的通知．｛翻到这里，有没有人闻到java的味道了？｝
BT使用Chubby来做以下几个任务：保证任何时间最多只有一个活跃的主备份；来存储BT数据的启动位置（参考5.1节）；发现小表 （tablet）服务器，并完成tablet服务器消亡的善后（5.2节）；存储BT数据的模式信息（每张表的列信息）；以及存储访问权限列表．如果有相当长的时间Chubby不能访问，BT就也不能访问了｛任何系统都有其弱点｝．最近我们在使用11个Chubby服务实例的14个BT集群中度量了这个效果，由于Chubby不能访问而导致BT中部分数据不能访问的平均百分比是0.0047%,这里Chubby不能访问的原因是Chubby本身失效或者网络问题．单个集群里，受影响最大的百分比是0.0326%｛基于文件系统的Chubby还是很稳定的｝.
GFS是一个可扩展的分布式文件系统，用于大型的、分布式的、对大量数据进行访问的应用。它运行于廉价的普通硬件上，但可以提供容错功能。它可以给大量的用户提供总体性能较高的服务。
出处：http://labs.google.com/papers/gfs.html
1、设计概览
（1）设计想定
GFS与过去的分布式文件系统有很多相同的目标，但GFS的设计受到了当前及预期的应用方面的工作量及技术环境的驱动，这反映了它与早期的文件系统明显不同的设想。这就需要对传统的选择进行重新检验并进行完全不同的设计观点的探索。
GFS与以往的文件系统的不同的观点如下：
1、部件错误不再被当作异常，而是将其作为常见的情况加以处理。因为文件系统由成百上千个用于存储的机器构成，而这 些机器是由廉价的普通部件组成并被大量的客户机访问。部件的数量和质量使得一些机器随时都有可能无法工作并且有一部分还可能无法恢复。所以实时地监控、错 误检测、容错、自动恢复对系统来说必不可少。
2、按照传统的标准，文件都非常大。长度达几个GB的文件是很平常的。每个文件通常包含很多应用对象。当经常要处理 快速增长的、包含数以万计的对象、长度达TB的数据集时，我们很难管理成千上万的KB规模的文件块，即使底层文件系统提供支持。因此，设计中操作的参数、 块的大小必须要重新考虑。对大型的文件的管理一定要能做到高效，对小型的文件也必须支持，但不必优化。
3、大部分文件的更新是通过添加 新数据完成的，而不是改变已存在的数据。在一个文件中随机的操作在实践中几乎不存在。一旦写完，文件就只可读，很多数据都有这些特性。一些数据可能组成一 个大仓库以供数据分析程序扫描。有些是运行中的程序连续产生的数据流。有些是档案性质的数据，有些是在某个机器上产生、在另外一个机器上处理的中间数据。 由于这些对大型文件的访问方式，添加操作成为性能优化和原子性保证的焦点。而在客户机中缓存数据块则失去了吸引力。
4、工作量主要由两种读操作构成：对大量数据的流方式的读操作和对少量数据的随机方式的读操作。在前一种读操作中， 可能要读几百KB，通常达 1MB和更多。来自同一个客户的连续操作通常会读文件的一个连续的区域。随机的读操作通常在一个随机的偏移处读几个KB。性能敏感的应用程序通常将对少量 数据的读操作进行分类并进行批处理以使得读操作稳定地向前推进，而不要让它来来回回的读。
5、工作量还包含许多对大量数据进行的、连续的、向文件添加数据的写操作。所写的数据的规模和读相似。一旦写完，文件很少改动。在随机位置对少量数据的写操作也支持，但不必非常高效。
6、系统必须高效地实现定义完好的大量客户同时向同一个文件的添加操作的语义。
（2）系统接口
GFS提供了一个相似地文件系统界面，虽然它没有向POSIX那样实现标准的API。文件在目录中按层次组织起来并由路径名标识。
（3）体系结构：
一个GFS集群由一个master和大量的chunkserver构成，并被许多客户（Client）访问。如图1 所示。Master和 chunkserver通常是运行用户层服务进程的Linux机器。只要资源和可靠性允许，chunkserver和client可以运行在同一个机器 上。
文件被分成固定大小的块。每个块由一个不变的、全局唯一的64位的chunk－handle标识，chunk－ handle是在块创建时由 master分配的。ChunkServer将块当作Linux文件存储在本地磁盘并可以读和写由chunk－handle和位区间指定的数据。出于可靠 性考虑，每一个块被复制到多个chunkserver上。默认情况下，保存3个副本，但这可以由用户指定。
Master维护文件系统所以的元数据（metadata），包括名字空间、访问控制信息、从文件到块的映射以及块 的当前位置。它也控制系统范围的活动，如块租约（lease）管理，孤儿块的垃圾收集，chunkserver间的块迁移。Master定期通过 HeartBeat消息与每一个 chunkserver通信，给chunkserver传递指令并收集它的状态。
与每个应用相联的GFS客户代码实现了文件系统的API并与master和chunkserver通信以代表应用程序读和写数据。客户与master的交换只限于对元数据（metadata）的操作，所有数据方面的通信都直接和chunkserver联系。
客户和chunkserver都不缓存文件数据。因为用户缓存的益处微乎其微，这是由于数据太多或工作集太大而无法 缓存。不缓存数据简化了客户程序和整个系统，因为不必考虑缓存的一致性问题。但用户缓存元数据（metadata）。Chunkserver也不必缓存文 件，因为块时作为本地文件存储的。
（4）单master。
只有一个master也极大的简化了设计并使得master可以根据全局情况作出先进的块放置和复制决定。但是我们 必须要将master对读和写的参与减至最少，这样它才不会成为系统的瓶颈。Client从来不会从master读和写文件数据。Client只是询问 master它应该和哪个 chunkserver联系。Client在一段限定的时间内将这些信息缓存，在后续的操作中Client直接和chunkserver交互。
以图1解释一下一个简单的读操作的交互。
1、client使用固定的块大小将应用程序指定的文件名和字节偏移转换成文件的一个块索引（chunk index）。
2、给master发送一个包含文件名和块索引的请求。
3、master回应对应的chunk handle和副本的位置（多个副本）。
4、client以文件名和块索引为键缓存这些信息。（handle和副本的位置）。
5、Client 向其中一个副本发送一个请求，很可能是最近的一个副本。请求指定了chunk handle（chunkserver以chunk handle标识chunk）和块内的一个字节区间。
6、除非缓存的信息不再有效（cache for a limited time）或文件被重新打开，否则以后对同一个块的读操作不再需要client和master间的交互。
通常Client可以在一个请求中询问多个chunk的地址，而master也可以很快回应这些请求。
（5）块规模：
块规模是设计中的一个关键参数。我们选择的是64MB，这比一般的文件系统的块规模要大的多。每个块的副本作为一个普通的Linux文件存储，在需要的时候可以扩展。
块规模较大的好处有：
1、减少client和master之间的交互。因为读写同一个块只是要在开始时向master请求块位置信息。对于读写大型文件这种减少尤为重要。即使对于访问少量数据的随机读操作也可以很方便的为一个规模达几个TB的工作集缓缓存块位置信息。
2、Client在一个给定的块上很可能执行多个操作，和一个chunkserver保持较长时间的TCP连接可以减少网络负载。
3、这减少了master上保存的元数据（metadata）的规模，从而使得可以将metadata放在内存中。这又会带来一些别的好处。
不利的一面：
一个小文件可能只包含一个块，如果很多Client访问改文件的话，存储这些块的chunkserver将成为访问的热点。但在实际应用中，应用程序通常顺序地读包含多个块的文件，所以这不是一个主要问题。
（6）元数据（metadata）：
master存储了三中类型的metadata：文件的名字空间和块的名字空间，从文件到块的映射，块的副本的位 置。所有的metadata都放在内存中。前两种类型的metadata通过向操作日志登记修改而保持不变，操作日志存储在master的本地磁盘并在几 个远程机器上留有副本。使用日志使得我们可以很简单地、可靠地更新master的状态，即使在master崩溃的情况下也不会有不一致的问题。相反， mater在每次启动以及当有 chuankserver加入的时候询问每个chunkserver的所拥有的块的情况。
A、内存数据结构：
因为metadata存储在内存中，所以master的操作很快。进一步，master可以轻易而且高效地定期在后台扫描它的整个状态。这种定期地扫描被用于实现块垃圾收集、chunkserver出现故障时的副本复制、为平衡负载和磁盘空间而进行的块迁移。
这种方法的一个潜在的问题就是块的数量也即整个系统的容量是否受限与master的内存。实际上，这并不是一个严重 的问题。Master为每个 64MB的块维护的metadata不足64个字节。除了最后一块，文件所有的块都是满的。类似的，每个文件的名字空间数据也不足64个字节，因为文件名 是以一种事先确定的压缩方式存储的.如果要支持更大的文件系统，那么增加一些内存的方法对于我们将元数据（metadata）保存在内存种所获得的简单 性、可靠性、高性能和灵活性来说，这只是一个很小的代价。
B、块位置：
master并不为chunkserver所拥有的块的副本的保存一个不变的记录。它在启动时通过简单的查询来获得这些信息。Master可以保持这些信息的更新，因为它控制所有块的放置并通过HeartBeat消息来监控chunkserver的状态。
这样做的好处：因为chunkserver可能加入或离开集群、改变路径名、崩溃、重启等，一个集群重有成百个server，这些事件经常发生，这种方法就排除了master与chunkserver之间的同步问题。
另一个原因是：只有chunkserver才能确定它自己到底有哪些块，由于错误，chunkserver中的一些块可能会很自然的消失，这样在master中就没有必要为此保存一个不变的记录。
C、操作日志：
操作日志包含了对metadata所作的修改的历史记录。它作为逻辑时间线定义了并发操作的执行顺序。文件、块以及它们的版本号都由它们被创建时的逻辑时间而唯一地、永久地被标识。
操作日志是如此的重要，我们必须要将它可靠地保存起来，并且只有在metadata的改变固定下来之后才将变化呈现给用户。所以我们将操作日志复制到数个远程的机器上，并且只有在将相应的日志记录写到本地和远程的磁盘上之后才回答用户的请求。
Master可以用操作日志来恢复它的文件系统的状态。为了将启动时间减至最小，日志就必须要比较小。每当日志的长度增长到超过一定的规模后，master就要检查它的状态，它可以从本地磁盘装入最近的检查点来恢复状态。
创建一个检查点比较费时，master的内部状态是以一种在创建一个检查点时并不耽误即将到来的修改操作的方式来组 织的。Master切换到一个新的日子文件并在一个单独的线程中创建检查点。这个新的检查点记录了切换前所有的修改。在一个有数十万文件的集群中用一分钟 左右就能完成。创建完后，将它写入本地和远程的磁盘。
（7）数据完整性
名字空间的修改必须是原子性的，它们只能有master处理：名字空间锁保证了操作的原子性和正确性，而master的操作日志在全局范围内定义了这些操作的顺序。
文 件区间的状态在修改之后依赖于修改的类型，不论操作成功还是失败，也不论是不是并发操作。如果不论从哪个副本上读，所有的客户都看到同样的数据，那么文件 的这个区域就是一致的。如果文件的区域是一致的并且用户可以看到修改操作所写的数据，那么它就是已定义的。如果修改是在没有并发写操作的影响下完成的，那 么受影响的区域是已定义的，所有的client都能看到写的内容。成功的并发写操作是未定义但却是一致的。失败的修改将使区间处于不一致的状态。
Write操作在应用程序指定的偏移处写入数据，而record append操作使得数据（记录）即使在有并发修改操作的情况下也至少原子性的被加到GFS指定的偏移处，偏移地址被返回给用户。
在一系列成功的修改操作后，最后的修改操作保证文件区域是已定义的。GFS通过对所有的副本执行同样顺序的修改操作并且使用块版本号检测过时的副本（由于chunkserver退出而导致丢失修改）来做到这一点。
因为用户缓存了会位置信息，所以在更新缓存之前有可能从一个过时的副本中读取数据。但这有缓存的截止时间和文件的重新打开而受到限制。
在修改操作成功后，部件故障仍可以是数据受到破坏。GFS通过master和chunkserver间定期的handshake，借助校验和来检测对数据的破坏。一旦检测到，就从一个有效的副本尽快重新存储。只有在GFS检测前，所有的副本都失效，这个块才会丢失。
2、系统交互
（1）租约（lease）和修改顺序
（2）数据流
我们的目标是充分利用每个机器的网络带宽，避免网络瓶颈和延迟
为了有效的利用网络，我们将数据流和控制流分离。数据是以流水线的方式在选定的chunkerserver链上线性的传递的。每个机器的整个对外带宽都被用作传递数据。为避免瓶颈，每个机器在收到数据后，将它收到数据尽快传递给离它最近的机器。
（3）原子性的record Append：
GFS提供了一个原子性的添加操作：record append。在传统的写操作中，client指定被写数据的偏移位置，向同一个区间的并发的写操作是不连续的：区间有可能包含来自多个client的数 据碎片。在record append中， client只是指定数据。GFS在其选定的偏移出将数据至少原子性的加入文件一次，并将偏移返回给client。
在分布式的应用中，不同机器上的许多client可能会同时向一个文件执行添加操作，添加操作被频繁使用。如果用传 统的write操作，可能需要额外的、复杂的、开销较大的同步，例如通过分布式锁管理。在我们的工作量中，这些文件通常以多个生产者单个消费者队列的方式 或包含从多个不同 client的综合结果。
Record append和前面讲的write操作的控制流差不多，只是在primary上多了一些逻辑判断。首先，client将数据发送到文件最后一块的所有副本 上。然后向primary发送请求。Primary检查添加操作是否会导致该块超过最大的规模（64M）。如果这样，它将该块扩充到最大规模，并告诉其它 副本做同样的事，同时通知client该操作需要在下一个块上重新尝试。如果记录满足最大规模的要求，primary就会将数据添加到它的副本上，并告诉 其它的副本在在同样的偏移处写数据，最后primary向client报告写操作成功。如果在任何一个副本上record append操作失败，client将重新尝试该操作。这时候，同一个块的副本可能包含不同的数据，因为有的可能复制了全部的数据，有的可能只复制了部 分。GFS不能保证所有的副本每个字节都是一样的。它只保证每个数据作为一个原子单元被写过至少一次。这个是这样得出的：操作要是成功，数据必须在所有的 副本上的同样的偏移处被写过。进一步，从这以后，所有的副本至少和记录一样长，所以后续的记录将被指定到更高的偏移处或者一个不同的块上，即使另一个副本 成了primary。根据一致性保证，成功的record append操作的区间是已定义的。而受到干扰的区间是不一致的。
（4）快照（snapshot）
快照操作几乎在瞬间构造一个文件和目录树的副本，同时将正在进行的其他修改操作对它的影响减至最小。
我们使用copy-on-write技术来实现snapshot。当master受到一个snapshot请求时， 它首先将要snapshot的文件上块上的lease。这使得任何一个向这些块写数据的操作都必须和master交互以找到拥有lease的副本。这就给 master一个创建这个块的副本的机会。
副本被撤销或终止后，master在磁盘上登记执行的操作，然后复制源文件或目录树的metadata以对它的内存状态实施登记的操作。这个新创建的snapshot文件和源文件（其metadata）指向相同的块（chunk）。
Snapshot之后，客户第一次向chunk c写的时候，它发一个请求给master以找到拥有lease的副本。Master注意到chunk c的引用记数比1大，它延迟对用户的响应，选择一个chunk handle C’,然后要求每一有chunk c的副本的chunkserver创建一个块C’。每个chunkserver在本地创建chunk C’避免了网络开销。从这以后和对别的块的操作没有什么区别。
3、MASTER操作
MASTER执行所有名字空间的操作，除此之外，他还在系统范围管理数据块的复制：决定数据块的放置方案，产生新数据块并将其备份，和其他系统范围的操作协同来确保数据备份的完整性，在所有的数据块服务器之间平衡负载并收回没有使用的存储空间。
3.1 名字空间管理和加锁
与传统文件系统不同的是，GFS没有与每个目录相关的能列出其所有文件的数据结构，它也不支持别名（unix中的硬连接或符号连接），不管是对文件或是目录。GFS的名字空间逻辑上是从文件元数据到路径名映射的一个查用表。
MASTER在执行某个操作前都要获得一系列锁，例如，它要对/d1/d2…/dn/leaf执行操作，则它必须获 得/d1，/d1/d2，…， /d1/d2/…/dn的读锁，/d1/d2…/dn/leaf的读锁或写锁（其中leaf可以使文件也可以是目录）。MASTER操作的并行性和数据的 一致性就是通过这些锁来实现的。
3.2 备份存储放置策略
一个GFS集群文件系统可能是多层分布的。一般情况下是成千上万个文件块服务器分布于不同的机架上，而这些文件块服 务器又被分布于不同机架上的客户来访问。因此，不同机架上的两台机器之间的通信可能通过一个或多个交换机。数据块冗余配置策略要达到连个目的：最大的数据 可靠性和可用性，最大的网络带宽利用率。因此，如果仅仅把数据的拷贝置于不同的机器上很难满足这两个要求，必须在不同的机架上进行数据备份。这样即使整个 机架被毁或是掉线，也能确保数据的正常使用。这也使数据传输，尤其是读数据，可以充分利用带宽，访问到多个机架，而写操作，则不得不涉及到更多的机架。
3.3 产生、重复制、重平衡数据块
当MASTER产生新的数据块时，如何放置新数据块，要考虑如下几个因素：（1）尽量放置在磁盘利用率低的数据块服 务器上，这样，慢慢地各服务器的磁盘利用率就会达到平衡。（2）尽量控制在一个服务器上的“新创建”的次数。（3）由于上一小节讨论的原因，我们需要把数 据块放置于不同的机架上。
MASTER在可用的数据块备份低于用户设定的数目时需要进行重复制。这种情况源于多种原因：服务器不可用，数据被 破坏，磁盘被破坏，或者备份数目被修改。每个被需要重复制的数据块的优先级根据以下几项确定：第一是现在的数目距目标的距离，对于能阻塞用户程序的数据 块，我们也提高它的优先级。最后， MASTER按照产生数据块的原则复制数据块，并把它们放到不同的机架内的服务器上。
MASTER周期性的平衡各服务器上的负载：它检查chunk分布和负载平衡，通过这种方式来填充一个新的服务器而 不是把其他的内容统统放置到它上面带来大量的写数据。数据块放置的原则与上面讨论的相同，此外，MASTER还决定那些数据块要被移除，原则上他会清除那 些空闲空间低于平均值的那些服务器。
3.4 垃圾收集
在一个文件被删除之后，GFS并不立即收回磁盘空间，而是等到垃圾收集程序在文件和数据块级的的检查中收回。
当一个文件被应用程序删除之后，MASTER会立即记录下这些变化，但文件所占用的资源却不会被立即收回，而是重新 给文件命了一个隐藏的名字，并附上了删除的时间戳。在MASTER定期检查名字空间时，它删除超过三天（可以设定）的隐藏的文件。在此之前，可以以一个新 的名字来读文件，还可以以前的名字恢复。当隐藏的文件在名字空间中被删除以后，它在内存中的元数据即被擦除，这就有效地切断了他和所有数据块的联系。
在一个相似的定期的名字空间检查中，MASTER确认孤儿数据块（不属于任何文件）并擦除他的元数据，在和MASTER的心跳信息交换中，每个服务器报告他所拥有的数据块，MASTER返回元数据不在内存的数据块，服务器即可以删除这些数据块。
3.5 过时数据的探测
在数据更新时如果服务器停机了，那么他所保存的数据备份就会过时。对每个数据块，MASTER设置了一个版本号来区别更新过的数据块和过时的数据块。
当MASTER授权一个新的lease时，他会增加数据块的版本号并会通知更新数据备份。MASTER和备份都会记 录下当前的版本号，如果一个备份当时不可用，那么他的版本号不可能提高，当ChunkServer重新启动并向MASTER报告他的数据块集时， MASTER就会发现过时的数据。
MASTER在定期的垃圾收集程序中清除过时的备份，在此以前，处于效率考虑，在各客户及英大使，他会认为根本不存 在过时的数据。作为另一个安全措施， MASTER在给客户及关于数据块的应答或是另外一个读取数据的服务器数据是都会带上版本信息，在操作前客户机和服务器会验证版本信息以确保得到的是最新 的数据。
4、容错和诊断
4.1 高可靠性
4.1.1 快速恢复
不管如何终止服务，MASTER和数据块服务器都会在几秒钟内恢复状态和运行。实际上，我们不对正常终止和不正常终止进行区分，服务器进程都会被切断而终止。客户机和其他的服务器会经历一个小小的中断，然后它们的特定请求超时，重新连接重启的服务器，重新请求。
4.1.2 数据块备份
如上文所讨论的，每个数据块都会被备份到放到不同机架上的不同服务器上。对不同的名字空间，用户可以设置不同的备份级别。在数据块服务器掉线或是数据被破坏时，MASTER会按照需要来复制数据块。
4.1.3 MASTER备份
为确保可靠性，MASTER的状态、操作记录和检查点都在多台机器上进行了备份。一个操作只有在数据块服务器硬盘上 刷新并被记录在MASTER和其备份的上之后才算是成功的。如果MASTER或是硬盘失败，系统监视器会发现并通过改变域名启动它的一个备份机，而客户机 则仅仅是使用规范的名称来访问，并不会发现MASTER的改变。
4.2 数据完整性
每个数据块服务器都利用校验和来检验存储数据的完整性。原因：每个服务器随时都有发生崩溃的可能性，并且在两个服务器间比较数据块也是不现实的，同时，在两台服务器间拷贝数据并不能保证数据的一致性。
每个Chunk按64kB的大小分成块，每个块有32位的校验和，校验和和日志存储在一起，和用户数据分开。
在读数据时，服务器首先检查与被读内容相关部分的校验和，因此，服务器不会传播错误的数据。如果所检查的内容和校验 和不符，服务器就会给数据请求者返回一个错误的信息，并把这个情况报告给MASTER。客户机就会读其他的服务器来获取数据，而MASTER则会从其他的 拷贝来复制数据，等到一个新的拷贝完成时，MASTER就会通知报告错误的服务器删除出错的数据块。
附加写数据时的校验和计算优化了，因为这是主要的写操作。我们只是更新增加部分的校验和，即使末尾部分的校验和数据已被损坏而我们没有检查出来，新的校验和与数据会不相符，这种冲突在下次使用时将会被检查出来。
相反，如果是覆盖现有数据的写，在写以前，我们必须检查第一和最后一个数据块，然后才能执行写操作，最后计算和记录校验和。如果我们在覆盖以前不先检查首位数据块，计算出的校验和则会因为没被覆盖的数据而产生错误。
在空闲时间，服务器会检查不活跃的数据块的校验和，这样可以检查出不经常读的数据的错误。一旦错误被检查出来，服务器会拷贝一个正确的数据块来代替错误的。
4.3 诊断工具
广泛而细致的诊断日志以微小的代价换取了在问题隔离、诊断、性能分析方面起到了重大的作用。GFS服务器用日志来记 录显著的事件（例如服务器停机和启动）和远程的应答。远程日志记录机器之间的请求和应答，通过收集不同机器上的日志记录，并对它们进行分析恢复，我们可以 完整地重现活动的场景，并用此来进行错误分析。
5 测量
5.1 测试环境
一台主控机，两台主控机备份，16台数据块服务器，16台客户机。
每台机器：2块PIII1.4G处理器，2G内存，2块80G5400rpm的硬盘，1块100Mbps全双工网卡
19台服务器连接到一个HP2524交换机上，16台客户机俩接到领外一台交换机上，两台交换机通过1G的链路相连。

原文转自：http://bigweb.group.javaeye.com/group/topic/5749

相关文章

• [转]C/C++/Perl/汇编/Java效率比较 (0)
• ACE自适配通信环境 (0)
• 大型高并发高负载网站的系统架构 (0)
• flickr对javascript干的好事 (0)
• 应用加速 (0)

相关文章

• 清除指定squid缓存文件的脚本 (0)
• 应用加速 (0)
• 大型高并发高负载网站的系统架构 (0)
• 使用memcached进行内存缓存 (0)
• [转]内存种类知多少 (1)

AT必须同为大写或小写。如”At”或”aT”是不允许的。

    一串命令可以写在一行里。为了便于阅读可以加或不加空格。命令中或命令间的空格会被忽略，命令行的最多字符数为39(包括”AT”)。在输入一条命令期间，可以用退格键(backspace)改正除”AT”以外的错误。若命令行中任一处出现语法错误，本行其后的内容将被忽略，并返回ERROR。大数带有超出正常范围的参数的命令将不被接收并返回 ERROR.本章列出所有设置调制解调器的命令。包括控制ACTIVE调制解调器的贺氏标准AT命令集。贺氏V系列命令集和扩展命令集

AT命令集的描述

      符号 * 表明该命令的设置可用AT&Wn命令存于两个用户方案中的一个

A/        重执行命令

重执行前一AT命令行，主要用于连接时占线，无应答或号码错误。这一命令必须单独构成一命令行并由”/”字符结束,(<Enter> 不能用于结束命令)。

+++       退出字符 缺省:+

切换调制解调器从在线状态到命令状态，而不会中断数据连接。可以通过改变S寄存器S2的值来改变这一字符。

AT=x      写入被选的S寄存器

这一命令将数值x写入当前被选的S寄存器，一个S寄存器可由ATSn命令选择，若 x 是一个数字,所有S 寄存器将返回 OK 响应。

AT?       读被选的S寄存器

  这一命令读并且显示被选的S寄存器的内容。一个S寄存器可由ATSn命令选择。

ATA       应答

它必须是命令行中的最后一条指令。调制解调器在应答方式下继续执行连接程序。在与远端调制解调器交换载波后进入连接状态,如果在由寄存器S7规定的时间内(缺省值=50秒)没有检测到载波, 调制解调器将挂机。在连接过程中，通过DTE输入的任何一个字母都将中断这一命令。

ATBn*     选择ITU-T或Bell模式 缺省=0

 ATB0 选择在1200和300bps速率下通讯的ITU-T V.22和V.21协议
 ATB1 选择在1200和300bps速率下通讯的Bell 212A和103协议

ATCn      载波控制缺省=1

包含这一命令只是为了保证兼容性，执行号只是返回一结果码而没有其它作用。
ATC1 正常传输载波切换

ATDn      拨号

它必须是命令行中的最后一条指令, ATD命令使调制解调器摘机后, 根据输入的参数拨号,以建立连接。如果不带参数，调制解调器摘机后，不拨号进入发起方式。

使用标点可使命令更易读懂。圆括号,连字符和空格符会被忽略。拔号命令行中如果出现了非法字符，则该字符及其后的内容将被忽略。调制解调器允许的拨号命令长度为36个字符。

参数：0-9 A B C D * # L P T R ! @ W , ; ^ S=n
0-9     DTMF 符号0到9
A-D     DTMF 符号A,B,C和D。在一些国家中不使用这些符号
*       “星”号(仅用于音频拨号)
#       “#”号(仅用于音频拨号)
J       为本次呼叫执行在可提供的最高速率下的MNP10链路协商(可选)
K       使本次呼叫MNP10链路协商期间电源电平可调(可选)
L       重拨上一次拨过的号码
P       脉冲拨号
T       双音频拨号
R       逆叫方式。允许调制解调器使用应答方式呼叫只能作为发起使用的调制解调        器, 必须作为命令行中的最后一个字符输入。
!       使调制解调器按照S29中规定的值挂机一段时间再摘机。
@       使调制解调器等待5秒钟的无声回答
w       按照寄存器S7中规定的时间，在拨号前等待拨号音。
,       在拨号过程中，按照寄存器S8中规定的时间,暂停
;       拨号后返回命令状态
^       打开呼叫音
()      被忽视，用于格式化号码串
-       被忽视，用于格式化号码串
<space> 被忽视,用于格式化号码串
S=n     用AT&Zn 命令存在地址n处的号码拨号

ATE*     命令回应           缺省:1

ATE0 关闭命令回应
ATE1 打开 命令回应

ATHn     摘挂机控制       缺省:0

ATH0 使调制解调器挂机
ATH1 当调制解调器处于挂机状态，使调制解调器摘机，返回响 OK，等待进一步的命令。

ATIn     识别

I0 报告产品代码
I1 报告ROM中预先计算的校验和
I2 计算校验和并与ROM中的校验和比较,返回”OK”或”ERROR”结果码
I3 报告固件修正
I4 报告OEM定义的识别串
I5 报告国家代码参数
I6 报告固件修正
I7 报告调制解调器数据泵类型

ATLn*    扬声器音量       缺省:2

ATL0 扬声器低音量
ATL1 扬声器低音量
ATL2 扬声器中音量
ATL3 扬声器高音量

ATMn*    扬声器控制       缺省:1

ATM0 关闭扬声器
ATM1 扬声器在呼叫建立握手阶段打开至检测到来自于远端调制解调器的载波后关闭
ATM2 扬声器持续开
ATM3 扬声器在应答期间打开。当检测到来自于远端的调制解调器的载波和拨号时关闭

ATNn*     调制握手       缺省:1

 ATN0 要求调制解调器S37选择连接速率,若S37＝0,则连接速率必须与发出的上一条AT命令的速率相匹配。如果所选择的速率可用不止一个通讯标准实现(如Bell212A或ITU-T V.22 速率在 1200bps)调制解调器同时参考ATB 命令选择。ATN1 允许时使用双方调制解调器都支持的任一速率握手，使能够自动检测。在这一方式下，ATB命令被忽视，调制解调器只用ITU-T方式连接。

ATOn     进入数据在现状态 缺省:0

ATO0 使调制解调器从命令在现状态直接返回数据在线状态,不经过自动均衡。
ATO1 使调制解调器从命令在现状态返回数据在状态,经过自动均衡。

ATP*     设脉冲拨号为缺省
 

ATQn*    结果码显示        缺省:0

ATQ0 调制解调器向DTE发送结果码
ATQ1 禁止调制解调器向DTE发送结果码

点击查看S寄存器详解！

ATSn     设S寄存器n为缺省寄存器
 ATSn?    读S寄存器

读S寄存器中的内容，所有的S寄存器都可以读

ATSn=x   写入S寄存器

将 x值写入指定的S寄存器n

ATT*     设音频拔号为缺省
 

ATVn*    结束码类型 (消息控制)        缺省:1

ATV0 发送短型 (数字型) 结果码
ATV1 发送长型 (字符型) 结果码

ATWn*    协商进程报告                缺省:0

ATW0 不报告纠错呼叫进程
ATW1 报告纠错呼叫进程
ATW2 不报告纠错呼叫进程，CONNECT xxxx指示DCE速率。

ATXn*     扩展结果码            缺省:4

ATX0 调制解调器忽视拨号音和忙音。当由盲拨建立连接时，发送CONNECT信息。ATX1 调制解调器忽视拨号音和忙音。当由盲拨建立连接时，CONNECT XXXX 反映的是比特速率

ATX2 调制解调器忽视忙音，但在拨号前等待拨号音，如果5秒钟内检测不到拨号音，则发送NO DIAL TONE 信息，连接建立后 发送 CONNECT xxxx反映比特速率。

ATX3 调制解调器忽视拨号音,若检测到忙音,发送BUSY信息,当由盲拨建立起连接时, CONNECT XXXX 反映的是比特速率。

ATX4 如果5秒钟内检测不到拨号音，发送NO DIAL TONE 讯息,检测到忙音, 发送BUSY信息。连接建立后发送CONNECT XXXX 反映比特速率。

ATYn*     控制长间隔拆接         缺省:0

ATY0 不允许长间隔拆接
ATY1 允许长间隔拆接

ATZn      复位                缺省:0

重新调出由用户方案规定的动态配置
ATZ0 软复位并重新调出用户方案0
ATZ1 软复位并重新调出用户方案1

AT&An*    握手异常终止(备选)    缺省:1

 AT&A0 在握手时禁止用户进行异常终止。当拨号或应答时，握手不能异常终止,只有DTR 信号下降。AT&A1 用户可以在握手时进行异常终止.在接收到DTE的字符后,发起和应答可以在握手期间随时进行异常终止.

AT&Cn*     RS232-C DCD          设置缺省:1

AT&C0 DCD为ON，不论来自远端的调制解调器的数据载波的状态为何。
AT&C1 DCD 跟随来自于远端调制解调器的数据载波的状态

AT&Dn*    RS232-C DTR          设置缺省:2

决定了调制解调器与来自串口的DTR信号相关的操作。由于跟踪DTR的下降引起的操作在下表列出:

AT&Fn     重新调用工厂            设置缺省:0

AT&Gn*    设置保护音            缺省:0

AT&Jn*    电话插头选择          缺省:0
 

包含这一命令只是基于兼容性的考虑，没有任何功能
AT&J0 不操作任何功能
AT&J1 不操作任何功能

AT&Kn*    DTE/调制解调器流    控制缺省:3

AT&Ln*    传输线类型            缺省:0

AT&Mn*    通讯方式

AT&Pn*    拨号脉冲占空比        缺省:0

AT&Qn*    通讯方式             缺省:5

AT&Rn*    RS232-C RTS/CTS   设置缺省:0

AT&R0 CTS跟踪RTS, 本地DTE发送的RTS由OFF变为ON经过由寄存器S26所规定的以10微秒为增量的延迟后,CTS变为ONAT&R1 调制解调器忽视RTS,除非使用了AT&K3命令,CTS保持为ON

AT&Sn*    RS232-C DSR       设置缺省:0

AT&Tn*    测试和诊断            缺省:4

AT&V     看当今配置及用户参数

AT&V0 查看当前配置、用户方案和存储的电话号码
AT&V1 显示最后一次数据连接的详细情况

AT&Wn    储存用户参数              缺省：0

AT&Xn*    选择同步时钟源             缺省：0

AT&Yn*    指示缺省用户参数            缺省：0

在硬复位后可选择将使用的用户方案。
AT&Y0 选择用户方案0
AT&Y1 选择用户方案1

AT&Zn=x   储存电话号码(n=0-3)         缺省：0

将一36位数字电话号码(x)存放在一指定电话号码表中(n), 作以后拨号用(参见命令ATDS=n)

AT\Bn     发送中断信号(n=1-9)        缺省:3

当在非MNP连接期间输入此命令,调制解调器向远端调制解器发送一中断信号,中断信号长度参数为n值的100倍（以毫秒            为单位）,在MNP模式下,输入此命令,调制解调器向远端调制解调器发送一链路注意码PDU

AT\Gn     调制解调器到调制解调器的流控制    缺省:0

AT\Jn     DTE速率自动调整控制            缺省:0

AT\Kn     中断控制                     缺省:5

AT\Ln     MNP块传输控制                 缺省:0

AT\Nn     操作模式控制                 缺省:3

AT\N0 选择标准速度缓存模式(无纠错)
AT\N1 选择直接模式(等效于&M0,&Q0)
AT\N2 选择可靠模式,可靠连接失败会使调制解调器挂机
AT\N3 选择自动可靠模式
AT\N4 选择LAPM纠错模式,LAPM纠错连接失败会使调制解调器挂机
AT\N5 选择MNP纠错模式,MNP纠错连接失败会使调制解调器挂机

AT\Vn     单线连接信息                 缺省：0

AT％C*    压缩控制                    缺省: 3

AT％En    开/关自动均衡                缺省：2
 

控制是使调制解调器自动监听线路质量并请求均衡(％E1)还是当线路质量不好时降速，线路质量好时升速。

AT％L     报告接收灵敏度

返回接收信号的电平值,提供以下数值

AT%On     选择应答或呼叫模式             缺省：1

AT%Rn     选择接收灵敏度 (适用於专线型号) 缺省：0

AT％Q     显示线路信号质量

AT#CIDn   呼叫者身份鉴定                 缺省：0

AT#CID=0关闭呼叫者身份鉴定
AT#CID=1打开DTE格式化形式的呼叫者身份鉴定
AT#CID=2打开DTE非格式化形式的呼叫者身份鉴定
AT#CID? 从调制解调器中恢复当前呼叫者身份鉴定方式
AT#CID=? 返回调制解调器允许模式的列表,表中各部分间用逗号隔开

AT-SDR=n  鉴别性振铃                    缺省：0

AT-SDR=0 允许任何振铃、并报告”RING”
AT-SDR=1 允许一类型振铃
AT-SDR=2 允许二类型振铃
AT-SDR=3 允许一及二类型振铃
AT-SDR=4 允许三类型振铃
AT-SDR=5 允许一及三类型振铃
AT-SDR=6 允许二及三类型振铃
AT-SDR=7 允许一、二及三类型振铃

AT+MS*     选择线路调制方式

命令格式为（336型号）:
AT+MS=<模式>,<自动模式>,<最小速率>,<最大速率>
缺省值为 AT+MS=11,1,300,33600 （336型号）命令格式为（560型号）:
AT+MS=<模式>,<自动模式>,<最小速率>,<最大速率>,
<x_law>,<rb_signal>,<maxup_rate>
缺省值为 AT+MS=12,1,300,56000,33600 （560型号）

AT+MS?  向包含所选选项的DTE发送一信息流

AT+MS=? 向包含所提供选项的DTE发送一信息流
 
 

<x_law> 是一个可选的数字，用来确定码类型，选择是：

0 = u-Law 1 = A-Law注意：ATZ命令将复位<x_law>值为0 (u-Law)。
 

<rb_signaling> 是一个可选的数字，用于配置一个发送数据的调制解调器产生“丢失位”信号或不产生“丢               失位”信号；或配置一台接收数据的调制解调器检测“丢失位”信号或不检测“丢失位”信               号。选择是：

Maxup_rate : 连接速率的最大值。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1535176

相关文章

• [转]嵌入式系统 Boot Loader 技术内幕 (0)
• PHP5 效率优化 (0)
• 清除指定squid缓存文件的脚本 (0)
• 常用的HR相关英文词汇 (1)
• 什么是bootloader程序及其功能和特点 (0)

    凡是对电脑有所了解的朋友都知道内存这玩意，可是，可能有不少朋友对内存的认识仅仅局限在SDRAM和DDR SDRAM这两种类型，事实上，内存的种类是非常多的，从能否写入的角度来分，就可以分为RAM(随机存取存储器)和ROM(只读存储器)这两大类。每一类别里面有分别有许多种类的内存。以下就让我们看看内存到底有些什么种类吧！

　　一、RAM(Random Access Memory，随机存取存储器)

　　RAM的特点是：电脑开机时，操作系统和应用程序的所有正在运行的数据和程序都会放置其中，并且随时可以对存放在里面的数据进行修改和存取。它的工作需要由持续的电力提供，一旦系统断电，存放在里面的所有数据和程序都会自动清空掉，并且再也无法恢复。

　　根据组成元件的不同，RAM内存又分为以下十八种：

　　01.DRAM（Dynamic RAM，动态随机存取存储器）：

　　这是最普通的RAM，一个电子管与一个电容器组成一个位存储单元，DRAM将每个内存位作为一个电荷保存在位存储单元中，用电容的充放电来做储存动作，但因电容本身有漏电问题，因此必须每几微秒就要刷新一次，否则数据会丢失。存取时间和放电时间一致，约为2~4ms。因为成本比较便宜，通常都用作计算机内的主存储器。

　　02.SRAM（Static RAM，静态随机存取存储器）

　　静态，指的是内存里面的数据可以长驻其中而不需要随时进行存取。每6颗电子管组成一个位存储单元，因为没有电容器，因此无须不断充电即可正常运作，因此它可以比一般的动态随机处理内存处理速度更快更稳定，往往用来做高速缓存。

　　03.VRAM（Video RAM，视频内存）

　　它的主要功能是将显卡的视频数据输出到数模转换器中，有效降低绘图显示芯片的工作负担。它采用双数据口设计，其中一个数据口是并行式的数据输出入口，另一个是串行式的数据输出口。多用于高级显卡中的高档内存。

　　04.FPM DRAM（Fast Page Mode DRAM，快速页切换模式动态随机存取存储器）

　　改良版的DRAM，大多数为72Pin或30Pin的模块。传统的DRAM在存取一个BIT的数据时，必须送出行地址和列地址各一次才能读写数据。而FRM DRAM在触发了行地址后，如果CPU需要的地址在同一行内，则可以连续输出列地址而不必再输出行地址了。由于一般的程序和数据在内存中排列的地址是连续的，这种情况下输出行地址后连续输出列地址就可以得到所需要的数据。FPM将记忆体内部隔成许多页数Pages，从512B到数KB不等，在读取一连续区域内的数据时，就可以通过快速页切换模式来直接读取各page内的资料，从而大大提高读取速度。在96年以前，在486时代和PENTIUM时代的初期，FPM DRAM被大量使用。

　　05.EDO DRAM（Extended Data Out DRAM，延伸数据输出动态随机存取存储器）

　　这是继FPM之后出现的一种存储器，一般为72Pin、168Pin的模块。它不需要像FPM DRAM那样在存取每一BIT 数据时必须输出行地址和列地址并使其稳定一段时间，然后才能读写有效的数据，而下一个BIT的地址必须等待这次读写操作完成才能输出。因此它可以大大缩短等待输出地址的时间，其存取速度一般比FPM模式快15%左右。它一般应用于中档以下的Pentium主板标准内存，后期的486系统开始支持EDO DRAM，到96年后期，EDO DRAM开始执行。。

　　06.BEDO DRAM（Burst Extended Data Out DRAM，爆发式延伸数据输出动态随机存取存储器）

　　这是改良型的EDO DRAM，是由美光公司提出的，它在芯片上增加了一个地址计数器来追踪下一个地址。它是突发式的读取方式，也就是当一个数据地址被送出后，剩下的三个数据每一个都只需要一个周期就能读取，因此一次可以存取多组数据，速度比EDO DRAM快。但支持BEDO DRAM内存的主板可谓少之又少，只有极少几款提供支持（如VIA APOLLO VP2），因此很快就被DRAM取代了。

　　07.MDRAM（Multi-Bank DRAM，多插槽动态随机存取存储器）

　　MoSys公司提出的一种内存规格，其内部分成数个类别不同的小储存库 (BANK)，也即由数个属立的小单位矩阵所构成，每个储存库之间以高于外部的资料速度相互连接，一般应用于高速显示卡或加速卡中，也有少数主机板用于L2高速缓存中。

　　08.WRAM（Window RAM，窗口随机存取存储器）

　　韩国Samsung公司开发的内存模式，是VRAM内存的改良版，不同之处是它的控制线路有一、二十组的输入/输出控制器，并采用EDO的资料存取模式,因此速度相对较快，另外还提供了区块搬移功能（BitBlt），可应用于专业绘图工作上。

　　09.RDRAM（Rambus DRAM，高频动态随机存取存储器）

　　Rambus公司独立设计完成的一种内存模式，速度一般可以达到500~530MB/s，是DRAM的10倍以上。但使用该内存后内存控制器需要作相当大的改变，因此它们一般应用于专业的图形加速适配卡或者电视游戏机的视频内存中。

　　10.SDRAM（Synchronous DRAM，同步动态随机存取存储器）

　　这是一种与CPU实现外频Clock同步的内存模式，一般都采用168Pin的内存模组，工作电压为3.3V。 所谓clock同步是指内存能够与CPU同步存取资料，这样可以取消等待周期，减少数据传输的延迟，因此可提升计算机的性能和效率。

　　11.SGRAM（Synchronous Graphics RAM，同步绘图随机存取存储器）

　　SDRAM的改良版，它以区块Block，即每32bit为基本存取单位，个别地取回或修改存取的资料，减少内存整体读写的次数，另外还针对绘图需要而增加了绘图控制器，并提供区块搬移功能（BitBlt），效率明显高于SDRAM。

　　12.SB SRAM（Synchronous Burst SRAM，同步爆发式静态随机存取存储器）

　　一般的SRAM是非同步的，为了适应CPU越来越快的速度，需要使它的工作时脉变得与系统同步，这就是SB SRAM产生的原因。

　　13.PB SRAM（Pipeline Burst SRAM，管线爆发式静态随机存取存储器）

　　CPU外频速度的迅猛提升对与其相搭配的内存提出了更高的要求，管线爆发式SRAM取代同步爆发式SRAM成为必然的选择，因为它可以有效地延长存取时脉，从而有效提高访问速度。

　　14.DDR SDRAM（Double Data Rate二倍速率同步动态随机存取存储器）

　　作为SDRAM的换代产品，它具有两大特点：其一，速度比SDRAM有一倍的提高；其二，采用了DLL（Delay Locked Loop：延时锁定回路）提供一个数据滤波信号。这是目前内存市场上的主流模式。

　　15.SLDRAM （Synchronize Link，同步链环动态随机存取存储器）

　　这是一种扩展型SDRAM结构内存，在增加了更先进同步电路的同时，还改进了逻辑控制电路，不过由于技术显示，投入实用的难度不小。

　　16.CDRAM（CACHED DRAM，同步缓存动态随机存取存储器）

　　这是三菱电气公司首先研制的专利技术，它是在DRAM芯片的外部插针和内部DRAM之间插入一个SRAM作为二级CACHE使用。当前，几乎所有的CPU都装有一级CACHE来提高效率，随着CPU时钟频率的成倍提高，CACHE不被选中对系统性能产生的影响将会越来越大，而CACHE DRAM所提供的二级CACHE正好用以补充CPU一级CACHE之不足，因此能极大地提高CPU效率。

　　17.DDRII (Double Data Rate Synchronous DRAM，第二代同步双倍速率动态随机存取存储器)

　　DDRII 是DDR原有的SLDRAM联盟于1999年解散后将既有的研发成果与DDR整合之后的未来新标准。DDRII的详细规格目前尚未确定。

　　18.DRDRAM (Direct Rambus DRAM)

　　是下一代的主流内存标准之一，由Rambus 公司所设计发展出来，是将所有的接脚都连结到一个共同的Bus，这样不但可以减少控制器的体积，已可以增加资料传送的效率。

　　二、ROM(READ Only Memory，只读存储器)

　　ROM是线路最简单半导体电路，通过掩模工艺，一次性制造，在元件正常工作的情况下，其中的代码与数据将永久保存，并且不能够进行修改。一般应用于PC系统的程序码、主机板上的 BIOS (基本输入/输出系统Basic Input/Output System)等。它的读取速度比RAM慢很多。

　　根据组成元件的不同，ROM内存又分为以下五种：

　　1.MASK ROM（掩模型只读存储器）

　　制造商为了大量生产ROM内存，需要先制作一颗有原始数据的ROM或EPROM作为样本，然后再大量复制，这一样本就是MASK ROM，而烧录在MASK ROM中的资料永远无法做修改。它的成本比较低。

　　2.PROM（Programmable ROM，可编程只读存储器）

　　这是一种可以用刻录机将资料写入的ROM内存，但只能写入一次，所以也被称为“一次可编程只读存储器”(One Time Progarmming ROM，OTP-ROM)。PROM在出厂时，存储的内容全为1，用户可以根据需要将其中的某些单元写入数据0(部分的PROM在出厂时数据全为0，则用户可以将其中的部分单元写入1)， 以实现对其“编程”的目的。

　　3.EPROM（Erasable Programmable，可擦可编程只读存储器）

　　这是一种具有可擦除功能，擦除后即可进行再编程的ROM内存，写入前必须先把里面的内容用紫外线照射它的IC卡上的透明视窗的方式来清除掉。这一类芯片比较容易识别，其封装中包含有“石英玻璃窗”，一个编程后的EPROM芯片的“石英玻璃窗”一般使用黑色不干胶纸盖住， 以防止遭到阳光直射。

　　4.EEPROM（Electrically Erasable Programmable，电可擦可编程只读存储器）

　　功能与使用方式与EPROM一样，不同之处是清除数据的方式，它是以约20V的电压来进行清除的。另外它还可以用电信号进行数据写入。这类ROM内存多应用于即插即用（PnP）接口中。

　　5.Flash Memory（快闪存储器）

　　这是一种可以直接在主机板上修改内容而不需要将IC拔下的内存，当电源关掉后储存在里面的资料并不会流失掉，在写入资料时必须先将原本的资料清除掉，然后才能再写入新的资料，缺点为写入资料的速度太慢。

相关文章

• google背后的分布式架构 (0)
• 应用加速 (0)
• 大型高并发高负载网站的系统架构 (0)
• [转]嵌入式系统 Boot Loader 技术内幕 (0)
• flickr对javascript干的好事 (0)

    在这篇指南的第一部分，我给了大家一个编写外壳扩展的介绍，并且演示了一个一次操作一个简单文件的上下文菜单扩展。在第二部分中，我将要演示如何在一个操作中操作多个文件。这个扩展是一个注册和卸载COM服务器的实用工具。它还演示了如何使用ATL对话框类CDialogImpl。我将通过解释一些特殊的注册表键来讲第二部分，通过这些键你可以使你的扩展被任何文件调用，而不是那些预先选择的类型(.TXT)。

    第二部分假设你已经阅读了第一部分，所以你知道了上下文菜单扩展的基本知识。除此之外，你还必须理解COM，ATL和STL的基本知识。

上下文菜单扩展的开始-它能做什么？

    这个外壳扩展将使你注册和卸载那些在EXE,DLL和OCX里的COM服务器。不像我们在第一部分所做的那样，这个扩展将对所有你右键点击事件发生时所有选中的文件进行操作。

使用AppWizard 开始

运行AppWizard ，做一个新的ATL COM wizard app。我们叫它DllReg。在向导中保持所有默认选项，单击完成。我们现在就有了一个空的将会生成DLL的ATL项目，但是我们必须添加自己的外壳扩展COM对象。在ClassView树中，右键单击 DllReg classes项，选择New ATL Object。

在ATL Object 向导，第一面板已经选择了Simple Object ，只要单击下一步就行了。在第二面板中，在Short Name 编辑控件中输入DllRegShlExt ，然后单击确定（面板中的其它的编辑框将会自动完成）。这就创建了一个类名为CDllRegShlExt 的类，它包含了实现一个COM对象的基本代码。我们将向这个类添加我们的代码。

初始化接口

    在这个扩展中，我们的IShellExtInit::Initialize()实现将会相当不同。有两个原因，第一我们将列举所有选中的文件；第二，我们将测试我们选中的文件是否有注册(register)和卸载(unregister)函数的出口。我们将仅仅考虑那些同时有DllRegisterServer()和DllUnregisterServer()出口的文件。其他的都将被忽略掉。

    我们将使用列表控件和STL的字符串与列表类，所以你必须首先在stdafx.h 文件中添加如下行：

#include <commctrl.h>#include <string>#include <list>#include <atlwin.h>typedef std::list<std::basic_string<TCHAR> > string_list;

    我们的CDllRegShlExt类也将需要一些成员变量：

protected:    HBITMAP     m_hRegBmp;    HBITMAP     m_hUnregBmp;    string_list m_lsFiles;    TCHAR       m_szDir[MAX_PATH];

    CDllRegShlExt的构造函数中将加载两幅上下文菜单中使用的位图：

CDLLRegShlExt::CDLLRegShlExt(){    m_hRegBmp = LoadBitmap ( _Module.GetModuleInstance(),                             MAKEINTRESOURCE(IDB_REGISTERBMP) );    m_hUnregBmp = LoadBitmap ( _Module.GetModuleInstance(),                               MAKEINTRESOURCE(IDB_UNREGISTERBMP) );}

    在你将IShellExtInit添加到了被CDllRegShlExt实现的接口列表中之后(关于这个操作请参见第一部分)，我们开始写Initialize()函数。

  Initialize()将执行如下步骤：

1. 改变当前目录为在资源浏览器窗口中正在被查看的目录；
2. 列举所有被选中的文件；
3. 对每一个文件，试图使用LoadLibrary()加载它；
4. 如果LoadLibrary()成功，看该文件是否有DllRegisterServer()和DllUnregisterServer()的函数出口；
5. 如果两个出口都被找到了，添加该文件的的文件名到我们能操作的文件列表中，m_lsFiles。

HRESULT CDllRegShlExt::Initialize (     LPCITEMIDLIST pidlFolder,    LPDATAOBJECT pDataObj,    HKEY hProgID ){TCHAR     szFile    [MAX_PATH];TCHAR     szFolder  [MAX_PATH];TCHAR     szCurrDir [MAX_PATH];TCHAR*    pszLastBackslash;UINT      uNumFiles;HDROP     hdrop;FORMATETC etc = { CF_HDROP, NULL, DVASPECT_CONTENT, -1, TYMED_HGLOBAL };STGMEDIUM stg = { TYMED_HGLOBAL };HINSTANCE hinst;bool      bChangedDir = false;HRESULT (STDAPICALLTYPE* pfn)();

    非常多的局部变量！第一步是从传进去的pDataObj参数中获得一个HDROP。这和第一部分的扩展有些相似。

    // Read the list of folders from the data object.  They're stored in HDROP    // format, so just get the HDROP handle and then use the drag 'n' drop APIs    // on it.    if ( FAILED( pDO->GetData ( &etc, &stg )))        return E_INVALIDARG;    // Get an HDROP handle.    hdrop = (HDROP) GlobalLock ( stg.hGlobal );    if ( NULL == hdrop )        {        ReleaseStgMedium ( &stg );        return E_INVALIDARG;        }    // Determine how many files are involved in this operation.    uNumFiles = DragQueryFile ( hdrop, 0xFFFFFFFF, NULL, 0 );

    接下来要做的就是一个获取下一个文件名的for循环(使用DragQueryFile())并试图用LoadLibrary()装载它。在该文的实际例子工程当中预先做了一些目录改变的工作。在这儿我把它忽略了，因为它有点儿太长了。

    for ( UINT uFile = 0; uFile < uNumFiles; uFile++ )        {        // Get the next filename.        if ( 0 == DragQueryFile ( hdrop, uFile, szFile, MAX_PATH ))            continue;        // Try & load the DLL.        hinst = LoadLibrary ( szFile );                if ( NULL == hinst )            continue;

    下一步，我们将看看它是否有两个必要函数的出口。

        // Get the address of DllRegisterServer();        (FARPROC&) pfn = GetProcAddress ( hinst, "DllRegisterServer" );        // If it wasn't found, skip the file.        if ( NULL == pfn )            {            FreeLibrary ( hinst );            continue;            }        // Get the address of DllUnregisterServer();        (FARPROC&) pfn = GetProcAddress ( hinst, "DllUnregisterServer" );        // If it was found, we can operate on the file, so add it to        // our list of files (m_lsFiles).        if ( NULL != pfn )            {            m_lsFiles.push_back ( szFile );            }        FreeLibrary ( hinst );        }   // end for

    最后一步就是(在最后一个if块中)添加文件名到m_lsFiles中。m_lsFiles是一个保存字符串的STL列表集。这个列表在稍后，就是当我们遍历所有文件注册和卸载的时候将被用到。

    在Initialize()的最后要做的就是释放资源并返回恰当的值给Explorer。

    // Release resources.    GlobalUnlock ( stg.hGlobal );    ReleaseStgMedium ( &stg );    // If we found any files we can work with, return S_OK.  Otherwise,    // return E_INVALIDARG so we don't get called again for this right-click    // operation.    return ( m_lsFiles.size() > 0 ) ? S_OK : E_INVALIDARG;}

    如果你看一眼例子项目代码的话，你会发现我不得不都过查看文件的文件名来计算出哪个目录正在被查看。你也许会纳闷为什么我不用pidlFolder参数。虽然在pidlFolder的文档中，它被解释为“包含正在显示上下文菜单的项目的文件夹的项目标志列表(the item identifier list for the folder that contains the item whose context menu is being displayed)(很抱歉我不能把这句话翻译好，贴出原文供参考)”。可是，我在Windows 98 上测试的时候，这个参数总是为NULL，所以它毫无用处。

添加我们的菜单项

    接下来的是IContextMenu方法。和以前一样，你需要添加IContextMenu到CDllRegShlExt实现的接口列表中。再一次的，做这些的步骤在第一部分中。

    我们将添加两个菜单项到菜单中，一个为注册选中的文件，一个是卸载它们。这些项看起来如下：

    我们的QueryContextMenu()实现和第一部分一样开始。我们检查uFlags，如果CMF_DEFAULTONLY标志存在的话立即返回。 

HRESULT CDLLRegShlExt::QueryContextMenu (    HMENU hmenu,    UINT  uMenuIndex,    UINT  uidFirstCmd,    UINT  uidLastCmd,    UINT  uFlags ){UINT uCmdID = uidFirstCmd;    // If the flags include CMF_DEFAULTONLY then we shouldn't do anything.    if ( uFlags & CMF_DEFAULTONLY )        {        return MAKE_HRESULT ( SEVERITY_SUCCESS, FACILITY_NULL, 0 );        }

    下面，我们添加"Register servers"菜单项。这儿有些新东西：我们给菜单项设置了位图。这和WinZip的菜单有点儿相似，也在菜单命令旁边显示一个小图标。

    // Add our register/unregister items.    InsertMenu ( hmenu, uMenuIndex, MF_STRING | MF_BYPOSITION, uCmdID++,                 _T("Register server(s)") );    // Set the bitmap for the register item.    if ( NULL != m_hRegBmp )        {        SetMenuItemBitmaps ( hmenu, uMenuIndex, MF_BYPOSITION, m_hRegBmp, NULL );        }    uMenuIndex++;

    SetMenuItemBitmaps()API函数我们宰菜单旁显示一个小齿轮的方法。注意uCmdID是自增加的，这样下一次我们调用InsertMenu()，它的命令ID将会比前一个大1。在这步骤的最后，uMenuIndex 被增加是因为我们的第二个菜单项将被显示在第一个之后。

    接着说第二个菜单项。它和第一个非常相似。

    InsertMenu ( hmenu, uMenuIndex, MF_STRING | MF_BYPOSITION, uCmdID++,                 _T("Unregister server(s)") );    // Set the bitmap for the unregister item.    if ( NULL != m_hUnregBmp )        {        SetMenuItemBitmaps ( hmenu, uMenuIndex, MF_BYPOSITION, m_hUnregBmp, NULL );        }

    最后，我们告诉Explorer我们添加了几个菜单项。

    return MAKE_HRESULT ( SEVERITY_SUCCESS, FACILITY_NULL, 2 );

提供敏感帮助和动词

    和前面的一样，当Explorer需要显示敏感帮助或者获得动词的时候，GetCommandString()方法被调用。和前一个稍稍不同的是我们添加了2个菜单项，所以我们必须首先检查uCmdID参数来知道Explorer正在呼叫哪个菜单项。

#include <atlconv.h>HRESULT CDLLRegShlExt::GetCommandString (     UINT  uCmdID,    UINT  uFlags,     UINT* puReserved,    LPSTR szName,    UINT  cchMax ){LPCTSTR szPrompt;    USES_CONVERSION;    if ( uFlags & GCS_HELPTEXT )        {        switch ( uCmdID )            {            case 0:                szPrompt = _T("Register all selected COM servers");            break;            case 1:                szPrompt = _T("Unregister all selected COM servers");            break;            default:                return E_INVALIDARG;            break;            }

    如果uCmdID为0，那么我们正在调用第一个(register)。如果为1，则在调用第二个(unregister)。在确定帮助字符串之后，我们将它拷贝到提供的缓存当中，必要的话，先将它转换成Unicode形式。

        // Copy the help text into the supplied buffer.  If the shell wants        // a Unicode string, we need to case szName to an LPCWSTR.        if ( uFlags & GCS_UNICODE )            {            lstrcpynW ( (LPWSTR) szName, T2CW(szPrompt), cchMax );            }        else            {            lstrcpynA ( szName, T2CA(szPrompt), cchMax );            }        }

    在这个扩展中，我同样也写了代码提供一个动词。然而，我在Windows 98下测试的时候，Explorer从来不调用GetCommandString()来获取一个动词。我甚至写了一个在DLL中调用ShellExecute()的测试程序然后试图使用动词，但是它还是不工作。我不知道这个情况在Windows NT下是否会有不同。这儿，我忽略了那些动词相关的代码，如果你感兴趣的话，你可以在例子项目中找到。

执行用户的选择

    当用户点击我们菜单中的一个时，Explorer调用我们的InvokeCommand()方法。InvokeCommand()首先检查了lpVerb的高位字(high word)。如果它是非零的，则它是被调用的动词的名称，因为我们知道动词不能正常工作(至少在Win 98下)，我们将它忽略了。否则，如果它的低位字(low word)是0或1，那么我们知道其中有一个菜单项目被点击了。

HRESULT CDllRegShlExt::InvokeCommand ( LPCMINVOKECOMMANDINFO pCmdInfo ){    // If lpVerb really points to a string, ignore this function call and bail out.    if ( 0 != HIWORD( pInfo->lpVerb ))        return E_INVALIDARG;    // Check that lpVerb is one of our commands (0 or 1)    switch ( LOWORD( pInfo->lpVerb ))        {        case 0:        case 1:            {            CProgressDlg dlg ( &m_lsFiles, pInfo );            dlg.DoModal();            return S_OK;            }        break;        default:            return E_INVALIDARG;        break;        }}

    如果lpVerb是0或1，我们创建一个对话框（从ATL类CDialogImpl继承），然后向它传递文件名列表。

    所有实际的工作都在CProgressDlg类中完成。它的OnInitDialog()函数初始化列表控件，然后调用CProgressDlg::DoWork()。DoWork()遍历在CDllRegShlExt::Initialize()中生成的文件名列表，然后调用文件中的合适的函数。基本代码如下；并不完全，因为我删掉了错误检查和填充列表控件的部分。不过这已经足够向大家演示如何遍历一个文件列表并执行每一个。

void CProgressDlg::DoWork(){HRESULT (STDAPICALLTYPE* pfn)();string_list::const_iterator it, itEnd;HINSTANCE hinst;LPCSTR    pszFnName;HRESULT   hr;WORD      wCmd;    wCmd = LOWORD ( m_pCmdInfo->lpVerb );    // We only support 2 commands, so check the value passed in lpVerb.    if ( wCmd > 1 )        return;    // Determine which function we'll be calling.  Note that these strings are    // not enclosed in the _T macro, since GetProcAddress() only takes an    // ANSI string for the function name.    pszFnName = wCmd ? "DllUnregisterServer" : "DllRegisterServer";    for ( it = m_pFileList->begin(), itEnd = m_pFileList->end();          it != itEnd;          it++ )        {        // Try to load the next file.        hinst = LoadLibrary ( it->c_str() );        if ( NULL == hinst )            continue;        // Get the address of the register/unregister function.        (FARPROC&) pfn = GetProcAddress ( hinst, pszFnName );        // If it wasn't found, go on to the next file.        if ( NULL == pfn )            continue;        // Call the function!        hr = pfn();

    我需要解释一下那个for循环，因为STL集合类是有点令人胆战心惊的，如果你不习惯使用它的话。m_pFileList是一个指向在CDllRegShlExt类中的m_lsFiles列表的指针。（这个指针被传递给了CProgressDlg的构造器。）STL列表集有一个类型叫做const_iterator，这是一个相似于MFC中POSITION类型的抽象实体。一个const_iterator变量像一个列表中常量对象的指针，所以这个遍历器(iterator)可以使用->访问它本身。遍历器可以使用++ 来自增实现在列表中前进。

    所以，这个for循环的初始化表达式调用list::begin()来获取一个遍历器“指向”列表中的第一个字符串，然后调用list::end()来获取一个遍历器“指向”列表的“末尾”，最后一个字符串的位置。 (我把这些词语放在引号里是为了强调指向，开始，和末尾的概念都是被const_iterator类型抽象了的，而且必须通过const_iterator的方法[像begin()]或者操作符[像++]。)这些遍历器被分别地赋给it和itEnd。 这个循环一直进行着，直到it等于itEnd；意思是，当it还没有到达列表的“末尾”时。这个遍历器it将会在循环过程每次自增加，这样它可以每次到达一个列表中的字符串。

    在遍历其中，表达式it->c_str() 使用->操作符。因为it像一个指向string的指针(记住，m_pFileList是一个STL string的列表)，it->c_str()在it当前所指向的string中调用c_str()函数。c_str()返回一个C类型的字符串指针，既然这样，就是一个LPCTSTR。

    DoWork()的余下部分是释放内存和错误检查。你可以从例子项目的ProgressDlg.cpp文件中获取所有代码。

    (我刚刚意识到叫一个变量为"it"，是多么的奇怪。很抱歉！) :)

注册外壳扩展

    这个DllReg扩展对可执行文件进行操作，所以我们注册它被EXE,DLL和OCX文件调用。和第一部分中一样，我们可以在RGS脚本中做这些事，DllRegShlExt.rgs。下面是注册我们的扩展为一个对于上述扩展名文件的上下文菜单扩展必需的脚本。

HKCR{    NoRemove dllfile    {        NoRemove shellex        {            NoRemove ContextMenuHandlers            {                ForceRemove DLLRegSvr = s '{8AB81E72-CB2F-11D3-8D3B-AC2F34F1FA3C}'            }        }    }    NoRemove exefile    {        NoRemove shellex        {            NoRemove ContextMenuHandlers            {                ForceRemove DLLRegSvr = s '{8AB81E72-CB2F-11D3-8D3B-AC2F34F1FA3C}'            }        }    }    NoRemove ocxfile    {        NoRemove shellex        {            NoRemove ContextMenuHandlers            {                ForceRemove DLLRegSvr = s '{8AB81E72-CB2F-11D3-8D3B-AC2F34F1FA3C}'            }        }    }}

    RGS文件的格式，以及关键词NoRemove和ForceRemove在第一部分已经解释过了，如果你忘了他们的意思的话。 

    正如我们前一个扩展一样，在NT/2000下，我们需要添加我们的扩展到“认证的(approved)”扩展列表当中。实现这个过程的代码在 DllRegisterServer()和DllUnregisterServer()函数中。我不想展示这些代码，因为它仅仅是一些简单的注册表访问，但是你可以从例子项目中中到这些代码。

看起来应该什么样呢？

    当你点击我们其中的一个菜单的时候，对话框就会出现，显示操作的结果：

    列表控件显示了每个文件的文件名和操作是否成功。当你选中一个项时，一个更详细的消息将被显示在下方。如果失败的话，将有调用失败的描述。

注册扩展的其他方法

    到现在为止，我们的扩展只被确定的文件类型调用。通过在HKCR\*下注册成为一个上下文菜单扩展使得被任何文件操作调用成为可能：

HKCR{    NoRemove *    {        NoRemove shellex        {            NoRemove ContextMenuHandlers            {                ForceRemove DLLRegSvr = s '{8AB81E72-CB2F-11D3-8D3B-AC2F34F1FA3C}'            }        }    }}

    HKCR\*键被所有文件调用的外壳扩展。注意文档中所说的该扩展也被其他外壳对象所调用（文件，目录，虚拟文件夹，控制面板项等等），但是我在测试中所见到的并不是这样。这些扩展仅仅被文件系统中的文件所调用。

    在外壳版本4.71以上，还有一个叫做HKCR\AllFileSystemObjects的键。如果我们在这个键下注册，我们的扩展将被文件系统中所有的文件和目录调用，根目录除外。（根目录调用的扩展在HKCR\Drive下注册。)然而，当我在这个键下注册的时候我看到一些奇怪的现象。“发送到”菜单也使用这个键，而它混在了DllReg菜单中间：

    你同样可以编写一个操作目录的上下文菜单扩展。要这样的例子的话，请看我的文章：
   A Utility to Clean Up Compiler Temp Files(一个清除编译临时文件的实用工具)。（译者：确实是个好玩艺 :)）

    最后，在外壳版本4.71以上，你可以使你的上下文菜单在用户右键单击一个正在查看目录（包括桌面）的资源管理器窗口背景时被调用。为了使你的扩展被这么调用，你必须在HKCR\Directory\Background\shellex\ContextMenuHandlers键下注册。使用这个方法，你可以向你的桌面上下文菜单中添加菜单项目或者其他任何目录。传递给IShellExtInit::Initialize()的参数有点儿不同，我会在我以后的文章中加以说明。

待续……

    接着的第三部分我们将实践一种新的扩展，查询。它将显示一些外壳对象的弹出式描述。我还将向你展示如何在外壳扩展中使用MFC。

    你可以从下面的网址获得这个和其他文章的最新版本：http://home.inreach.com/mdunn/code/

相关文章

• Shell编程 – 傻瓜教程1 (0)
• 免费软件套装 (0)
• [转]C/C++/Perl/汇编/Java效率比较 (0)
• PHP5 效率优化 (0)
• PHP & memcached (0)

HRESULT IShellExtInit::Initialize (

    LPCITEMIDLIST pidlFolder,

    LPDATAOBJECT pDataObj,

    HKEY hProgID );

#include <shlobj.h>

#include <comdef.h>

class ATL_NO_VTABLE CSimpleShlExt : 

    public CComObjectRootEx<CComSingleThreadModel>,

    public CComCoClass<CSimpleShlExt, &CLSID_SimpleShlExt>,

    public IDispatchImpl<ISimpleShlExt, &IID_ISimpleShlExt, &LIBID_SIMPLEEXTLib>,

    public IShellExtInit

{

BEGIN_COM_MAP(CSimpleShlExt)

    COM_INTERFACE_ENTRY(ISimpleShlExt)

    COM_INTERFACE_ENTRY(IDispatch)

    COM_INTERFACE_ENTRY(IShellExtInit)

END_COM_MAP()

protected:

    TCHAR m_szFile [MAX_PATH];

public:

    // IShellExtInit

    STDMETHOD(Initialize)(LPCITEMIDLIST, LPDATAOBJECT, HKEY);

HRESULT CSimpleShlExt::Initialize ( 

    LPCITEMIDLIST pidlFolder,

    LPDATAOBJECT pDataObj,

    HKEY hProgID )

{

FORMATETC fmt = { CF_HDROP, NULL, DVASPECT_CONTENT, -1, TYMED_HGLOBAL };

STGMEDIUM stg = { TYMED_HGLOBAL };

HDROP     hDrop;

    // Look for CF_HDROP data in the data object.

    if ( FAILED( pDataObj->GetData ( &fmt, &stg )))

        {

        // Nope! Return an "invalid argument" error back to Explorer.

        return E_INVALIDARG;

        }

    // Get a pointer to the actual data.

    hDrop = (HDROP) GlobalLock ( stg.hGlobal );

    // Make sure it worked.

    if ( NULL == hDrop )

        {

        return E_INVALIDARG;

        }

    // Sanity check – make sure there is at least one filename.

UINT uNumFiles = DragQueryFile ( hDrop, 0xFFFFFFFF, NULL, 0 );

    if ( 0 == uNumFiles )

        {

        GlobalUnlock ( stg.hGlobal );

        ReleaseStgMedium ( &stg );

        return E_INVALIDARG;

        }

HRESULT hr = S_OK;

    // Get the name of the first file and store it in our member variable m_szFile.

    if ( 0 == DragQueryFile ( hDrop, 0, m_szFile, MAX_PATH ))

        {

        hr = E_INVALIDARG;

        }

    GlobalUnlock ( stg.hGlobal );

    ReleaseStgMedium ( &stg );

    return hr;

}

class ATL_NO_VTABLE CSimpleShlExt : 

    public CComObjectRootEx<CComSingleThreadModel>,

    public CComCoClass<CSimpleShlExt, &CLSID_SimpleShlExt>,

    public IDispatchImpl<ISimpleShlExt, &IID_ISimpleShlExt, &LIBID_SIMPLEEXTLib>,

    public IShellExtInit,

    public IContextMenu

{

BEGIN_COM_MAP(CSimpleShlExt)

    COM_INTERFACE_ENTRY(ISimpleShlExt)

    COM_INTERFACE_ENTRY(IDispatch)

    COM_INTERFACE_ENTRY(IShellExtInit)

    COM_INTERFACE_ENTRY(IContextMenu)

END_COM_MAP()

public:

    // IContextMenu

    STDMETHOD(GetCommandString)(UINT, UINT, UINT*, LPSTR, UINT);

    STDMETHOD(InvokeCommand)(LPCMINVOKECOMMANDINFO);

    STDMETHOD(QueryContextMenu)(HMENU, UINT, UINT, UINT, UINT);

HRESULT IContextMenu::QueryContextMenu (

    HMENU hmenu,

    UINT  uMenuIndex, 

    UINT  uidFirstCmd,

    UINT  uidLastCmd,

    UINT  uFlags );

HRESULT CSimpleShlExt::QueryContextMenu (

    HMENU hmenu,

    UINT  uMenuIndex, 

    UINT  uidFirstCmd,

    UINT  uidLastCmd,

    UINT  uFlags )

{

    // If the flags include CMF_DEFAULTONLY then we shouldn't do anything.

    if ( uFlags & CMF_DEFAULTONLY )

        {

        return MAKE_HRESULT ( SEVERITY_SUCCESS, FACILITY_NULL, 0 );

        }

    InsertMenu ( hmenu, uMenuIndex, MF_BYPOSITION, uidFirstCmd, _T("SimpleShlExt Test Item") );

    return MAKE_HRESULT ( SEVERITY_SUCCESS, FACILITY_NULL, 1 );

}

HRESULT IContextMenu::GetCommandString (

    UINT idCmd,

    UINT uFlags,

    UINT *pwReserved,

    LPSTR pszName,

    UINT cchMax );

#include <atlconv.h>  // for ATL string conversion macros

HRESULT CSimpleShlExt::GetCommandString (

    UINT  idCmd,

    UINT  uFlags,

    UINT* pwReserved,

    LPSTR pszName,

    UINT  cchMax )

{

    USES_CONVERSION;

    // Check idCmd, it must be 0 since we have only one menu item.

    if ( 0 != idCmd )

        return E_INVALIDARG;

    // If Explorer is asking for a help string, copy our string into the

    // supplied buffer.

    if ( uFlags & GCS_HELPTEXT )

        {

        LPCTSTR szText = _T("This is the simple shell extension's help");

        if ( uFlags & GCS_UNICODE )

            {

            // We need to cast pszName to a Unicode string, and then use the

            // Unicode string copy API.

            lstrcpynW ( (LPWSTR) pszName, T2CW(szText), cchMax );

            }

        else

            {

            // Use the ANSI string copy API to return the help string.

            lstrcpynA ( pszName, T2CA(szText), cchMax );

            }

        return S_OK;

        }

    return E_INVALIDARG;

}

HRESULT IContextMenu::InvokeCommand ( LPCMINVOKECOMMANDINFO pCmdInfo );

HRESULT CSimpleShlExt::InvokeCommand ( LPCMINVOKECOMMANDINFO pCmdInfo )

{

    // If lpVerb really points to a string, ignore this function call and bail out.

    if ( 0 != HIWORD( pCmdInfo->lpVerb ))

        return E_INVALIDARG;

    // Get the command index - the only valid one is 0.

    switch ( LOWORD( pCmdInfo->lpVerb ))

        {

        case 0:

            {

            TCHAR szMsg [MAX_PATH + 32];

            wsprintf ( szMsg, _T("The selected file was:\n\n%s"), m_szFile );

            MessageBox ( pCmdInfo->hwnd, szMsg, _T("SimpleShlExt"),

                         MB_ICONINFORMATION );

            return S_OK;

            }

        break;

        default:

            return E_INVALIDARG;

        break;

        }

}

HKCR

{

    NoRemove txtfile

    {

        NoRemove ShellEx

        {

            NoRemove ContextMenuHandlers

            {

                ForceRemove SimpleShlExt = s '{5E2121EE-0300-11D4-8D3B-444553540000}'

            }

        }

    }

}

相关文章

• 免费软件套装 (0)
• IE编程 – ToolBar (0)
• 使用memcached进行内存缓存 (0)
• [转]C/C++/Perl/汇编/Java效率比较 (0)
• Shell编程 – 傻瓜教程2 (0)

PHP 5 引入了静态成员的概念，作用和 PHP 4 的函数内部静态变量一致，但前者是作为类的成员来使用。静态变量和 Ruby 的类变量(class variable)差不多，所有类的实例共享同一个静态变量。

<?php
class foo {
    function bar() {
        echo ‘foobar’;
    }
}

$foo = new foo;

// instance way

$foo->bar();

// static way

foo::bar();
?>

静态地调用非 static 成员，效率会比静态地调用 static 成员慢 50-60%。主要是因为前者会产生 E_STRICT 警告，内部也需要做转换。

使用类常量 (PHP5 ONLY)

PHP 5 新功能，类似于 C++ 的 const。

使用类常量的好处是：

- 编译时解析，没有额外开销
- 杂凑表更小，所以内部查找更快
- 类常量仅存在于特定「命名空间」，所以杂凑名更短
- 代码更干净，使除错更方便

(暂时)不要使用 require/include_once

require/include_once 每次被调用的时候都会打开目标文件！

- 如果用绝对路径的话，PHP 5.2/6.0 不存在这个问题
- 新版的 APC 缓存系统已经解决这个问题

文件 I/O 增加 => 效率降低

如果需要，可以自行检查文件是否已被 require/include。

不要调用毫无意义的函数

有对应的常量的时候，不要使用函数。

<?php
php_uname(‘s’) == PHP_OS;
php_version() == PHP_VERSION;
php_sapi_name() == PHP_SAPI;
?>
虽然使用不多，但是效率提升大概在 3500% 左右。

最快的 Win32 检查

<?php
$is_win = DIRECTORY_SEPARATOR == ‘\\’;
?>

- 不用函数
- Win98/NT/2000/XP/Vista/Longhorn/Shorthorn/Whistler…通用
- 一直可用

时间问题 (PHP>5.1.0 ONLY)

你如何在你的软件中得知现在的时间？简单，「time() time() again, you ask me…」。

不过总归会调用函数，慢。

现在好了，用 $_SERVER['REQUEST_TIME']，不用调用函数，又省了。

加速 PCRE

 对于不用保存的结果，不用 ()，一律用 (?:)

这样 PHP 不用为符合的内容分配内存，省。效率提升 15% 左右。

- 能不用正则，就不用正则，在分析的时候仔细阅读手册「字符串函数」部分。有没有你漏掉的好用的函数？

加速 strtr

如果需要转换的全是单个字符的时候，用字符串而不是数组来做 strtr：

<?php
$addr = strtr($addr, "abcd", "efgh"); // good
$addr = strtr($addr, array(‘a’ => ‘e’,
                           // …
                           )); // bad
?>
效率提升：10 倍。

不要做无谓的替换

即使没有替换，str_replace 也会为其参数分配内存。很慢！解决办法：

- 用 strpos 先查找(非常快)，看是否需要替换，如果需要，再替换

效率：

- 如果需要替换：效率几乎相等，差别在 0.1% 左右。
- 如果不需要替换：用 strpos 快 200%。

邪恶的 @ 操作符

不要滥用 @ 操作符。虽然 @ 看上去很简单，但是实际上后台有很多操作。用 @ 比起不用 @，效率差距：3 倍。

特别不要在循环中使用 @，在 5 次循环的测试中，即使是先用 error_reporting(0) 关掉错误，在循环完成后再打开，都比用 @ 快。

善用 strncmp

当需要对比「前 n 个字符」是否一样的时候，用 strncmp/strncasecmp，而不是 substr/strtolower，更不是 PCRE，更千万别提 ereg。strncmp/strncasecmp 效率最高(虽然高得不多)。

慎用 substr_compare (PHP5 ONLY)

按照上面的道理，substr_compare 应该比先 substr 再比较快咯。答案是否定的，除非：

- 无视大小写的比较
- 比较较大的字符串

不要用常量代替字符串

为什么：

- 需要查询杂凑表两次
- 需要把常量名转换为小写(进行第二次查询的时候)
- 生成 E_NOTICE 警告
- 会建立临时字符串

效率差别：700%。

不要把 count/strlen/sizeof 放到 for 循环的条件语句中

贴士：我的个人做法

<?php
for ($i = 0, $max = count($array);$i < $max; ++$i);
?>

效率提升相对于：

- count 50%
- strlen 75%

短的代码不一定快

<?php
// longest
if ($a == $b) {
    $str .= $a;
} else {
    $str .= $b;
}
// longer
if ($a == $b) {
    $str .= $a;
}
$str .= $b;

// short
$str .= ($a == $b ? $a : $b);
?>
你觉得哪个快？

效率比较：

- longest: 4.27
- longer: 4.43
- short: 4.76

不可思议？再来一个：
<?php
// original
$d = dir(‘.’);
while (($entry = $d->read()) !== false) {
    if ($entry == ‘.’ || $entry == ‘..’) {
        continue;
    }
}

// versus
glob(‘./*’);

// versus (include . and ..)
scandir(‘.’);
?>
哪个快？

效率比较：

- original: 3.37
- glob: 6.28
- scandir: 3.42
- original without OO: 3.14
- SPL (PHP5): 3.95

画外音：从此也可以看出来 PHP5 的面向对象效率提高了很多，效率已经和纯函数差得不太多了。

提高 PHP 文件访问效率

需要包含其他 PHP 文件的时候，使用完整路径，或者容易转换的相对路径。

<?php

include ‘file.php’; // bad approach

incldue ‘./file.php’; // good

include ‘/path/to/file.php’; // ideal

?>

物尽其用

PHP 有很多扩展和函数可用，在实现一个功能的之前，应该看看 PHP 是否有了这个功能？是否有更简单的实现？

<?php
$filename = "./somepic.gif";
$handle = fopen($filename, "rb");
$contents = fread($handle, filesize($filename));
fclose($handle);

// vs. much simpler

file_get_contents(‘./somepic.gif’);
?>

关于引用的技巧

引用可以：

- 简化对复杂结构数据的访问
- 优化内存使用
<?php
$a['b']['c'] = array();

// slow 2 extra hash lookups per access
for ($i = 0; $i < 5; ++$i)
    $a['b']['c'][$i] = $i;

// much faster reference based approach
$ref =& $a['b']['c'];
for ($i = 0; $i < 5; ++$i)
    $ref[$i] = $i;
?>
<?php
$a = ‘large string’;

// memory intensive approach
function a($str)
{
    return $str.‘something’;
}

// more efficient solution
function a(&$str)
{
    $str .= ‘something’;
}
?>
==============================================
参考资料
http://ilia.ws

Ilia 的个人网站，Blog，他参与的开发以及出版的一些稿物链接等等。
http://ez.no

eZ components 官方网站，eZ comp 是针对 PHP5 的开源通用库，以效率为己任，Ilia 也参与了开发。
http://phparch.com

php|architect，不错的 php 出版商/培训组织。买不起或者买不到的话，网上可以下到很多经典的盗版。

http://talks.php.net

相关文章

• PHP & memcached (0)
• 免费软件套装 (0)
• [转]C/C++/Perl/汇编/Java效率比较 (0)
• google背后的分布式架构 (0)
• 翻译：On having layout (0)

当你希望访问者每次都刷新你广告的图标，或每次都刷新你的计数器，就要禁用缓存了。通常HTML文件没有必要禁用缓存，对于ASP等页面，就可以使用禁用缓存，因为每次看到的页面都是在服务器动态生成的，缓存就失去意义。如果网页过期，那么存盘的cookie将被删除。
　　　用法：<Meta http-equiv="Set-Cookie" Content="cookievalue=xxx; expires=Wednesday, 21-Oct-98 16:14:21 GMT; path=/">
　　　注意：必须使用GMT的时间格式。
　　6、Window-target (显示窗口的设定)
　　　说明：强制页面在当前窗口以独立页面显示。
　　　用法：<Meta http-equiv="Widow-target" Content="_top">
　　　注意：这个属性是用来防止别人在框架里调用你的页面。Content选项：_blank、_top、_self、_parent。
　　7、Pics-label (网页RSAC等级评定)
　　　说明：在IE的Internet选项中有一项内容设置，可以防止浏览一些受限制的网站，而网站的限制级别就是通过该参数来设置的。
　　　用法：<META http-equiv="Pics-label" Contect="(PICS－1.1′http://www.rsac.org/ratingsv01.html’ I gen comment ‘RSACi North America Sever’ by ‘inet@microsoft.com’　for ‘http://www.microsoft.com’ on ’1997.06.30T14:21－0500′ r(n0 s0 v0 l0))">
　　　注意：不要将级别设置的太高。RSAC的评估系统提供了一种用来评价Web站点内容的标准。用户可以设置Microsoft Internet Explorer（IE3.0以上）来排除包含有色情和暴力内容的站点。上面这个例子中的HTML取自Microsoft的主页。代码中的（n 0 s 0 v 0 l 0）表示该站点不包含不健康内容。级别的评定是由RSAC，即美国娱乐委员会的评级机构评定的，如果你想进一步了解RSAC评估系统的等级内容，或者你需要评价自己的网站，可以访问RSAC的站点：http://www.rsac.org/。
　　8、Page-Enter、Page-Exit (进入与退出)
　　　说明：这个是页面被载入和调出时的一些特效。
　　　用法：<Meta http-equiv="Page-Enter" Content="blendTrans(Duration=0.5)">
　　　　　　<Meta http-equiv="Page-Exit" Content="blendTrans(Duration=0.5)">
　　　注意：blendTrans是动态滤镜的一种，产生渐隐效果。另一种动态滤镜RevealTrans也可以用于页面进入与退出效果:
　　　　　　<Meta http-equiv="Page-Enter" Content="revealTrans(duration=x,transition=y)">
　　　　　　<Meta http-equiv="Page-Exit" Content="revealTrans(duration=x,ransition=y)">
　　　　　　　Duration　　表示滤镜特效的持续时间(单位：秒)
　　　　　　　Transition　滤镜类型。表示使用哪种特效，取值为0-23。
　　　　　　　0 矩形缩小　　　　　　　1 矩形扩大
　　　　　　　2 圆形缩小　　　　　　　3 圆形扩大
　　　　　　　4 下到上刷新　　　　　　　5 上到下刷新
　　　　　　　6 左到右刷新　　　　　　　7 右到左刷新
　　　　　　　8 竖百叶窗　　　　　　　9 横百叶窗
　　　　　　 10 错位横百叶窗　　　　　　 11 错位竖百叶窗
　　　　　　 12 点扩散　　　　　　 13 左右到中间刷新
　　　　　　 14 中间到左右刷新　　　　　　 15 中间到上下
　　　　　　 16 上下到中间　　　　　　 17 右下到左上
　　　　　　 18 右上到左下　　　　　　 19 左上到右下
　　　　　　 20 左下到右上　　　　　　 21 横条
　　　　　　 22 竖条　　　　　　 23 以上22种随机选择一种
　　9、MSThemeCompatible (XP主题)
　　　说明：是否在IE中关闭 xp 的主题
　　　用法：<Meta http-equiv="MSThemeCompatible" Content="Yes">
　　　注意：关闭 xp 的蓝色立体按钮系统显示样式，从而和win2k 很象。
　　10、IE6 (页面生成器)
　　　说明：页面生成器generator，是ie6
　　　用法：<Meta http-equiv="IE6" Content="Generator">
　　　注意：用什么东西做的，类似商品出厂厂商。
　　11、Content-Script-Type (脚本相关)
　　　说明：这是近来W3C的规范，指明页面中脚本的类型。
　　　用法：<Meta http-equiv="Content-Script-Type" Content="text/javascript">
　　　注意：
※NAME变量
　　name是描述网页的，对应于Content（网页内容），以便于搜索引擎机器人查找、分类（目前几乎所有的搜索引擎都使用网上机器人自动查找meta值来给网页分类）。
　　name的value值（name=""）指定所提供信息的类型。有些值是已经定义好的。例如description(说明)、keyword(关键字)、refresh(刷新)等。还可以指定其他任意值，如：creationdate(创建日期) 、document ID(文档编号)和level(等级)等。
　　name的content指定实际内容。如：如果指定level(等级)为value(值)，则Content可能是beginner(初级)、intermediate(中级)、advanced(高级)。
　　1、Keywords (关键字)
　　　说明：为搜索引擎提供的关键字列表
　　　用法：<Meta name="Keywords" Content="关键词1,关键词2，关键词3,关键词4,……">
　　　注意：各关键词间用英文逗号“,”隔开。META的通常用处是指定搜索引擎用来提高搜索质量的关键词。当数个META元素提供文档语言从属信息时，搜索引擎会使用lang特性来过滤并通过用户的语言优先参照来显示搜索结果。例如：
　　　　　　<Meta name="Kyewords" Lang="EN" Content="vacation,greece,sunshine">
　　　　　　<Meta name="Kyewords" Lang="FR" Content="vacances,grè:ce,soleil">
　　2、Description (简介)
　　　说明：Description用来告诉搜索引擎你的网站主要内容。
　　　用法：<Meta name="Description" Content="你网页的简述">
　　　注意：
　　3、Robots (机器人向导)
　　　说明：Robots用来告诉搜索机器人哪些页面需要索引，哪些页面不需要索引。Content的参数有all、none、index、noindex、follow、nofollow。默认是all。
　　　用法：<Meta name="Robots" Content="All|None|Index|Noindex|Follow|Nofollow">
　　　注意：许多搜索引擎都通过放出robot/spider搜索来登录网站，这些robot/spider就要用到meta元素的一些特性来决定怎样登录。
　　　 all：文件将被检索，且页面上的链接可以被查询；
　　　 none：文件将不被检索，且页面上的链接不可以被查询；(和 "noindex, no follow" 起相同作用)
　　　 index：文件将被检索；（让robot/spider登录）
　　　 follow：页面上的链接可以被查询；
　　　 noindex：文件将不被检索，但页面上的链接可以被查询；(不让robot/spider登录)
　　　nofollow：文件将不被检索，页面上的链接可以被查询。(不让robot/spider顺着此页的连接往下探找)
　　4、Author (作者)
　　　说明：标注网页的作者或制作组
　　　用法：<Meta name="Author" Content="张三，abc@sohu.com">
　　　注意：Content可以是：你或你的制作组的名字,或Email
　　5、Copyright (版权)
　　　说明：标注版权
　　　用法：<Meta name="Copyright" Content="本页版权归Zerospace所有。All Rights Reserved">
　　　注意：
　　6、Generator (编辑器)
　　　说明：编辑器的说明
　　　用法：<Meta name="Generator" Content="PCDATA|FrontPage|">
　　　注意：Content="你所用编辑器"
　　7、revisit-after (重访)
　　　说明：
　　　用法：<META name="revisit-after" CONTENT="7 days" >
　　　注意：
※Head中的其它一些用法
　　1、scheme (方案)
　　　说明：scheme can be used when name is used to specify how the value of content should
　　　　　　be interpreted.
　　　用法：<meta scheme="ISBN" name="identifier" content="0-14-043205-1" />
　　　注意：
　　2、Link (链接)
　　　说明：链接到文件
　　　用法：<Link href="soim.ico" rel="Shortcut Icon">
　　　注意：很多网站如果你把她保存在收件夹中后，会发现它连带着一个小图标，如果再次点击进入之后还会发现地址栏中也有个小图标。现在只要在你的页头加上这段话，就能轻松实现这一功能。<LINK> 用来将目前文件与其它 URL 作连结，但不会有连结按钮，用於 <HEAD> 标记间， 格式如下：
　　　　　　　<link href="URL" rel="relationship">
　　　　　　　<link href="URL" rev="relationship">
　　3、Base (基链接)
　　　说明：插入网页基链接属性
　　　用法：<Base href="http://www.csdn.net/" target="_blank">
　　　注意：你网页上的所有相对路径在链接时都将在前面加上“http://www.cn8cn.com/”。其中

target="_blank"是链接文件在新的窗口中打开，你可以做其他设置。将“_blank”改为“_parent”是链接文件将在当前窗口的父级窗口中打开；改为“_self”链接文件在当前窗口（帧）中打开；改为“_top”链接文件全屏显示。

<head>　　
<title>文件头，显示在浏览器标题区</title>
<meta http-equiv="Content-Language" content="zh-cn">
　<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
　<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
　<meta name="ProgId" content="FrontPage.Editor.Document">
　<meta name="制作人" content="Simonzy">
　<meta name="主题词" content="HTML 网页制作 C# .NET JavaScript JS">
</head>

以上是META标签的一些基本用法，其中最重要的就是：Keywords和Description的设定。为什么呢？道理很简单，这两个语句可以让搜索引擎能准确的发现你，吸引更多的人访问你的站点!根据现在流行搜索引擎(Google，Lycos，AltaVista等)的工作原理，搜索引擎先派机器人自动在WWW上搜索，当发现新的网站时，便于检索页面中的Keywords和Description，并将其加入到自己的数据库，然后再根据关键词的密度将网站排序。

相关文章

• flickr对javascript干的好事 (0)
• 翻译：On having layout (0)
• 有漏洞的Web 2.0 (0)
• 大型高并发高负载网站的系统架构 (0)
• 二十一世纪让人悲伤的七个原因 (0)