Google File System

前言

没什么好说的，传说中的文件系统，当代网络超大容量分布式文件系统设计的典范，Google的核心竞争力所在。Google的Search、GMail、 video、blog spaces等等都是用这个技术做的。Google目前的中国区总裁李开复就认为学计算机的学生都应该看看Google File System。

很佩服Google的开放精神，将GoogleFS的详细设计写成了Paper: The Google File System, （ http://labs.google.com/papers/GoogleFS-sosp2003.pdf） 作者是Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung。该论文长达15页，对Google FS介绍得非常详细，从设计时考虑的因素到详细的解决方案，以及测试和实际运行数据，都做了具体的说明，而不像IBM这么遮遮掩掩，从GPFS、 Storage Tank到TotalStorage SAN File System，一直都是小里小气的样子，生怕别人知道它做了啥。

在Google公开了GoogleFS的论文后（2003年），已经有开源的项目开始借鉴GoogleFS的设计思想，开发类似的新型大容量分布式文件系 统，如NDFS/ Hadoop等。

拍完GoogleFS的马屁，下面就该轮到详细的介绍一下GoogleFS了。目前关于GoogleFS最权威的资料就是上文提到的那片15页的技术论 文。本来想把论文翻译部分贴出来，结果发现网上早就有现成的翻译版本了，我就脸皮厚点，从chinaunix转载过来了，然后修正一些明显的错误，加上一 些自己的理解，放在这里了，嘿嘿。

简介

GoogleFS是一个可扩展的分布式文件系统，用于大型的、分布式的、对海量数据进行访问的应用。它运行于廉价的普通硬件上，但提供了容错复制功能，可 以给大量的用户提供总体性能较高的可靠服务。

1、设计概述

（1）设计假设

GoogleFS与传统的分布式文件系统有很多相同的目标，但GoogleFS的设计受到了当前及预期的应用方面的工作量以及技术环境的驱动，因而形成了 它与传统的分布式文件系统明显不同的设想。这就需要对传统的选择进行重新检验并进行完全不同的设计观点的探索。

GoogleFS与以往的文件系统的不同的特点如下：

1、硬件错误（包括存储设备或是存储节点的故障）不再被认为是异常的情况，而是将其作为常见的情况加以处理。因为文件系统由成千上万个用于存储的机器节点 构成，而这些机器是由廉价的普通硬件组成并被大量的客户机访问。硬件的数量和质量使得一些机器随时都有可能无法工作并且有一部分还可能无法恢复。所以实时 地监控、错误检测、容错、自动恢复对系统来说必不可少。（我们就吃过很多次这种亏啊，呜呜）

2、按照传统的标准，文件都非常大，长度达几个GB的文件是很平常的。每个文件通常包含很多应用对象。因为经常要处理快速增长的、包含数以万计的对象、长 度达TB的数据集，我们很难管理成千上万的KB规模的文件块，即使底层文件系统提供支持。因此，设计中操作的参数、块的大小必须要重新考虑。对大型的文件 的管理一定要能做到高效，对小型的文件也必须支持，但不必优化。

3、大部分文件的更新是通过添加新数据完成的，而不是改变已存在的数据。在一个文件中随机的操作在实践中几乎不存在。一旦写完，文件就只可读，很多数据都 有这些特性。一些数据可能组成一个大仓库以供数据分析程序扫描。有些是运行中的程序连续产生的数据流。有些是档案性质的数据，有些是在某个机器上产生、在 另外一个机器上处理的中间数据。由于这些对大型文件的访问方式，添加操作成为性能优化和原子性保证的焦点。而在客户机中缓存数据块则失去了吸引力。

4、工作量主要由两种读操作构成：对大量数据的流方式的读操作和对少量数据的随机方式的读操作。在前一种读操作中，可能要读几百KB，通常达 1MB和更多。来自同一个客户的连续操作通常会读文件的一个连续的区域。随机的读操作通常在一个随机的偏移处读几个KB。性能敏感的应用程序通常将对少量 数据的读操作进行分类并进行批处理以使得读操作稳定地向前推进，而不要让它来来回回的读。

5、工作量还包含许多对大量数据进行的、连续的、向文件添加数据的写操作。所写的数据的规模和读相似。一旦写完，文件很少改动。在随机位置对少量数据的写 操作也支持，但不必非常高效。

6、系统必须高效地实现定义完好的大量客户同时向同一个文件的添加操作的语义。

（2）系统接口

虽然GoogleFS没有像POSIX那样实现标准的API，但它提供了一个相似地文件系统界面，文件在目录中按层次组织起来并由路径名标识。

（3）体系结构

一个GoogleFS集群由一个Master和大量的chunkserver构成，并被许多客户（Client）访问。如图1所示。Master和 chunkserver通常是运行用户层服务进程的Linux机器。只要资源和可靠性允许，chunkserver和Client可以运行在同一个机器 上。

图1 GoogleFS架构

文件被分成固定大小的块(block)。每个块由一个不变的、全局唯一的64位的chunk-handle标识，chunk-handle是在块创建的时 候由Master分配的。chunkserver将块当作Linux文件存储在本地磁盘并可以读和写由chunk-handle和位区间指定的数据。出于 可靠性考虑，每一个块被复制到多个chunkserver上。默认情况下，保存3个副本，但这可以由用户指定。

Master维护文件系统所有的元数据（metadata），包括名字空间、访问控制信息、从文件到块的映射以及块的当前位置。它也控制系统范围的活动， 如块租约（lease）管理，孤儿块的垃圾收集，chunkserver间的块迁移。Master定期通过HeartBeat消息与每一个 chunkserver通信，给chunkserver传递指令并收集它的状态。

Hadoop分布式文件系统：架构 和设计要点

一、前提和设计目标

1、硬件错误是常态，而非异常情况，HDFS可能是有成百上千的server组成，任何一个组件都有可能一直失效，因此错误检测和快速、自动的恢复是HDFS的核心架构目标。

2、跑在HDFS上的应用与一般的应用不同，它们主要是以流式读为主，做批量处理；比之关注数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。

3、HDFS以支持大数据集合为目标，一个存储在上面的典型文件大小一般都在千兆至T字节，一个单一HDFS实例应该能支撑数以千万计的文件。

4、HDFS应用对文件要求的是write-one-read-many访问模型。一个文 件经过创建、写，关闭之后就不需要改变。这一假设简化了数据一致性问 题，使高吞吐量的数据访问成为可能。典型的如MapReduce框架，或者一个web crawler应用都很适合这个模型。

5、移动计算的代价比之移动数据的代价低。一个应用请求的计算，离它操作的数据越近就越高效，这在数据达到海量级别的时候更是如此。将计算移动到数据附近，比之将数据移动到应用所在显然更好，HDFS提供给应用这样的接口。

6、在异构的软硬件平台间的可移植性。

二、Namenode和Datanode

HDFS采 用master/slave架构。一个HDFS集群是有一个Namenode和一定数目的Datanode组成。Namenode是一个中心服 务器，负责管理文件系统的namespace和客户端对文件的访问。Datanode在集群中一般是一个节点一个，负责管理节点上它们附带的存储。在内 部，一个文件其实分成一个或多个block，这些block存储在Datanode集合里。Namenode执行文件系统的namespace操作，例如 打开、关闭、重命名文件和目录，同时决定block到具体Datanode节点的映射。Datanode在Namenode的指挥下进行block的创 建、删除和复制。Namenode和Datanode都是设计成可以跑在普通的廉价的运行linux的机器上。HDFS采用java语言开发，因此可以部署在很大范围的机器上。一个典型的部署场景是一台机器跑一个单独的Namenode节点，集群中的其 他机器各跑一个Datanode实例。这个架构并不排除一台机器上跑多个Datanode，不过这比较少见。

单一节点的Namenode大大简化了系统的架构。Namenode负责保管和管理 所有的HDFS元数据，因而用户数据就不需要通过Namenode（也就是说文件数 据的读写是直接在Datanode上）。

三、文件系统的namespace

HDFS支持传统的层次型文件组织，与大多数其他文件系统类似，用户可以创建目录，并在其间创建、删除、移动和重命名文件。HDFS不支持user quotas和访问权限，也不支持链接（link)，不过当前的架构并不排除实现这些特性。Namenode维护文件系统的namespace，任何对文件系统namespace和文件属性的修改都将被Namenode记录下来。应用可以设置HDFS保存的文件的副本数目，文件副本的数目称为文件的 replication因子，这个信息也是由Namenode保存。

四、数据复制

HDFS被设计成在一个大集群中可以跨机器地可靠地存储海量的文件。它将每个文件存储成block序列，除了最后一个block，所有的block都是同样的大小。文件的所有block为了容错都会被复制。每个文件的block大小和replication因子都是可配置的。Replication因子可 以在文件创建的时候配置，以后也可以改变。HDFS中的文件是write-one，并且严格要求 在任何时候只有一个writer。Namenode全权管理block的复制，它周期性地从集群中的每个Datanode接收心跳包和一个Blockreport。心跳包的接收 表示该Datanode节点正常工作，而Blockreport包括了该Datanode上所有的block组成的列表。

1、副本的存放，副本的存放是HDFS可靠性和性能的关键。HDFS采用一种称为rack-aware的策略来改进数 据的可靠性、有效性和网络带宽的利用。这个策略实现的短期目标是验证在生产环境下的表现，观察它的行为，构建测试和研究的基础，以便实现更先进的策略。庞大的HDFS实例一般运行在多个机架的计算机形成的集群上，不同机架间的两台机器的通讯需要通过交换机，显然通常情况下，同一个机架内的两个节点间的带宽会比不同机架间的两台机器的带宽 大。

通过一个称为Rack Awareness的过程，Namenode决定了每个Datanode所属的rack id。 一个简单但没有优化的策略就是将副本存放在单独的机架上。这样可以防止整个机架（非副本存放）失效的情况，并且允许读数据的时候可以从多个机架读取。这个简单策略设置可以将副本分布在集群中，有利于组件失败情况下的负载均衡。但是，这个简单策略加大了写的代价，因为一个写操作需要传输block到多个机架。

在大多数情况下，replication因子是3，HDFS的存放策略是将一 个副本存放在本地机架上的节点，一个副本放在同一机架上的另一个节点，最后一 个副本放在不同机架上的一个节点。机架的错误远远比节点的错误少，这个策略不会影响到数据的可靠性和有效性。三分之一的副本在一个节点上，三分之二在一个机架上，其他保存在剩下的机架中，这一策略改进了写的性能。

2、副本的选择，为了降低整体的带宽消耗和读延时，HDFS会尽量让reader读最近的副本。 如果在reader的同一个机架上有一个副本，那么就读该副本。如果一个HDFS集群跨越多个数 据中心，那么reader也将首先尝试读本地数据中心的副本。

3、SafeMode

Namenode启动后会进入一个称为SafeMode的特殊状态，处在这个状态的Namenode是不会进行数据块的复制的。Namenode从所有的 Datanode接收心跳包和Blockreport。Blockreport包括了某个Datanode所有的数据块列 表。每个block都有指定的最小数目的副本。当Namenode检测确认某个Datanode的数据块副本的最小数目，那么该Datanode就会被认为是安全的；如果一定百分比（这 个参数可配置）的数据块检测确认是安全的，那么Namenode将退出SafeMode状态，接下来它 会确定还有哪些数据块的副本没有达到指定数目，并将这些block复制到其他Datanode。

五、文件系统元数据的持久化

Namenode存储HDFS的元数据。对于任何对文件元数据产生修改的操作，Namenode都使用一个称为Editlog的事务日志记录下来。例如， 在HDFS中创建一个文件，Namenode就会在Editlog中插入一条记录 来表示；同样，修改文件的replication因子也将往 Editlog插入一条记录。Namenode在本地OS的文件系统中存 储这个Editlog。整个文件系统的namespace，包括block到文件 的映射、文件的属性，都存储在称为FsImage的文件中，这个文件也是放在Namenode所在系统的文件 系统上。

Namenode在内存中保存着整个文件系统namespace和文件Blockmap的映像。这个关 键的元数据设计得很紧凑，因而一个带有4G内存的 Namenode足够支撑海量的文件和目录。当Namenode启动时，它从硬盘中读取Editlog和FsImage，将所有Editlog中的事务作用（apply)在内存中的FsImage ，并将这个新版本的FsImage从内存中flush到硬盘上,然后再truncate这个旧的Editlog，因为这个旧的Editlog的事务都已经作用在FsImage上了。这个过程称为checkpoint。在当前实现中，checkpoint只发生在Namenode启动时，在不久的将来我们将实现支持周期性的checkpoint。

Datanode并不知道关于文件的任何东西，除了将文件中的数据保存在本地的文件系统上。它把每个HDFS数据块存储在本地文件系统上隔离的文件中。 Datanode并不在同一个目录创建所有的文件，相反，它用启发式地方法来确定每个目录的最佳文件数目，并且在适当的时候创建子目录。在同一个目录创建所有的文件不是最优的选择，因为本地文件系统可能无法高效地在单一目录中支持大量的文件。当一个Datanode启动时，它扫描本地文件系统，对这些本地文件产生相应的一个所有HDFS数据块的列表，然后发送报告到Namenode，这个报告就是Blockreport。

六、通讯协议

所有的HDFS通讯协议都是构建在TCP/IP协议上。客户端通 过一个可配置的端口连接到Namenode，通过ClientProtocol与Namenode交互。而Datanode是使用DatanodeProtocol与Namenode交互。从ClientProtocol和Datanodeprotocol抽象出一个远程调用(RPC），在设计上，Namenode不会主动发起RPC，而是是响应来自客户端和 Datanode 的RPC请求。

网站文件的存储还是要讲究的，如果在网站成立初期，数据量不大就没有注意，随着时间的增长，网站的图片文件等数据肯定会越来越多，如何解决这些文件 存储也成了新的难题。如果把这些文件都完全采用大硬盘存储来解决，并不是一个好主意，因为数据量越大风险就越高，虽然文件能存得下，但是故障率相应会较 高，另外重建耗费时间也比较长。所以最好的办法是尽可能考虑分布式存储，把文件想办法利用网络分散到多个机器上。

从我所了解的存储结构来看，分布式存储大致可以分为几种：

1、类googlefs的分布式文件系统

因为目前googlefs没有开源，所以网上出现的分布式文件系统都是利用google的方案自行实现的。这个方案的优点是可用性比较高，基本上基 于硬盘的应用都可以处理，可用范围就比较广泛。我看了gfs、gfs2、ocfs2、FastDFS、MogileFS的一些相关介绍，大致有一些认识。

首先是文档比较少而出现的问题倒不少;然后是目前这些还没有一个能称得上是稳定版本，如果有的话，估计也就是其中一些收费的版本。因为磁盘存储乃是 致关重要，所以目前建议还是不要轻易把这些东西部署到重要的地方。假如非常想使用的话，最好是做好充分测试，确保它的功能完全能够满足需要;然后还要想办 法在传统的文件系统中做好完全的备份，以免造成损失。

另外可以提的一个东西是memcached，这个东西实现了内存的分布式共享，稳定度貌似比以上这些分布式文件系统要稳定。不过是完全基于内存的， 如果数据量不是很大，可以一试。

2、手工使用文件路径分散存储

这个结构通常使用在web静态文件中，就以这种情形作为例子。

如果这些文件数量比较大，可以通过分散文件路径，把某个文件的访问指定到特定的一台或几台服务器上。例如：

1)采用域名的分散策略

例如使用a.xxx.com/b.xxx.com…来区分标记为a或b的一系列文件，这些文件存储的时候，依然按照标记，存到a或b的服务器 上。这个策略将区分机器的任务交由dns服务器来执行，扩容时会相应轻松。这需要web项目初期就规划好这些东东，后期才转用域名策略的成本比较高甚至不 可以实现。

2)采用目录的分散策略

假如域名初期并没有规划使用域名策略，那么可以采用代理服务器来进行目录级的划分。比如一般存储大量文件时，因为文件系统的限制以及效率问题，都会 按照一定规则划分了很多级的目录，按这些目录拆分机器也并不是困难的事情。这种架构的问题在于代理服务器的性能和可靠性问题，需要在这点上稍下一点功夫。

以上这两个方案，都要自行制定策略实现分散同步传输，传输一般可以归纳为推送和抓取两种办法，同步的话可以采用日志同步(把要同步的数据记入日志， 通过日志记录来传输相应文件)、比较同步(使用rsync等同步软件)或即时同步(有新的修改就立刻传输);另外要实现单点故障剔除的话，首先找一个策略 把文件存储到多个节点上，例如，a.xxx.com或目录a的文件相应也存到b和c节点;然后在环境中使用故障剔除技术(lvs或nginx等)，就可以 解决问题，例如：采用域名的话，可以采用lvs，缺点是使用的机器就会成倍增加;亦可再用一级代理服务器，缺点是会牺牲性能。采用目录的话，因为本身就用 到了代理服务器，所以只要存储得当，实现比较容易。

YSlow给如何提高网页效率和优化网站性能提供了22条建议，其中有一条是关于域名的：Use cookie-free domains。

使用 cookie-free domains 有什么好处呢？当用户浏览器发送一个静态文件，如图片image、CSS样式表文件时会同时发送同一个域名（或二级域名）下的cookies，但是网站服 务器对发送过来的cookies完全不予理会，因此这些没用的cookies白白浪费了网站带宽，影响网站加载速度和网页性能表现。YSlow建议为了解 决这个问题，就可以通过使用 cookie-free domains 的方法来做优化，从而提高网页效率。

使用二级域名作为cookie-free domains

通俗地说，所谓的 cookie-free domains 就是在浏览器发送静态内容的请求时不会发送cookies 的域名。YSlow提示可以申请注册一个二级域名专门用来储存这些静态图片、JS、静态CSS文件。

在前面泛域名解析设置影响seo和Google PR值这里提到了www开头，形如www.haohtml.com的域名实际上也是属于二级域名。如果你的网站主域名是www开头的域名，建立一个二级域 名作为单独储存（hosting）静态图片、JS、CSS文件的cookie-free domains 是可行的；但是如果网站主域名用的是比较短的顶级域名，如远方博客用的是不带www的顶级域名haohtml.com，使用新创建的二级域名作为 cookie-free domains的方法是无效的。因为顶级域名haohtml.com会向所有被请求的静态文件二级域名服务器发送cookies。

即www.haohtml.com 和 blog.haohtml.com是互相独立的两个“二级域名”，不会造成域名污染， blog.haohtml.com 可以作为cookie-free 域名；但是需要做一些设置，比如下面介绍的Wordpress 博客设置wp-config.php文件的实例。

顶级域名haohtml.com 会向所有被请求的二级域名（子域名：www.haohtml.com和blog.haohtml.com）发送 cookies，blog.haohtml.com 也会被污染，不能当作cookie-free 域名。具体原因在下面Wordpress 博客cookie-free domains设置中有介绍。

使用独立域名作为cookie-free domains

那么使用顶级域名的博客应该如何使用 cookie-free domains？解决方法是使用另外一个独立域名。比如雅虎Yahoo！ 自身使用的是就是独立域名ymig.com来作为cookie-free domains的，YouTube使用的是ytimg.com 独立域名。

现在注册一个域名也很便宜的，godaddy 域名以.com .info .org .net 后缀的域名第一年购买都很便宜，第二年续费比较贵，这时候第二年可以再换一个新的。其他一些域名注册商也差不多这样。

WordPress 博客cookie-free domains 设置

在Wordpress 博客中，针对使用带www域名作为网站主域名，其他二级域名作为cookie-free domains 的情况，还要再另外设置Cookie的作用域就可以了。打开wp-config.php文件，设置COOKIE_DOMAIN：

所谓的COOKIE_DOMAIN，就是cookie-free domains相反的意思。看看Wordpress 对Set Cookie Domain 的介绍：

为Wordpress设置的COOKIES Domain 可以进行一些特殊情况下的域名设置。比如使用二级域名存放静态内容。为了阻止Wordpress Cookies 在对每一个二级域名上的静态内容请求时被传送，我们可以只设置非静态域名为cookie domian。

前面我用已经启用了网页压缩功能，见 http://blog.haohtml.com/index.php/archives/3723,下面我们来对网页元素有效期进行设置。

首先，启用LoadModule expires_module modules/mod_expires.so,只要在httpd.conf中把前面的#号去掉就可以了。然后在httpd.conf最后添加以下几行

ExpiresActive On

ExpiresDefault “access plus 10 years”

重启apache，可以用firefox浏览器中的yslow插件查看最终效果，此时”add expires haders”项应该为A。表示配置成功.

先启用 LoadModule deflate_module modules/mod_deflate.so,只需要把前面的#去掉就可以了。

然后在httpd.conf最下面添加以下行:

DeflateBufferSize 8096 DeflateCompressionLevel 1 DeflateMemLevel 9 DeflateWindowSize 15

DeflateFilterNote Input instream DeflateFilterNote Output outstream DeflateFilterNote Ratio ratio DeflateFilterNote ratio LogFormat ‘”%r” %{outstream}n/%{instream}n (%{ratio}n%%)’ deflate CustomLog logs/deflate.log deflate

SetOutputFilter DEFLATE

AddOutputFilterByType DEFLATE text/html text/css application/x-javascript text/plain text/xml

然后重启apache,即可。可以用firefox的插件yslow来查看效果，此时会看到”Compress components with gzip”项的等级为A,说明配置成功了.

法则13 配置ETags

实体标签（ETags）是用于确定浏览器缓存中元素 与原Web 服务器中的元素是否相匹配的机制（实体是“元素”的另外一个称谓：如图片、脚本、样式 表等），它提供 了比last-modified 时间更为灵活的元素验证机制。每一个ETag，都是唯一的字符串，用于标识特定版本的元素，它需被包括在引号中。原Web 服务器在响应信息头中用Etag来标识元素，如：

>  HTTP/1.1 200 OK
>
>  Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT
>
>  ETag: “10c24bc-4ab-457e1c1f”
>
>  Content-Length: 12195

之后，如果浏览器需验证某元 素，它在信息头中用If-None-Match传回ETag给原Web 服务器，若ETag匹配，则服务器返回304代码而不是上例中的12195字节，从而节省了下载响应时间。

> GET /i/yahoo.gif HTTP/1.1
>
> Host: us.yimg.com
>
> If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT
>
> If-None-Match: “10c24bc-4ab-457e1c1f”
> HTTP/1.1 304 Not Modified

ETags的问题在于它们是基于服务器唯一性的某些属性构造的。而当今大部分网站都是使用服务器集群来处理请求，当浏览器先从原服务器1请求某元素，后来向另一服务器2验证该元素，这样Etag是不匹配的。默认情况下，在多服务器情形下，APACHE与IIS嵌入的Etag验证测试成功都显著减少。

Apache1.32.x的Etag格式是inode-si ze-timestamp，尽管同一文件存放在多个服务器的相同路径下、具有相 同大小，权限，时间戳等，但一台服务器的inode与另一台是不同的。

IIS 5.0和6.0的Etag存在类似问题，其格式是 Filetimestamp:ChangeNumber。ChangeNumber是用于跟踪IIS配置改变的一个计数值，每一个网站的IIS服务器的ChangeNumber都不尽相同。

最终对于同一个元素，Apache与IIS产生的Etag，在不同的web 服务器上，都不一样。由于ETag不同，用户不会接收到小的、快速的304响应，相反，他们将收到一个正常的200响应，来提收全部的元素。若网站只有一台服务器，这不是问题，但若由 多台服务器提供服务，且使用APACHE或IIS默认的Etag配置，用户访问将比较慢，服务器不堪重负，消耗更多的带宽，而且代理也不能有效缓存网站内容。即使元素有一个超长期的Expires头，用户重新刷新时，仍会制造带条件的GET请求。

因此，若不需要用到ETags系统提供的灵活的验证机制，最好删除ETag。Last-Modified头提供了基于元素时间戳的验证，何况删除ETag会减少http response及后续请求的HTTP头的大小。微软支持文章描述了如何删除ETags，而在 Apache下，只要在配置文件中设置FileETag none即可。

Cache-Control头域 Cache-Control指定请求和响应遵循的缓存机制。在请求消息或响应消息中设置Cache- Control并不会修改另一个消息处理过程中的缓存处理过程。请求时的缓存指令包括no-cache、no-store、max-age、max- stale、min-fresh、only-if-cached，响应消息中的指令包括public、private、no-cache、 no-store、no-transform、must-revalidate、proxy-revalidate、max-age。各个消息中的指令含 义如下

Public指示响应可被任何缓存区缓存

Private指示对于单个用户的整个或部分响应消息，不能被共享缓存处理。这允许服务器 仅仅描述当用户的部分响应消息，此响应消息对于其他用户的请求无效

no-cache指示请求或响应消息不能缓存

no-store用于防止 重要的信息被无意的发布。在请求消息中发送将使得请求和响应消息都不使用缓存。

max-age指示客户机可以接收生存期不大于指定时间（以秒为单 位）的响应

min-fresh指示客户机可以接收响应时间小于当前时间加上指定时间的响应

max-stale指示客户机可以接收超出超时 期间的响应消息。如果指定max-stale消息的值，那么客户机可以接收超出超时期指定值之内的响应消息。

Cache-control用于控制HTTP缓存（在HTTP/1.0中可能部分没实现，仅仅实现了 Pragma: no-cache）

数据包中的格式：

Cache-Control: cache-directive

cache-directive可以为以下：

request时用到：

| "no-cache"
| "no-store"
| "max-age" "=" delta-seconds
| "max-stale" [ "=" delta-seconds ]
| "min-fresh" "=" delta-seconds
| "no-transform"
| "only-if-cached"
| "cache-extension"

response时用到：

| "public"
| "private" [ "=" <"> field-name <"> ]
| "no-cache" [ "=" <"> field-name <"> ]
| "no-store"
| "no-transform"
| "must-revalidate"
| "proxy-revalidate"
| "max-age" "=" delta-seconds
| "s-maxage" "=" delta-seconds
| "cache-extension"

部分说明：
根据是否可缓存分为
Public  指示响应可被任何缓存区缓存。
Private  指示对于单个用户的整个或部分响应消息，不能被共享缓存处理。这允许服务器仅仅描述当用户的
部分响应消息，此响应消息对于其他用户的请求无效。
no-cache  指示请求或响应消息不能缓存（HTTP/1.0用Pragma的no-cache替换）
根据什么能被缓存
no-store  用于防止重要的信息被无意的发布。在请求消息中发送将使得请求和响应消息都不使用缓存。
根据缓存超时
max-age  指示客户机可以接收生存期不大于指定时间（以秒为单位）的响应。
min-fresh  指示客户机可以接收响应时间小于当前时间加上指定时间的响应。
max-stale  指示客户机可以接收超出超时期间的响应消息。如果指定max-stale消息的值，那么客户机可以
接收超出超时期指定值之内的响应消息。
Expires 表示存在时间，允许客户端在这个时间之前不去检查（发请求），等同max-age的
效果。但是如果同时存在，则被Cache-Control的max-age覆盖。
格式：
Expires = "Expires" ":" HTTP-date
例如
Expires: Thu, 01 Dec 1994 16:00:00 GMT （必须是GMT格式）

2.应用
通过HTTP的META设置expires和cache-control
<meta http-equiv="Cache-Control" content="max-age=7200" />
<meta http-equiv="Expires" content="Mon, 20 Jul 2009 23:00:00 GMT" />
上述设置仅为举例，实际使用其一即可。这样写的话仅对该网页有效，对网页中的图片或其他请求无效，并不会做任何cache。
这样客户端的请求就多了，尽管只是检查Last-modified状态的东西，但是请求一多对浏览速度必定有影响。

如果要对文件添加cache可以通过apache的mod_expire模块，写法为

本书结合Web 2.0以来Web开发领域的最新形势和特点，介绍了网站性能问题的现状、产生的原因，以及改善或解决性能问题的原则、技术技巧和最佳实践。重点关注网页的行为特征，阐释优化Ajax、CSS、JavaScript、Flash和图片处理等要素的技术，全面涵盖浏览器端性能问题的方方面面。在《高性能网站建设指南》中，作者给出了14条具体的优化原则，每一条原则都配以范例佐证，并提供了在线支持。《高性能网站建设指南》内容丰富，主要包括减少HTTP请求、Edge Computing技术、Expires Header技术、Gzip组件、CSS和JavaScript最佳实践、主页内联、Domain最小化、JavaScript优化、避免重定向的技巧、删除重复JavaScript的技巧、关闭ETags的技巧、Ajax缓存技术和最小化技术等。《高性能网站建设指南》适合Web架构师、信息架构师、 Web开发人员及产品经理阅读和参考。

下载地址(请使用 下载工具下载)：

高性能网站建设指南_CHS

也可以在网盘下载： 高性能网站建设指南.zip

一、Windows版Squid的下载与安装

下载windwosNT版本的squid下载地址：

http://squid.acmeconsulting.it/download/squid-2.6.STABLE13-bin.zip

1．把squid-2.6.STABLE13-bin.zip解压缩，把里面的squid文件夹拷到c:\下(squid默认的是c: \squid)

2．squid\etc目录下把

squid.conf.default拷贝一份重新命名为 squid.conf

cachemgr.conf.default拷贝一份重新命名为cachemgr.conf

mime.conf.default 拷贝一份重新命名为mime.conf

3．用文本编辑器打开squid.conf，需要修改的地方：

找到 http_port 3128在后面增加一行

http_port 80 transparent

找 到#cache_peer sib2.foo.net sibling 3128 3130 [proxy-only]在后面增加一行

cache_peer 192.168.1.8 parent 7001 0 no-query originserver

找到# TAG: visible_hostname在后面增加一行

visible_hostname volcano(任意命名)

找到 http_access deny all在其前面加#将这一行注释掉，然后增加一行

http_access allow all

4． 从命令行到c:\squid\sbin目录下执行

squid -i（将squid服务加入到服务里面）

squid -z

安装完成

5．从服务里启动squid

访问squid服务器:

http://192.168.1.2(你 的squid服务器IP地址)»>指向http://192.168.1.8:7001(web服务器地址)

如果 把#http_access deny all打开把http_access allow all注释掉，你的访问就会被拒绝

你需要配置 一下：找到下面两行

#acl our_networks src 192.168.1.0/24 192.168.2.0/24

#http_access allow our_networks

– 备份 mysqldump –force –quick –skip-opt –create-options –add-drop-table –extended-insert –host=”localhost” –user=”root” –password=”密码” “数据库名称” > C:/2010-01-26.sql ** – 还原** mysql –host=”localhost” –user=”root” –password=”密码” “数据库名称” < C:/2010-01-26.sql

本文总结了MySQL数据库备份及恢复常用命令mysqldump,source的用法。 还原一个数据库:mysql -h localhost -u root -p123456 www

备份一个数据库:mysqldump -h localhost -u root -p123456 www > d:\www2008-2-26.sql

//以下是在程序中进行测试

//$command = “mysqldump –opt -h $dbhost -u $dbuser -p $dbpass $dbname | gzip > $backupFile”;

$command=”mysqldump -h localhost -u root -p123456 guestbook > guestbook2-29.sql”;

system($command);

echo “success”;

智能DNS配置

智能DNS可以为同时有电信、网通、教育网服务器的网站提供智能的解析，让电信用户访问电信的服务器，网通的用户访问网通的服务器，达到互联互通的效果。 以下配置：网通用户使用网通web服务，其他使用电信服务 主DNS服务器 202.93.111.100 次DNS服务器 202.93.111.101 网通WEB     202.93.111.102 电信WEB     202.93.111.103 邮件服务器  202.93.111.104

一、DNS服务器安装 安装bind-9.4.2 #emerge -v bind

配置主机名： nano -w /etc/hosts 增加： 202.93.111.100   ns1.myddz.com ns1

配置dns本机器查找 nano -w /etc/resolv.conf 增加： domain myddz.com

二、 named.conf的配置

1. nano -w /etc/bind/named.conf
2. options {
3. directory “/var/bind”;
4. listen-on-v6 { none; };
5. pid-file “/var/run/named/named.pid”;
6. };
7. logging {
8. channel warning
9. { file “/data/logs/bind/named.log” versions 3 size 2048k;
10. severity warning;
11. print-category yes;
12. print-severity yes;
13. print-time yes;
14. };
15. channel query
16. { file “/data/logs/bind/query.log” versions 3 size 2048k;
17. severity info;
18. print-category yes;
19. print-severity yes;
20. print-time yes;
21. };
22. category default { warning; };
23. category queries { query; };
24. };
25. zone “.” IN {
26. type hint;
27. file “named.ca”;
28. };
29. include “cnc_acl.conf”;
30. view “view_cnc”{
31. match-clients{
32. CNC;
33. };
34. zone “.” IN {
35. type hint;
36. file “named.ca”;
37. };
38. zone “localhost” IN {
39. type master;
40. file “pri/localhost.zone”;
41. allow-update { none; };
42. notify no;
43. };
44. zone “127.in-addr.arpa” IN {
45. type master;
46. file “pri/127.zone”;
47. allow-update { none; };
48. notify no;
49. };
50. zone “myddz.com” IN {
51. type master;
52. file “named.myddz.com.CNC”;
53. allow-update {none;};
54. };
55. zone “111.93.202.in-addr.arpa” IN {
56. type master;
57. file “named.myddz.com.rev.CNC”;
58. allow-update {none;};
59. };
60. };
61. view “view_any”{
62. match-clients{
63. any;
64. };
65. zone “.” IN {
66. type hint;
67. file “named.ca”;
68. };
69. zone “localhost” IN {
70. type master;
71. file “pri/localhost.zone”;
72. allow-update { none; };
73. notify no;
74. };
75. zone “127.in-addr.arpa” IN {
76. type master;
77. file “pri/127.zone”;
78. allow-update { none; };
79. notify no;
80. };
81. zone “myddz.com” IN {
82. type master;
83. file “named.myddz.com”;
84. allow-update {none;};
85. };
86. zone “111.93.202.in-addr.arpa” IN {
87. type master;
88. file “named.myddz.com.rev”;
89. allow-update {none;};
90. };
91. };

三、添加网通的解析。1)正向解析

1、 新浪

新浪采用了ChinaCache做的CDN系统，ChinaCache在全国分布了四十多个 点，同时采用基于动态DNS分配的全球服务器负载均衡技术。

从新浪的站点结构可 以看出：

 www.sina.com.cn

Server: UnKnown

Address: 192.168.1.254

Non-authoritative answer:

Name: libra.sina.com.cn

Addresses: 61.135.152.71, 61.135.152.72, 61.135.152.73, 61.135.152.74 61.135.152.75, 61.135.152.76, 61.135.153.181, 61.135.153.182, 61.135.53.183, 61.135.153.184, 61.135.152.65, 61.135.152.66, 61.135.152.67, 61.135.12.68, 61.135.152.69, 61.135.152.70

Aliases: www.sina.com.cn, jupiter.sina.com.cn

在北京地区ChinaCache将 www.sina.com.cn 的网址解析到libra.sina.com.cn，然后 libra.sina.com.cn做了DNS负载均衡，将libra.sina.com.cn解析到61.135.152.71等16个ip上，这16 个ip分布在北京的多台前台缓存服务器上，使用squid做前台缓存。如果是在其它地区访问 www.sina.com.cn 可能解析到本地相应的服务器，例如 pavo.sina.com.cn，然后pavo又对应了很多做了squid的ip。这样就实现了在不同地区访问自动转到最近的服务器访问，达到加快访问 速度的效果。

我们再看一个新浪其它频道是指到哪里的：

news.sina.com.cn

Server: UnKnown

Address: 192.168.1.254

Non-authoritative answer:

Name: libra.sina.com.cn

Addresses: 61.135.152.65, 61.135.152.66, 61.135.152.67, 61.135.152.68 61.135.152.69, 61.135.152.70, 61.135.152.71, 61.135.152.72, 61.135.152.73 61.135.153.178, 61.135.153.179, 61.135.153.180, 61.135.153.181, 61.135.153.182 61.135.153.183, 61.135.153.184

Aliases: news.sina.com.cn, jupiter.sina.com.cn

mysql查 看表结构命令，如下:

desc 表名;

show columns from 表名;

describe 表名;

show create table 表名;

use information_schema

select * from columns where table_name=’表名’;

顺便记下：

show databases;

use 数据库名;

show tables;

原有一unique索引AK_PAS_Name(PAC_Name)在表 tb_webparamcounter中，

执行以下sql修改索引

alter table tb_webparamcounter drop index AK_PAS_Name;

alter table tb_webparamcounter add UNIQUE AK_PAS_Name(PC_ID,PAC_Name);

若发现索引的逻辑不对，还需要再加一个字段进去，执行

alter table tb_webparamcounter drop index AK_PAS_Name;

alter table tb_webparamcounter add UNIQUE AK_PAS_Name(PC_ID,PAC_Name,PAC_Value);

注 意：这时的PC_ID,PAC_Name,PAC_Value三个字段不是FOREIGN KEY

否则必需先drop FOREIGN KEY，再重做上一步才行

顺便提下oracle

select * from v$database;

select * from all_users;