2、找到“Internet 信息服务” —> “万维网服务”—>“性能功能”—>“动态内容压缩”、“万维网服务”—>“应用程序开发功能”—>“CGI”，勾选上然后确定。

3、打开IIS管理器，在中间的功能视图里打开“处理程序映射”，点击右边操作栏里的“添加模块映射”。

请求路径：*.php

模块：FastCgiModule

可执行文件："C:\\Program Files\\php\\php-cgi.exe"(注：“C:\\Program Files\\php”为PHP安装目录，如果路径中有空格，就必须要双引号）

名称：PHP_via_FastCGI

http://www.w2blog.net/download/iis6+fastcgi+php+memcache+eaccelerator/iis6.zip

2、php,vc9 非线程版本(Non Thread Safe)

http://windows.php.net/download/

php的安装

a、把下载回来的压缩包解压缩到 C:\\php5 目录。

b、给 C:\\php5 目录加上 NETWORK SERVICE 用户“读取和运行”权限。

c、把 c:\\php5\\php.ini-production 文件重命名为 php.ini ，编辑 php.ini ，修改字段值如下：

extension_dir = ext

cgi.force_redirect = 0

cgi.fix_pathinfo = 1

fastcgi.impersonate=1

3、fastcgi

FastCGI Extension

http://www.iis.net/download/fastcgi

该安装程序需要.net 2.0支持，请确认已经安装.net Framework2.0。

或

Web Platform

http://www.microsoft.com/web/downloads/

fastcgi的安装

a、双击下载回来的 msi 文件，一路 next 即可。

b、执行 Internet 信息服务(IIS)管理器。

c、双击本地计算机图标。

d、右键单位“网站”，选择“属性”。

e、点击“主目录”标签。

f、点击“配置...”按钮。

g、单击“添加...”按钮。

h、设置“可执行文件”值为 C:\\WINDOWS\\system32\\inetsrv\\fcgiext.dll

i、设置“扩展名”值为 php

j、设置“动作” 为“限制为” 值 GET,HEAD,POST

k、点击“确定”。

l、编辑 C:\\WINDOWS\\system32\\inetsrv\\fcgiext.ini ，在最后添加如下内容：

[Types]

php=php5

[php5]

ExePath=c:\\php5\\php-cgi.exe

4、在网站根目录下新建文本文件，重命名为 phpinfo.php，内容如下：

<?php

phpinfo();

?>

打开IE，在地址栏输入：http://localhost/phpinfo.php

5、php的memcache扩展

http://downloads.php.net/pierre/

下载nts版本

6、php的eAccelerator扩展

比较新的版本可以在http://www.apachelounge.com/viewforum.php?f=3或留意官网http://eaccelerator.net/

7、mysql

http://www.mysql.com/downloads/mysql/，选择MSI Installer版本。

8、memcache的server端

http://www.w2blog.net/download/iis6+fastcgi+php+memcache+eaccelerator/memcached.zip

打开Setup.bat

9、iis6中打开gzip

在IIS管理器中，“网站”上面右键－属性，不是下面的某个站点，而是整个网站。进入“服务”标签，选上启用动态内容压缩，静态内容压缩。

然后选中网站下面那个服务器扩展，新建一个服务器扩展。名字无所谓，下面的添加文件的路径是：c:\\windows\\system32\\inetsrv\\gzip.dll，然后启用这个扩展。

停用IIS服务及WWW服务，在c:\\windows\\system32\\inetsrv\\下面有个MetaBase.xml文件，可以用记事本打开，找到IIsCompressionScheme，有三个相同名字的段，分别是deflate,gzip,Parameters，第三段不用管它，前两段有基本相同的参数，在这两段的参数HcScriptFileExtensions下面都加上一行php，如果你有其它的动态程序要压缩，也加在这里。HcDynamicCompressionLevel改成9，（0－10，9是性价比最高的一个）。

http://www.w2blog.net/download/php/eAccelerator_v1_0_svn425_for_v5_3_4-VC6.zip

针对php5.3.3版本的eAccelerator下载连接：

http://www.sitebuddy.com/php/accelerators/eaccelerator-windows-binaries

eaccelerator配置信息详解(根据官方英文说明翻译)

extension="eAccelerator.dll"

解释：dll文件的路径，在linux下区分大小写。

--------------------

eaccelerator.shm_size="32"

解释：eaccelerator可使用的共享内存大小(单位为MB)。

--------------------

eaccelerator.cache_dir="/data/cache/eaccelerator"

解释：缓存路径，需有写权限

--------------------

eaccelerator.enable="1"

解释：打开或者关闭eaccelerator。"1"指打开，"0"指关闭。默认值为"1"。

--------------------

eaccelerator.optimizer="1"

解释：打开或者关闭代码优化，开启可以加快代码的执行速度。"1"指打开，"0"指关闭。默认值为"1"。

--------------------

eaccelerator.check_mtime="1"

解释：当打开此项时，eaccelerator会在每次请求时检查php文件的修改时间，看其是否被修改过，这会耗费一点时间，如果php文件被修改过，eaccelerator会重新编译缓存该php文件。当关闭此项时，如果php文件被修改，则需要手工删除eaccelerator缓存，才能显示被修改的php文件。"1"指打开，"0"指关闭。默认值为"1"。

--------------------

eaccelerator.debug="0"

解释：打开或者关闭调试记录。当打开时，eaccelerator会将对一个缓存文件的每次请求都写进log。打开此项只对调试eaccelerator是否有BUG时有益处。"1"指打开，"0"指关闭。默认值为"0"。

--------------------

eaccelerator.filter=""

解释：决定哪些PHP文件应该被缓存。可以指定一个范围(比如"*.php *.phtml")，这样被指定的文件就会被缓存。如果该范围以!开头，被指定的文件就不会被缓存。默认值为""，表示缓存所有的PHP文件。

--------------------

eaccelerator.shm_max="0"

解释：一个用户使用例如eaccelerator_put之类的函数能够往共享内存中加载的最大数据。默认值为"0"，表示不限制。(单位为字节)

--------------------

eaccelerator.shm_ttl="0"

解释：当没有足够的空闲共享内存去尝试缓冲一个新脚本时，将删除至少在shm_ttl秒之前没有被访问过的文件。默认值为"0"，表示不尝试从共享内存中删除任何旧的脚本。(单位为秒)

--------------------

eaccelerator.shm_prune_period="0"

解释：当没有足够的空闲共享内存去尝试缓冲一个新脚本时，将删所有旧脚本，前提是这个尝试在超过shm_prune_period秒之前被执行过。默认值为"0"，表示不尝试从共享内存中删除任何旧的脚本。(单位为秒)

--------------------

eaccelerator.shm_only="0"

解释：打开或者关闭在磁盘上缓存编译过的脚本。这个参数对会话数据和内容缓存没有效果。默认值为"0"，表示使用磁盘和共享内存来缓存。

--------------------

eaccelerator.compress="1"

解释：打开或者关闭缓存内容压缩。"1"指打开，"0"指关闭。默认值为"1"。

--------------------

eaccelerator.compress_level="9"

解释：内存压缩的级别。默认值为"9"，表示最大压缩。

新君威2.0AT，现在2.0的只有一个世博版。开起来和英朗差不多优点，但坐起来没英朗舒服，后排小窄，价钱比蒙迪欧致胜贵一些。。。

克鲁兹1.8AT，方向比较重、油门适中，可惜加速太肉，踩到一半都没什么推背感，悬挂太硬、隔音太差，挺失望的。。。

嘉年华三厢1.5AT，方向不错，加速一般，隔音差。。。

世嘉三厢1.6AT，方向不错，加速反映小慢，后排座椅角度不舒服，个人挺喜欢，可惜LD不喜欢方向盘和中控，一票毙掉。

速腾说驾照不够一年不给试驾，比较狗日。。。

资源：

http://movie.douban.com/subject/1294183/

http://www.verycd.com/topics/85906/

http://www.mtime.com/movie/14121/

剧情简介 · · · · · ·

作者简介

1、行级元素和块级元素的区别？

2、IE和FF及其他浏览器对盒模型解释的区别？

CSS：

1、清除浮动有哪几种方法？

2、透明/半透明效果如何实现？

Javascript：

1、跨域获取数据有哪几种方法？

2、处理浏览器兼容常见的问题是哪些？

3、在不考虑现有js框架的情况下，ajax如何实现？

4、一个完整的ajax请求有哪几步？

5、类似webqq那种应用，是如何实现的？如果不利用ajax的话，还有其他解决方法吗？

6、如果需要给一个div内的a元素捆绑事件，有什么快速的处理方法？

7、在不考虑现有js框架的情况下，页面元素的拖拽效果如何实现？请说出大概流程。

8、a怎么继承b？

综合：

1、前端优化有哪几种方法？

2、http的请求过程是怎样的？

3、http的304状态码是什么意思？

http://www.w2blog.net/download/javascript-load-optimization/javascript-load-optimization.pptx

及

http://www.w2blog.net/download/javascript-load-optimization/javascript-load-optimization.xlsx

由于ppt是早期制作的，所以相关具体测试结论，以excel文件记载为准。有疑问请联系eason007。

剧情简介 · · · · · ·

本文是基于现有的公开资料和个人的经验来对Google的整体架构进行总结和猜想。

在软件工程界，大家有一个共识，那就是"需求决定架构"，也就是说，架构的发展是为了更好地支撑应用。那么本文在介绍架构之前，先介绍一下Google所提供的主要产品有哪些？

产品

对于Google和它几个主要产品，比如搜索和邮件等，大家已经非常熟悉了，但是其提供服务的不只于此，并主要可分为六大类：

• 各种搜索：网页搜索，图片搜索和视频搜索等。
• 广告系统：AdWords和AdSense。
• 生产力工具：Gmail和Google Apps等。
• 地理产品：地图，Google Earth和Google Sky等。
• 视频播放：Youtube。
• PaaS平台：Google App Engine。

设计理念

根据现有的资料，Google的设计理念主要可以总结出下面这六条：

• Scale，Scale，Scale Scale：因为Google大多数服务所面对的客户都是百万级别以上的，导致Scale也就是伸缩已经深深植入Google的DNA中，而且Google为了帮助其开发人员更好地开发分布式应用和服务，不仅研发了用于大规模数据处理MapReduce框架，还推出了用于部署分布式应用的PaaS平台Google App Engine。
• 容错：一个分布式系统，就算是构建在昂贵的小型机或者大型机之上，也会不时地出现软件或者硬件方面的错误，何况Google的分布式系统还是浇筑在便宜的X86服务器之上，即使其设备标称的MTBF（平均故障间隔时间）很高，但是由于一个集群内的设备极多，导致其错误发生的几率非常高，比如李开复曾经提过这样一个例子：在一个拥有两万台X86服务器的集群中，每天大约有110台机器会出现宕机等恶劣情况，所以容错是一个不可被忽视的问题，同时这点也被Google院士Jeffrey Dean在多次演讲中提到。
• 低延迟：延迟是影响用户体验的一个非常重要的因素，Google的副总裁Marissa Mayer曾经说过："如果每次搜索的时间多延迟半秒的话，那么使用搜索服务的人将减少20%"，从这个例子可以看出，低延迟对用户体验非常关键，而且为了避免光速和复杂网络环境造成的延时，Google已在很多地区设置了本地的数据中心。
• 廉价的硬件和软件：由于Google每天所处理的数据和请求在规模上是史无前例的，所以现有的服务器和商业软件厂商是很难为Google"度身定做"一套分布式系统，而且就算能够设计和生产出来，其价格也是Google所无法承受的，所以其上百万台服务器基本采用便宜的X86系统和开源的Linux，并开发了一整套分布式软件栈，其中就包括上篇提到的MapReduce，BigTable和GFS等。
• 优先移动计算：虽然随着摩尔定律的不断发展，使得很多资源都处于不断地增长中，比如带宽等，但是到现在为止移动数据成本远大于移动计算的成本，所以在处理大规模数据的时候，Google还是倾向于移动计算，而不是移动数据。
• 服务模式：在Google的系统中，服务是相当常用的，比如其核心的搜索引擎需要依赖700-1000个内部服务，而且服务这种松耦合的开发模式在测试，开发和扩展等方面都有优势，因为它适合小团队开发，并且便于测试。

整体架构的猜想

在整体架构这部分，首先会举出Google的三种主要工作负载，接着会试着对数据中心进行分类，最后会做一下总结。

三种工作负载

对于Google而言，其实工作负载并不仅仅只有搜索这一种，主要可以被分为三大类：

• 本地交互：用于在用户本地为其提供基本的Google服务，比如网页搜索等，但会将内容的生成和管理工作移交给下面的内容交付系统，比如：生成搜索所需的Index等。通过本地交互，能让用户减少延迟，从而提高用户体验，而且其对SLA要求很高，因为是直接面对客户的。
• 内容交付：用于为Google大多数服务提供内容的存储，生成和管理工作，比如创建搜索所需的Index，存储YouTube的视频和GMail的数据等，而且内容交互系统主要基于Google自己开发那套分布式软件栈。还有，这套系统非常重视吞吐量和成本，而不是SLA。
• 关键业务：主要包括Google一些企业级事务，比如用于企业日常运行的客户管理和人力资源等系统和赚取利润的广告系统（AdWords和AdSense），同时关键业务对SLA的要求非常高。

两类数据中心

按照2008年数据，Google在全球有37个数据中心，其中19个在美国，12个在欧洲，3个在亚洲(北京、香港、东京)，另外3个分布于俄罗斯和南美。下图显示其中36个数据中心在全球的分布：

图1. 2008年Google全球数据中心分布图

根据 Jeffrey Dean 在2009年末的一次演讲和最近几期季报可以推测出Google并没有在2009年过多地增加全球数据中心的数量，总数应该还是稍多于36个，但很有可能在台湾、马来西亚、立陶宛等地增加新的数据中心。

虽然Google拥有数据中心数量很多，但是它们之间存在一定的差异，而且主要可以分为两类：其一是巨型数据中心，其二是大中型数据中心。

巨型数据中心：服务器规模应该在十万台以上，常坐落于发电厂旁以获得更廉价的能源，主要用于Google内部服务，也就是内容交付服务，而且在设计方面主要关注成本和吞吐量，所以引入了大量的定制硬件和软件，来减低PUE并提升处理量，但其对SLA方面要求不是特别严厉，只要保证绝大部分时间可用即可。下图是Google巨型数据中心的一个代表，这个数据中心位于美国俄勒冈州北部哥伦比亚河畔的Dalles市，总占地面积接近30英亩，并占用了附近一个1.8GW水力发电站的大部分电力输出，当这个数据中心全部投入使用后，将消耗103兆瓦的电力，这相当于一个中小型城市的整个生活用电。

图2. Google在美国俄勒冈州哥伦比亚河畔的巨型数据中心近景图

大中型数据中心：服务器规模在千台至万台左右，可用于本地交互或者关键业务，在设计方面上非常重视延迟和高可用性，使得其坐落地点尽可能地接近用户而且采用了标准硬件和软件，比如Dell的服务器和MySQL的数据库等，常见的PUE大概在1.5和1.9之间。本来坐落于北京朝阳区酒仙桥附近的"世纪互联"机房的Google中国数据中心也属于大中型数据中心这类，其采用的硬件有DELL的工作站和Juniper的防火墙等，下图为其一角。

图3. Google前中国数据中心的一角（参[26]）

关于两者的区别：具体请查看下表：

表1. 巨型与大中型数据中心的对比表

总结

最后，稍微总结一下，首先，普通的用户当访问Google服务时，大多会根据其请求的IP地址或者其所属的ISP将这个请求转发到用户本地的数据中心，如果本地数据中心无法处理这个请求，它很有可能将这个请求转发给远端的内容交互中心。其次，当广告客户想接入Google的广告系统时，这个请求会直接转发至其专业的关键业务数据中心来处理。

图4. 总结

因为本文是基于现有的公开资料和个人的经验的总结和猜想，所以和Google实际的运行情况没有任何联系。

作者: ikewu
网址: http://www.dbanotes.net/arch/google_app_engine_arch_guess.html

本系列文章基于公开资料对Google App Engine的实现机制这个话题进行深度探讨。在切入Google App Engine之前，首先会对Google的核心技术和其整体架构进行分析，以帮助大家之后更好地理解Google App Engine的实现。

本篇将主要介绍Google的十个核心技术，而且可以分为四大类：

• 分布式基础设施：GFS、Chubby 和 Protocol Buffer。
• 分布式大规模数据处理：MapReduce 和 Sawzall。
• 分布式数据库技术：BigTable 和数据库 Sharding。
• 数据中心优化技术：数据中心高温化、12V电池和服务器整合。

分布式基础设施

GFS

由于搜索引擎需要处理海量的数据，所以Google的两位创始人Larry Page和Sergey Brin在创业初期设计一套名为"BigFiles"的文件系统，而GFS（全称为"Google File System"）这套分布式文件系统则是"BigFiles"的延续。

首先，介绍它的架构，GFS主要分为两类节点：

• Master节点：主要存储与数据文件相关的元数据，而不是Chunk（数据块）。元数据包括一个能将64位标签映射到数据块的位置及其组成文件的表格，数据块副本位置和哪个进程正在读写特定的数据块等。还有Master节点会周期性地接收从每个Chunk节点来的更新（"Heart-beat"）来让元数据保持最新状态。
• Chunk节点：顾名思义，肯定用来存储Chunk，数据文件通过被分割为每个默认大小为64MB的Chunk的方式存储，而且每个Chunk有唯一一个64位标签，并且每个Chunk都会在整个分布式系统被复制多次，默认为3次。

下图就是GFS的架构图：

图1. GFS的架构图（参片[15]）

接着，在设计上，GFS主要有八个特点：

• 大文件和大数据块：数据文件的大小普遍在GB级别，而且其每个数据块默认大小为64MB，这样做的好处是减少了元数据的大小，能使Master节点能够非常方便地将元数据放置在内存中以提升访问效率。
• 操作以添加为主：因为文件很少被删减或者覆盖，通常只是进行添加或者读取操作，这样能充分考虑到硬盘线性吞吐量大和随机读写慢的特点。
• 支持容错：首先，虽然当时为了设计方便，采用了单Master的方案，但是整个系统会保证每个Master都会有其相对应的复制品，以便于在Master节点出现问题时进行切换。其次，在Chunk层，GFS已经在设计上将节点失败视为常态，所以能非常好地处理Chunk节点失效的问题。
• 高吞吐量：虽然其单个节点的性能无论是从吞吐量还是延迟都很普通，但因为其支持上千的节点，所以总的数据吞吐量是非常惊人的。
• 保护数据：首先，文件被分割成固定尺寸的数据块以便于保存，而且每个数据块都会被系统复制三份。
• 扩展能力强：因为元数据偏小，使得一个Master节点能控制上千个存数据的Chunk节点。
• 支持压缩：对于那些稍旧的文件，可以通过对它进行压缩，来节省硬盘空间，并且压缩率非常惊人，有时甚至接近90%。
• 用户空间：虽然在用户空间运行在运行效率方面稍差，但是更便于开发和测试，还有能更好利用Linux的自带的一些POSIX API。

现在Google内部至少运行着200多个GFS集群，最大的集群有几千台服务器，并且服务于多个Google服务，比如Google搜索。但由于GFS主要为搜索而设计，所以不是很适合新的一些Google产品，比YouTube、Gmail和更强调大规模索引和实时性的Caffeine搜索引擎等，所以Google已经在开发下一代GFS，代号为"Colossus"，并且在设计方面有许多不同，比如：支持分布式Master节点来提升高可用性并能支撑更多文件，Chunk节点能支持1MB大小的chunk以支撑低延迟应用的需要。

Chubby

简单的来说，Chubby 属于分布式锁服务，通过 Chubby，一个分布式系统中的上千个client都能够对于某项资源进行"加锁"或者"解锁"，常用于BigTable的协作工作，在实现方面是通过对文件的创建操作来实现"加锁"，并基于著名科学家Leslie Lamport的Paxos算法。

Protocol Buffer

Protocol Buffer，是Google内部使用一种语言中立、平台中立和可扩展的序列化结构化数据的方式，并提供 Java、C++ 和 Python 这三种语言的实现，每一种实现都包含了相应语言的编译器以及库文件，而且它是一种二进制的格式，所以其速度是使用 XML 进行数据交换的10倍左右。它主要用于两个方面：其一是RPC通信，它可用于分布式应用之间或者异构环境下的通信。其二是数据存储方面，因为它自描述，而且压缩很方便，所以可用于对数据进行持久化，比如存储日志信息，并可被Map Reduce程序处理。与Protocol Buffer比较类似的产品还有Facebook的 Thrift ，而且 Facebook 号称Thrift在速度上还有一定的优势。

分布式大规模数据处理

MapReduce

首先，在Google数据中心会有大规模数据需要处理，比如被网络爬虫（Web Crawler）抓取的大量网页等。由于这些数据很多都是PB级别，导致处理工作不得不尽可能的并行化，而Google为了解决这个问题，引入了MapReduce这个编程模型，MapReduce是源自函数式语言，主要通过"Map（映射）"和"Reduce（化简）"这两个步骤来并行处理大规模的数据集。Map会先对由很多独立元素组成的逻辑列表中的每一个元素进行指定的操作，且原始列表不会被更改，会创建多个新的列表来保存Map的处理结果。也就意味着，Map操作是高度并行的。当Map工作完成之后，系统会先对新生成的多个列表进行清理（Shuffle）和排序，之后会这些新创建的列表进行Reduce操作，也就是对一个列表中的元素根据Key值进行适当的合并。

下图为MapReduce的运行机制：

图2. MapReduce的运行机制（参[19]）

接下来，将根据上图来举一个MapReduce的例子：比如，通过搜索Spider将海量的Web页面抓取到本地的GFS集群中，然后Index系统将会对这个GFS集群中多个数据Chunk进行平行的Map处理，生成多个Key为URL，value为html页面的键值对（Key-Value Map），接着系统会对这些刚生成的键值对进行Shuffle（清理），之后系统会通过Reduce操作来根据相同的key值（也就是URL）合并这些键值对。

最后，通过MapReduce这么简单的编程模型，不仅能用于处理大规模数据，而且能将很多繁琐的细节隐藏起来，比如自动并行化，负载均衡和机器宕机处理等，这样将极大地简化程序员的开发工作。MapReduce可用于包括"分布grep，分布排序，web访问日志分析，反向索引构建，文档聚类，机器学习，基于统计的机器翻译，生成Google的整个搜索的索引"等大规模数据处理工作。Yahoo也推出MapReduce的开源版本Hadoop，而且Hadoop在业界也已经被大规模使用。

Sawzall

Sawzall可以被认为是构建在MapReduce之上的采用类似Java语法的DSL（Domain-Specific Language），也可以认为它是分布式的AWK。它主要用于对大规模分布式数据进行筛选和聚合等高级数据处理操作，在实现方面，是通过解释器将其转化为相对应的MapReduce任务。除了Google的Sawzall之外，yahoo推出了相似的Pig语言，但其语法类似于SQL。

分布式数据库技术

BigTable

由于在Google的数据中心存储PB级以上的非关系型数据时候，比如网页和地理数据等，为了更好地存储和利用这些数据，Google开发了一套数据库系统，名为"BigTable"。BigTable不是一个关系型的数据库，它也不支持关联（Join）等高级SQL操作，取而代之的是多级映射的数据结构，并是一种面向大规模处理、容错性强的自我管理系统，拥有TB级的内存和PB级的存储能力，使用结构化的文件来存储数据，并每秒可以处理数百万的读写操作。

什么是多级映射的数据结构呢？就是一个稀疏的，多维的，排序的Map，每个Cell由行关键字，列关键字和时间戳三维定位．Cell的内容是一个不解释的字符串，比如下表存储每个网站的内容与被其他网站的反向连接的文本。 反向的URL com.cnn.www是这行的关键字；contents列存储网页内容，每个内容有一个时间戳，因为有两个反向连接，所以archor的Column Family有两列：anchor: cnnsi.com和anchhor:my.look.ca。Column Family这个概念，使得表可以轻松地横向扩展。下面是它具体的数据模型图：

图3. BigTable数据模型图（参[4]）

在结构上，首先，BigTable基于GFS分布式文件系统和Chubby分布式锁服务。其次BigTable也分为两部分：其一是Master节点，用来处理元数据相关的操作并支持负载均衡。其二是tablet节点，主要用于存储数据库的分片tablet，并提供相应的数据访问，同时Tablet是基于名为SSTable的格式，对压缩有很好的支持。

图4. BigTable架构图（参[15]）

BigTable正在为Google六十多种产品和项目提供存储和获取结构化数据的支撑平台，其中包括有Google Print、 Orkut、Google Maps、Google Earth和Blogger等，而且Google至少运行着500个BigTable集群。

随着Google内部服务对需求的不断提高和技术的不断地发展，导致原先的BigTable已经无法满足用户的需求，而Google也正在开发下一代BigTable，名为"Spanner（扳手）"，它主要有下面这些BigTable所无法支持的特性：

• 支持多种数据结构，比如table，familie，group和coprocessor等。
• 基于分层目录和行的细粒度的复制和权限管理。
• 支持跨数据中心的强一致性和弱一致性控制。
• 基于Paxos算法的强一致性副本同步，并支持分布式事务。
• 提供许多自动化操作。
• 强大的扩展能力，能支持百万台服务器级别的集群。
• 用户可以自定义诸如延迟和复制次数等重要参数以适应不同的需求。

数据库Sharding

Sharding就是分片的意思，虽然非关系型数据库比如BigTable在Google的世界中占有非常重要的地位，但是面对传统OLTP应用，比如广告系统，Google还是采用传统的关系型数据库技术，也就是MySQL，同时由于Google所需要面对流量非常巨大，所以Google在数据库层采用了分片（Sharding）的水平扩展（Scale Out）解决方案，分片是在传统垂直扩展（Scale Up）的分区模式上的一种提升，主要通过时间，范围和面向服务等方式来将一个大型的数据库分成多片，并且这些数据片可以跨越多个数据库和服务器来实现水平扩展。

Google整套数据库分片技术主要有下面这些优点：

• 扩展性强：在Google生产环境中，已经有支持上千台服务器的MySQL分片集群。
• 吞吐量惊人：通过巨大的MySQL分片集群能满足巨量的查询请求。
• 全球备份：不仅在一个数据中心还是在全球的范围，Google都会对MySQL的分片数据进行备份，这样不仅能保护数据，而且方便扩展。

在实现方面，主要可分为两块：其一是在MySQL InnoDB基础上添加了数据库分片的技术。其二是在ORM层的Hibernate的基础上也添加了相关的分片技术，并支持虚拟分片（Virtual Shard）来便于开发和管理。同时Google也已经将这两方面的代码提交给相关组织。

数据中心优化技术

数据中心高温化

大中型数据中心的PUE（Power Usage Effectiveness）普遍在2左右，也就是在服务器等计算设备上耗1度电，在空调等辅助设备上也要消耗一度电。对一些非常出色的数据中心，最多也就能达到1.7，但是Google通过一些有效的设计使部分数据中心到达了业界领先的1.2，在这些设计当中，其中最有特色的莫过于数据中心高温化，也就是让数据中心内的计算设备运行在偏高的温度下，Google的能源方面的总监Erik Teetzel在谈到这点的时候说："普通的数据中心在70华氏度（21摄氏度）下面工作，而我们则推荐80华氏度（27摄氏度）"。但是在提高数据中心的温度方面会有两个常见的限制条件：其一是服务器设备的崩溃点，其二是精确的温度控制。如果做好这两点，数据中心就能够在高温下工作，因为假设数据中心的管理员能对数据中心的温度进行正负1/2度的调节，这将使服务器设备能在崩溃点5度之内工作，而不是常见的20度之内，这样既经济，又安全。还有，业界传言Intel为Google提供抗高温设计的定制芯片，但云计算界的顶级专家James Hamilton认为不太可能，因为虽然处理器也非常惧怕热量，但是与内存和硬盘相比还是强很多，所以处理器在抗高温设计中并不是一个核心因素。同时他也非常支持使数据中心高温化这个想法，而且期望将来数据中心甚至能运行在40摄氏度下，这样不仅能节省空调方面的成本，而且对环境也很有利。

12V电池

由于传统的UPS在资源方面比较浪费，所以Google在这方面另辟蹊径，采用了给每台服务器配一个专用的12V电池的做法来替换了常用的UPS，如果主电源系统出现故障，将由该电池负责对服务器供电。虽然大型UPS可以达到92%到95%的效率，但是比起内置电池的99.99%而言是非常捉襟见肘的，而且由于能量守恒的原因，导致那么未被UPS充分利用的电力会被转化成热能，这将导致用于空调的能耗相应地攀升，从而走入一个恶性循环。同时在电源方面也有类似的"神来之笔"，普通的服务器电源会同时提供5V和12V的直流电。但是Google设计的服务器电源只输出12V直流电，必要的转换在主板上进行，虽然这种设计会使主板的成本增加1美元到2美元，但是它不仅能使电源能在接近其峰值容量的情况下运行，而且在铜线上传输电流时效率更高。

服务器整合

谈到虚拟化的杀手锏时，第一个让人想到肯定是服务器整合，而且普遍能实现1:8的整合率来降低各方面的成本。有趣的是，Google在硬件方面也引入类似服务器整合的想法，它的做法是在一个机箱大小的空间内放置两台服务器，这些做的好处有很多，首先，减小了占地面积。其次，通过让两台服务器共享诸如电源等设备，来降低设备和能源等方面的投入。

作者: ikewu
网址: http://www.dbanotes.net/arch/google_app_engine_arch_1.html

http://www.w2blog.net/download/javascript-load-optimization/normal-script-src.html

结果：

并行下载脚本 IE/Chr/Op/FF

并行下载其他资源 IE/Chr/FF

保持顺序 Op/FF

忙指示器 Chr/FF

阻塞渲染 Op

阻塞onload Op/FF

更多反馈，请联系eason007，把#号换成@号

测试平台：

win7 旗舰版32位 xhtml1-trict IE8 Chr 6.0.401.1 Op 10.54 FF 3.6.4

如果在INSERT语句末尾指定了ON DUPLICATE KEY UPDATE，并且插入行后会导致在一个UNIQUE索引或PRIMARY KEY中出现重复值，则执行旧行UPDATE；如果不会导致唯一值列重复的问题，则插入新行。例如，如果列a被定义为UNIQUE，并且包含值1，则以下两个语句具有相同的效果：

     如果行作为新记录被插入，则受影响行的值为1；如果原有的记录被更新，则受影响行的值为2。

     如果你想了解更多关于INSERT INTO .. ON DUPLICATE KEY的功能说明，详见MySQL参考文档：13.2.4. INSERT语法

     现在问题来了，如果INSERT多行记录， ON DUPLICATE KEY UPDATE后面字段的值怎么指定？要知道一条INSERT语句中只能有一个ON DUPLICATE KEY UPDATE，到底他会更新一行记录，还是更新所有需要更新的行。这个问题困扰了我很久了，其实使用VALUES()函数一切问题都解决了。

     举个例子，字段a被定义为UNIQUE，并且原数据库表table中已存在记录(2,2,9)和(3,2,1)，如果插入记录的a值与原有记录重复，则更新原有记录，否则插入新行：

     以上SQL语句的执行，发现(2,5,7)中的a与原有记录(2,2,9)发生唯一值冲突，则执行ON DUPLICATE KEY UPDATE，将原有记录(2,2,9)更新成(2,5,9)，将(3,2,1)更新成(3,3,1)，插入新记录(1,2,3)和(4,8,2)

     注意：ON DUPLICATE KEY UPDATE只是MySQL的特有语法，并不是SQL标准语法！

传说中，程序员们喜欢用powerDesign进行数据库建模。通常都是先设计出物理模型图，在转换出数据库需要的SQL语句，从而生成数据库。
但，江湖中流传着“powerDesign逆向工程”的传说。好，我们今天就来利用PowerDesign来建立逆向工程。

基于MySql 5.0 的数据库，PowerDesigner12.主要分为这几个步骤。

1> 通过windows数据源管理，建立ODBC数据源。

• 首先，安装ODBC的补丁。
• 这里是mySql 3.5.1 和 mySql5.1.5的补丁文件。使用他们进行安装。

• 打开Windows的控制面板
• 打开管理工具

• 打开数据源(ODBC)

• 选择你要操作的数据库类型

• 输入数据库参数，并测试连接

 
2> 通过powerDesigner使用ODBC数据源，建立PowerDesigner的数据源。

• 新建物理模型.

• 选择数据库(DataBase)---连接（Connect）。

• 选择已经配置好的ODBC数据源。 

• 输入登录数据库的【用户名】和【密码】。

 
2> 使用PowerDesigner进行逆向工程。

• 选择 DataBase----Reverse Engineer Database。 

• 使用已经配置好的数据源。 

• 选择你感兴趣的内容。 

• 生成物理模型。 

• 我们稍做等待，我出现了我们需要的数据模型。如下图： 

• 放大后 

到这里，我们的逆向工程，就完成了。

资源：

http://movie.douban.com/subject/1307747/

http://www.verycd.com/topics/255549/

http://www.mtime.com/movie/15817/

剧情

幕后花絮

剧情简介 · · · · · ·