**首先要记住的是: 正则表达式与通配符不一样,它们表示的含义并不相同!**正则表达式只是一种表示法,只要工具支持这种表示法， 那么该工具就可以处理正则表达式的字符串。vim、grep、awk 、sed 都支持正则表达式，也正是因为由于它们支持正则，才显得它们强大；

1基础正则表达式grep 工具，以前介绍过。

grep -[acinv]   ‘搜索内容串‘   filename

-a 以文本文件方式搜索 -c 计算找到的符合行的次数 -i 忽略大小写 -n 顺便输出行号 -v 反向选择，即显示不包含匹配文本的所有行 -h 查询多文件时不显示文件名。 -l 查询多文件时只输出包含匹配字符的文件名。 -s 不显示不存在或无匹配文本的错误信息。 grep命令加- E参数，这一扩展允许使用扩展模式匹配。

**其中搜索串可以是正则表达式!**grep: 要用好grep这个工具，其实就是要写好正则表达式，所以这里不对grep的所有功能进行实例讲解，只列几个例子，讲解一个正则表达式的写法。

$ ls -l | grep ‘^a’ 通过管道过滤ls -l输出的内容，只显示以a开头的行。

$ grep ‘test’ d* 显示所有以d开头的文件中包含test的行。

$ grep ‘test’ aa bb cc 显示在aa，bb，cc文件中匹配test的行。

$ grep ‘[a-z]{5}’ aa 显示所有包含每个字符串至少有5个连续小写字符的字符串的行。

$ grep ‘w(es)t.*\1’ aa 如果west被匹配，则es就被存储到内存中，并标记为1，然后搜索任意个字符（.），这些字符后面紧跟着另外一个es（\1），找到就显示该行。如果用egrep或grep -E，就不用”\”号进行转义，直接写成’w(es)t.\1’就可以了。

grep正则表达式元字符集（基本集）

元字符

功能

示例

匹配内容

^

锚定行的开始

基本语法

location [=||*|^~] /uri/ { … }

= 严格匹配。如果这个查询匹配，那么将停止搜索并立即处理此请求。

~ 为区分大小写匹配

~* 为不区分大小写匹配

!和!*分别为区分大小写不匹配及不区分大小写不匹配

^~ 如果把这个前缀用于一个常规字符串,那么告诉nginx 如果路径匹配那么不测试正则表达式。

例如:

location = / { # 只匹配 / 查询。

location / { # 匹配任何查询，因为所有请求都已 / 开头。但正则表达式规则和长的块规则将被优先和查询匹配。

location ^~ /images/ { # 匹配任何已 /images/ 开头的任何查询并且停止搜索。任何正则表达式将不会被测试。

location ~* .(gif|jpg|jpeg)$ { # 匹配任何以 gif、jpg 或 jpeg 结尾的请求。

++ 文件及目录匹配

• -f和!-f用来判断是否存在文件

• -d和!-d用来判断是否存在目录

• -e和!-e用来判断是否存在文件或目录

• -x和!-x用来判断文件是否可执行

++ 一些可用的全局变量

$args

$content_length

$content_type

$document_root

$document_uri

$host

$http_user_agent

$http_cookie

$limit_rate

$request_body_file

$request_method

$remote_addr

location

语法:location [=||*|^~] /uri/ { … } 默认:否

上下文:server

这个指令随URL不同而接受不同的结构。你可以配置使用常规字符串和正则表达式。如果使用正则表达式，你必须使用 ~* 前缀选择不区分大小写的匹配或者 ~ 选择区分大小写的匹配。

确定 哪个location 指令匹配一个特定指令，常规字符串第一个测试。常规字符串匹配请求的开始部分并且区分大小写，最明确的匹配将会被使用（查看下文明白 nginx 怎么确定它）。然后正则表达式按照配置文件里的顺序测试。找到第一个比配的正则表达式将停止搜索。如果没有找到匹配的正则表达式，使用常规字符串的结果。

有两个方法修改这个行为。第一个方法是使用 “=”前缀，将只执行严格匹配。如果这个查询匹配，那么将停止搜索并立即处理这个请求。例子：如果经常发生”/”请求，那么使用 “location = /” 将加速处理这个请求。

第二个是使用 ^~ 前缀。如果把这个前缀用于一个常规字符串那么告诉nginx 如果路径匹配那么不测试正则表达式。

而且它重要在于 NGINX 做比较没有 URL 编码，所以如果你有一个 URL 链接’/images/%20/test’ , 那么使用 “images/ /test” 限定location。

总结，指令按下列顺序被接受:

1. = 前缀的指令严格匹配这个查询。如果找到，停止搜索。
2. 剩下的常规字符串，长的在前。如果这个匹配使用 ^~ 前缀，搜索停止。
3. 正则表达式，按配置文件里的顺序。
4. 如果第三步产生匹配，则使用这个结果。否则使用第二步的匹配结果。

例子：

location = / { # 只匹配 / 查询。 [ configuration A ] }

location / { # 匹配任何查询，因为所有请求都已 / 开头。但是正则表达式规则和长的块规则将被优先和查询匹配。 [ configuration B ] }

为了安全起见,我们一般会对上传目录禁止运行php脚本

在 apache 下面我们可以通过：

php_flag engine off

的方式来来禁用目录下文件php执行权限。

那么在 nginx 里面同样可以实现这种方法，那就是location的优先匹配，关于location可以参考我之前的一批文章http://226617.cn/archives/392.htm

这里简单就举个例子

location ^~ /attachments/

{

access_log  off;

}

这样 attachments这个目录 就不会再去跳转给fastcgi去执行php了.这里利用了nginx下location指令的处理顺序优先级特点.

但上面的方法只能算一种技巧,一般不这样设置,正确的方法为:

location /upload/ {

location ~  .*.(php)?$

{

deny all;

}

}

而对于多个目录的话,可以一起进行限定:

location ~* ^/(attachments|images)/.*.(php|php5)$

{

deny all;

}

注意这段secion一定要放在 指定的php　section的前面才可以生效的．

location ~ .php$ { fastcgi_pass   127.0.0.1:9000; fastcgi_index  index.php; fastcgi_param  SCRIPT_FILENAME  /data/wwwroot/www$fastcgi_script_name; include        fastcgi_params; }

在大容量，高负荷的web系统中，对数据库进行一系列拆分，可有效提升数据库容量和性能。在初学程序的早期，程序员通常都喜欢按传统数据库设计模式，设计为单库和单一功能表的结构，这样的结构在数据量和并发量达到一定程度之后，会出现严重性能问题和维护问题。在出现问题的时候才着手进行优化，会非常痛苦，所以应该在系统架设之初就考虑好之后会出现的问题。

目前有些数据库策略是采用单库结构，然后通过同步分发到数台服务器实现读写分离。个人觉得这样的策略非常笨拙，还是想办法将其分隔开来好，否则每台机器的内存都很容易超支。

一般只对数据量比较大的表进行拆分，这应该没有什么异议；还有一种是有可能会进行维护的比较重要的表，比如文章目录表，如果有从其它系统倒数据进来的可能的话，也要拆掉，不然倒数据时一不小心把目录表弄坏了，发现忘了备份，那真是欲哭无泪。

下面来分析一下：

一、时间结构

如果业务系统对时效性较高，比如新闻发布系统的文章表，可以把数据库设计成时间结构，按时间分有几种结构：

1. 平板式

表类似： article_200901 article_200902 article_200903

用年来分还是用月可自定，但用日期的话表就太多了，也没这必要。一般建议是按月分就可以。

这种分法，其难处在于，假设我要列20条数据，结果这三张表里都有2条，那么业务上很有可能要求读三次表。如果时间长了，有几十张表，而每张表是0条，那不就是要读完整个系统的表才行么？另外这个结构，要作分页是比较难实现的。

主键：在这个系统中，主键是13位带毫秒的时间戳，不要用自动编号，否则难以通过主键定位到表，也可以在查询时带上时间，但比较烦琐。

2. 归档式

表类似： article_old article_new

为了解决平板式的缺点，可以采用时间归档式设计，可以看到这个系统只有两张表。一张是旧文章表，一张是新文章表，新文章表放2个月的信息，每天定期把2个月中的最早一天的文章归入旧表中。这样一方面可以解决性能问题，因为一般新闻发布系统读取的都是新的内容，旧的内容读取少；第二可以委婉地解决功能问题，比如平板式所说的问题，在归档式中最多也只需要读2张表就完成了。

归档式的缺点在于旧表容量还是相对比较大，如果业务允许，可对旧表中的超旧内容进行再归档或直接清理掉。

二、版块结构

如果按照文章的所属版块进行拆表，比如新闻、体育版块拆表，一方面可以使每个表数据量分离，另一方面是各版块之间相互影响可降到最低。假如新闻版块的数据表损坏或需要维护，并不会影响到体育版块的正常工作，从而降低了风险。版块结构同时常用于bbs这样的系统。

板块结构也有几种分法：

1. 对应式

对于版块数量不多，而且较为固定的形式，就直接对应就好。比如新闻版块，可以分出新闻的目录表，新闻的文章表等。

news_category news_article sports_category sports_article

可看到每一个版块都对应着一组相同的表结构，好处就是一目了然。在功能上，因为版块之间还是有一些隔阂，所以需要联合查询的需求不多，开发上比时间结构的方式要轻松。

主键：依旧要考虑的，在这个系统中，主键是版块+时间戳，单纯的时间戳或自动编号也能用，查询时要记得带上版块用于定位表。

2. 冷热式

对应式的缺点是，如果版块数量很大而且不确定，那要分出的表数量就太多了。举个例子：百度贴吧，如果按一个词条一个表设计，那得有多少张表呢？

用这样的方式吧。

tieba_汽车 tieba_飞机 tieba_火箭 tieba__unite

这个表汽车、火箭表是属于热门表，定义为新建的版块放在unite表里面，待到其超过一万张主贴的时候才开对应表结构。因为在贴吧这种系统中，冷门版块肯定比热门版块多得多，这些冷门版块通常只有几张帖子，为它们开表也太浪费了；同时热门版块数量和访问量等，又比冷门版块多得多，非常有特点。

unite表还可以扩展成哈希表，利用词条的md5编码，可以分成n张表，我算了一下，md5前一位可分36张表，两位即是1296张表，足够了。

tieba_unite_ab tieba_unite_ac …

三、哈希结构

哈希结构通常用于博客之类的基于用户的场合，在博客这样的系统里有几个特点，1是用户数量非常多，2是每个用户发的文章数量都较少，3是用户发文章不定期，4是每个用户发得不多，但总量仍非常之大。基于这些特点，用以上所说的任何一种分表方式都不合适，一没有固定的时效不宜用时间拆，二用户很多，而且还偏偏都是冷门，所以也不宜用版块（用户）拆。

哈希结构在上面有所提及，既然按每个用户不好直接拆，那就把一群用户归进一个表好了。

blog_aa blog_ab blog_ac …

如上所说，md5取前两位哈希可以达到1296张表，如果觉得不够，那就再加一位，总数可达46656张表，还不够？

表的数量太多，要创建这些表也是挺麻烦的，可以考虑在程序里往数据库insert之前，多执行一句判断表存在与否并创建表的语句，很实用，消耗也并不很大。

主键：依旧要考虑的，在这个系统中，主键是用户ID+时间戳，单纯的时间戳或自动编号也能用，但查询时要记得带上用户名用于定位表。 ** 四、总分结构**

以上的这些结构，根据每个业务系统，能想出的估计还有很多。不过现在互联网业务越来越复杂了，有些时候，单一的拆分法还不能实现需求，需要几种拆分方案一起实施，多管齐下，这时候其中的逻辑会让人绕晕。我就开发过一个系统，仅仅是将哈希结构和时间结构混着一用，觉得逻辑就相当复杂。

所以，除了拆表之外，按最原始的单库单表，再建一个总表，是非常有利的架构。在这个架构中，每次往数据库会写入两倍数据，读取主要依赖拆表提升性能，总表用于实现拆表后难以实现的功能并且用于每天的定时备份；另外总表和分表还相互是一个完整的备份，任何一个分表损坏或数据不正常，都可以从总表中读到正确的数据并恢复，反之亦然。

在总分结构中，让人感到质疑的是总表的性能和可维护性。我的方案是总表可采用相对能保证稳定的一些服务软件和架构，例如oracle，或lvs+pgpool+PostgreSQL，重点保证数据稳定；相对的，分表就用轻量级的mysql，重点在于速度。能够对总分表各采用不同的软件和方案，也是总分结构的一大特点。

总结：

****如何通过拆表来优化系统，最基本的是要按业务需求和特点分析。本文仅仅是提供了几种基本方法，具体工作要先动脑好好想，千万不可乱套，用错了工作量要加十倍噢。

来源：

Linux的硬盘识别:

2.6 kernel以后,linux会将识别到的硬件设备,在/dev/下建立相应的设备文件.如:

sda        表示第1块SCSI硬盘.# V, z   b, }2 F7 u’ |

hda        表示第1块IDE硬盘(即连接在第1个IDE接口的Master口上)

scd0        表示第1个USB光驱.

当添加了新硬盘后,在/dev目录下会有相应的设备文件产生.cciss的硬盘是个例外,它的设备文件在/dev/cciss/目录下.一般使用”fdisk -l”命令可以列出系统中当前连接的硬盘设备和分区信息.新硬盘没有分区信息,则只显示硬盘大小信息.

1.关闭服务器加上新硬盘

2.启动服务器，以root用户登录

3.查看硬盘信息

#fdisk -l

Disk /dev/sda: 146.1 GB, 146163105792 bytes

255 heads, 63 sectors/track, 17769 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot       Start          End       Blocks    Id   System

/dev/sda1    *            1           13       104391    83   Linux

/dev/sda2               14         5112     40957717+   83   Linux

/dev/sda3             5113         5243      1052257+   82   Linux swap /

为什么要从时间维度对页面进行监测？

网站分析 中有一个重要的指标：Bounce rate。定义是当用户在进入你网站的第一个页面后没有点击任何链接就离开了。假设两个用户同时进入网站的第一个页面后，一个什么都没有看就马上离开了，而另一个在阅读了页面上的内容并在Action按钮上忧郁了半天，最后离开了。那么这两个用户在Bounce rate里看起来没有区别。而实际上第二个用户比第一个用户更有可能被转化。而如果两个用户来自不同的渠道，那么第二个渠道相对第一个渠道更有一些价值。

在GA的报告中目前只提供两个时间维度：平均 页面停留时间 和平均 网站停留时间。使用JS事件与_trackPageview函数相配合，我们可以看到网页在时间维度上的表现，并获得更多详细的用户与网站互动的时间数据（被计算在Bounce rate内的非点击行为数据）。

1通过持续时间判断用户行为的有效性

上一篇文章的最后一个策略中提到，可以使用_trackPageview函数与JS的onmouseover事件配合。当用户将鼠标移到某个焦点图或按钮上时进行记录。但有一个问题就是收集到的大部分数据可能是用户无意识的行为（如鼠标划过或无意识的将鼠标停放在某个图标上），这并不能表明用户对这个焦点图或action按钮感兴趣。所以单纯记录这个行为并没有太大意义。

现在我们对这个行为加一个时间的限制。即只有用户在某个我们希望他关注的图片或action按钮上停留足够长的时间后再进行记录。（这样并不能百分百的解决之前的问题，但会大幅度的降低对无意义数据的记录，使数据更有参考性。）

具体操作是我们先编写一段时间控制脚本，然后当条件满足后通过onmouseover事件触发_trackPageview函数记录并发送数据。

时间控制JS代码：

1

2

3

4

5

6

7

8

9

10

1

当用户将鼠标停留在twitter.jpg图片上5秒时，_trackPageview函数记录并发送一次mouse_on_img数据。

2监测页面的加载时间

使用JS的onload事件和_trackPageview函数监测页面加载时间的方法在上一篇文章中已经详细介绍过了。这里说一下对收集到数据的分析。

通过GA的数据透视表功能，可以对页面加载时间按网络接入方式和所在地区两个维度进行细分。详细了解某一个地区的某种网络接入方式的页面显示速度。

3页面加载后持续时间监测

页面加载后持续时间的监测和通过持续时间判断用户行为的有效性的方法大致相同。编写一段时间控制JS代码，当onload事件被触发一段时间后通过_trackPageview函数记录并发送一个数据。

时间控制JS代码：

1

当页面完成加载10秒后，_trackPageview函数记录并发送一次loaded10seconds数据。

4用户页面停留时间监测

用户页面停留时间在上一篇文章中已有详细介绍。请点击 这里 查看。

5通过时间维度监测用户的行为

通过时间维度的监测，我们还可以知道用户在进行某个行为前的时间。如用户在打开landing page后到点击Action按钮之间的时间。如果这个时间过长有可能是我们的Action按钮过于隐蔽，又或者是页面文字的激励效果不够好。这时可能就需要对页面的文字表述或Action按钮的位置及大小进行调整了。

最后，一个很有意思的情况是我们虽然通过对时间维度的监测又对Bounce rate里的数据有了更多的了解，但这也完全破坏了原有的Bounce rate数据。所以，还是要根据目标和实际情况进行取舍才能获得更有价值的数据。

——【所有文章及图片版权归 蓝鲸（王彦平）所有。欢迎转载，但请注明转自“ 蓝鲸网站分析博客”。】——

根据OSI模型把网络通信的工作分为七层.一至四层被认为是低层,这些层与数据移动密切相关.五至七层是高层,包含应用程序级的数据.每一层负责一项具体的工作,然后把数据传送到下一层.由低到高具体分为:物理层.数据链路层,网络层,传输层,会话层,表示层和应用层.

OSI模型的最低层或第一层:物理层

物理层包含物理连网网媒介,实际上就是布线,光纤,网卡和其它用来把两台网络通信设备连接在一起的设施.它规定了激活,维持,关闭通信端之间的机械特性,电气特性,功能特性及过程特性.虽然物理层不提供纠错服务,但它能够设定数据传输速率并监测数据出错率.

OSI模型的第二层:数据链路层

数据链路层的主要作用是控制网络层与物理层之间的通信.它保证了数据在不可靠的物理线路上进行可靠的传递.它把从网络层接收到的数据侵害成特定的可被牧师层传输的帧,保证了传输的可靠性.它的主要作用包括:物理地址寻址,数据的成帧,流量控制,数据的栓错,重发等.它是独立于网络层和物理层的,工作时无须关心计算机是否在运行软件还是其它操作. 数据链路层协议主要有:SDLC,DHLC,PPP,STP,帧中继等.

OSI模型的第三层:网络层

很多用户经常混淆第二层和第三层的界限,简单来说,如果你在谈论一个与IP地址,,路由协议或者地址解析协议)ARP)相关的问题,那么这就是第三层的问题.

网络层负责对子网间的数据包进行路由选择,它通过综合考虑发磅仁德权,网络拥塞程度,服务质量及可选路由的花费来决定一个网络中两个节点的最佳路径.另外,它还可以实现拥塞控制,网际互联等功能.

网络层协议有:IP,IPX,RIP,OSPF等.

OSI模型第四层:传输层

传输层是OSI模型中最重要的一层,它是两台计算机经过网络进行数据通信时,第一个端到端的层次,起到缓冲作用.当网络层的服务质量不能满足要求时,它将提高服务,以满足高层的要求;而当风纪支服务质量较好时,它只段进行很少的工作.另外,它还要处理到的差错控制和流量控制等问题,最终为会话提供可靠的,无误的传输.

传输层协议主要有:TCP,UDP,SPX等.

在IP协议栈中第四层是TCP(传输控制协议)和UDP(用户数据报协议)所在的协议层.TCP和UDP包含端口号,它可以唯一区分每个数据包追念哪些应用协议((如HTTP,TCP,TELNET等).TCP/UDP端口号提供的附加信息可以为网络交换机所利用,四层交换机利用这种信息来区分包中的数据,这是第四层交换的基础.

OSI模型第五层:会话层

会话层负责在网络中两节点之间建立和维持通信,并保持会话同步,它还决定通信是否中断,以级通信中断时决定从何处重新发送.

OSI模型的第六层:表示层

表示层的作用是管理数据的解密与加密,如常见的系统口令处理,当您的账户数据在发送前被加密,在网络的另一端,表示层将对接收到的数据解密.另外表示层还要对图片和文件格式信息进行解码和编码.

OSI模型第七层:应用层

简单来说,应用层就是为操作系统或者网络应用程序提供访问网络服务接口,包括文件传输,文件管理及电子邮件等的信息处理.

应用层协议有:TELNET FTP HTTP SNMP等.

负载均衡产品有:

工作在第四层产品有:LVS

工作在第七层的产品有:

软件的七层负载均衡大多基于HTTP反向代理方式,代表产品有nginx, l7sw(layer swiithing), haproxy等.

nginx的反向代理负载均衡能够很好地支持虚拟主机,可配置性很强,可以按轮询,IP哈希,URL哈希,权重等多种方式对后端服务器做负载均衡,同时还支持后端服务器的健康检查.对于使用nginx的负载均衡实例见: http://blog.haohtml.com/archives/6573

Nginx中upstream有以下几种方式：

1、轮询(weight=1) 默认选项，当weight不指定时，各服务器weight相同， 每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。

[shell]upstream bakend { server 192.168.1.10; server 192.168.1.11; } [/shell]

2、weight 指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。 如果后端服务器down掉，能自动剔除。 比如下面配置，则1.11服务器的访问量为1.10服务器的两倍。

[shell]upstream bakend { server 192.168.1.10 weight=1; server 192.168.1.11 weight=2; }[/shell]

3、ip_hash 每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session不能跨服务器的问题。 如果后端服务器down掉，要手工down掉。

[shell]upstream resinserver{ ip_hash; server 192.168.1.10:8080; server 192.168.1.11:8080; }[/shell]

4、fair（第三方插件） 按后端服务器的响应时间来分配请求，响应时间短的优先分配。

[shell]upstream resinserver{ server 192.168.1.10:8080; server 192.168.1.11:8080; fair; }[/shell]

5、url_hash（第三方插件） 按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存服务器时比较有效。 在upstream中加入hash语句，hash_method是使用的hash算法

[shell]upstream resinserver{ server 192.168.1.10:8080; server 192.168.1.11:8080; hash $request_uri; hash_method crc32; }[/shell]

设备的状态有: 1.down 表示单前的server暂时不参与负载 2.weight 权重,默认为1。 weight越大，负载的权重就越大。 3.max_fails 允许请求失败的次数默认为1。当超过最大次数时，返回proxy_next_upstream 模块定义的错误 4.fail_timeout max_fails次失败后，暂停的时间。 5.backup 备用服务器, 其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。-

shell中可能经常能看到：>/dev/null 2>&1

命令的结果可以通过%>的形式来定义输出

/dev/null 代表空设备文件

代表重定向到哪里，例如：echo “123” > /home/123.txt 1 表示stdout标准输出，系统默认值是1，所以”>/dev/null”等同于”1>/dev/null” 2 表示stderr标准错误 & 表示等同于的意思，2>&1，表示2的输出重定向等同于1

那么本文标题的语句： 1>/dev/null 首先表示标准输出重定向到空设备文件，也就是不输出任何信息到终端，说白了就是不显示任何信息。 2>&1 接着，标准错误输出重定向等同于标准输出，因为之前标准输出已经重定向到了空设备文件，所以标准错误输出也重定向到空设备文件。

另一篇相关文章:

(1) autoload机制概述

在使用PHP的OO模式开发系统时，通常大家习惯上将每个类的实现都存放在一个单独的文件里，这样会很容易实现对类进行复用，同时将来维护时也很便利。这也是OO设计的基本思想之一。在PHP5之前，如果需要使用一个类，只需要直接使用include/require将其包含进来即可。下面是一个实际的例子：

/* Person.class.php */

class Person {

var $name, $age;

function __construct ($name, $age)

{

$this->name = $name;

$this->age = $age;

}

}

?>

/* no_autoload.php */

require_once (”Person.class.php”);

$person = new Person(”Altair”, 6);

var_dump ($person);

?>

在这个例子中，no-autoload.php文件需要使用Person类，它使用了require_once将其包含，然后就可以直接使用Person类来实例化一个对象。

但随着项目规模的不断扩大，使用这种方式会带来一些隐含的问题：如果一个PHP文件需要使用很多其它类，那么就需要很多的require/include语句，这样有可能会造成遗漏或者包含进不必要的类文件。如果大量的文件都需要使用其它的类，那么要保证每个文件都包含正确的类文件肯定是一个噩梦。

PHP5为这个问题提供了一个解决方案，这就是类的自动装载(autoload)机制。autoload机制可以使得PHP程序有可能在使用类时才自动包含类文件，而不是一开始就将所有的类文件include进来，这种机制也称为lazy loading。

下面是使用autoload机制加载Person类的例子：

/* autoload.php */

function __autoload($classname) {

require_once ($classname . “class.php”);

}

$person = new Person(”Altair”, 6);

　大多人浏览网页如果超过3秒打不开就会离开,Google为此推出了一款Apache加速模块：mod_pagespeed，该模块可以有效将网页加载速度提高50%。网页提速的问题是一个复杂多样的问题，有很多解决方法,往往关系到网站系统程序，服务器硬件，网络传输速度等方面，而Google这款加速模块简单的解决了许多复情况的问题：

　　◆如果你的网站采用Apache构建服务器，不需要对网站CMS系统进行处理即可应用;

　　◆加速模块可以自行对网络传输的HTML字节优化及对图象,CSS进入压缩优化传输;

　　◆智能缓存是一大亮点，它可以自动智能缓存,加速下载。

　　下面介绍一下所有特点功能：

　　◆优化缓存

　　◆缓存扩展

　　◆压缩处理CSS

　　◆优化JavaScript最大限度的减少重复请求

　　◆自动缓存CSS

　　◆JavaScript内嵌技术

　　◆有效载荷尺寸最小化

　　◆压缩空白

　　◆合并头信息

　　◆附加属性

　　◆内建核心JavaScript

　　◆优化图像下载

　　◆跳地非法字符

　　◆重写优化CSS

　　Google官方文档说明： http://code.google.com/intl/zh-CN/speed/page-speed/docs/module.html

　　Google官方下载地址： http://code.google.com/intl/zh-CN/speed/page-speed/download.html

概述

利用FreeBSD内核支持的BRIDGE、IPFIREWALL以及DUMMYNET选项，可以建立基于FreeBSD的透明流量控制防火墙（桥接模式），起到限制流量和包过滤的功能。

准备

可以在任何FreeBSD的兼容硬件上构建流量控制防火墙，但是基于性能和管理上的考虑，建议：

使用Intel PII450以上的处理器

使用至少128MB RAM

使用高性能10/100Mbps自适应网络适配器

如果多于一组桥接设备，建议使用双处理器系统

另外准备一块单独的网络适配器用于管理

——————————————————————————–

实例

联想万全1300 PC服务器，具有一颗Intel PII300处理器，配置有128MB RAM，主板集成Intel 82557网络适配器，另外安装了4块3Com 3C905B 10/100Mbps自适应PCI网络适配器。

——————————————————————————–

安装

安装最新版本的FreeBSD。可以从www.FreeBSD.org获取当前的FreeBSD版本信息，并且获得安装源文件。可以使用光盘安装和FTP安装方式。为了保证最好的硬件兼容性，请使用FreeBSD 4.3 RELEASE或者更高的版本。

必须安装操作系统源代码中的”sys”部分，安装完成以后需要重新编译系统内核以支持必要的流量控制防火墙选项。

——————————————————————————–

实例

安装FreeBSD-4.3-20010818-STABLE版本，从 ftp://releng4.freebsd.org/pub/FreeBSD/snapshots/i386/

获得。使用FTP安装方式，安装选项为：

[X] bin

[X] crypto

[X] man

[X] src->sys

——————————————————————————–

配置

完成操作系统安装以后，必须重新编译系统内核使其支持桥接流量控制防火墙选项。必须在系统内核编译配置文件中添加以下内容：

options BRIDGE

options DUMMYNET

options IPFIREWALL

options IPFIREWALL_DEFAULT_TO_ACCEPT

重新编译完系统内核以后必须重新启动计算机。

——————————————————————————–

实例

# cd /usr/src/sys/i386/conf

# cp GENERIC BRGFW

# echo “options BRIDGE” » BRGFW

# echo “options DUMMYNET” » BRGFW

int a[10];

int * p;

C语言规定数组名代表数组中第一个元素(即序号为0的元素)的地址,因此,下面两个语句等价:

p = &a[0];

p = a;

摘自：C语言程序设计(第二版)p211

（5）指针变量的值是可以改变的，见下例。

例10.20　改变指针变量的值。

#include <stdio.h>
void main()
{
char *a = "I love China!":
a = a + 7;
printf("%s", a);
}

运行结果如下：

China!

指针变量a的值是可以变化的，输出字符串是地从a当时所指向的单元开始输出各个字符，起码到遇’\0’为止。而数组名虽然代表地址，但它是常量，它的值是不能改变的。下面的用法是错误的：

char str[] = {“I love China!”};

str = str + 7;

printf(“%s”, str);

需要说明，若定义了一个指针变量， 并使它指向一个字符串，就可以用下标形式引用指针变量所指的字符串中的字符。

例10.21　用带下标的字符指针变量引用字符串中的字符：

#include <stdio.h>
void main()
{
char *a = "I love China!";
int i;
printf("The sixth character is %C\n", a[5] );
for(i=0; a[i] != '\0'; i++)
printf(%c" a[i]);

printf("\n");
}

运行结果如下：

又拍网是一个照片分享社区，从2005年6月至今积累了260万用户，1.1亿张照片，目前的日访问量为200多万。5年的发展历程里经历过许多起伏，也积累了一些经验，在这篇文章里，我要介绍一些我们在技术上的积累。

又拍网和大多数Web2.0站点一样，构建于大量开源软件之上，包括MySQL、PHP、nginx、Python、memcached、redis、Solr、Hadoop和RabbitMQ等等。又拍网的服务器端开发语言主要是PHP和Python，其中PHP用于编写Web逻辑（通过HTTP和用户直接打交道）， 而Python则主要用于开发内部服务和后台任务。在客户端则使用了大量的Javascript， 这里要感谢一下MooTools这个JS框架，它使得我们很享受前端开发过程。 另外，我们把图片处理过程从PHP进程里独立出来变成一个服务。这个服务基于nginx，但是是作为nginx的一个模块而开放REST API。

**图1：**开发语言

由于

PHP的单线程模型，我们把耗时较久的运算和I/O操作从HTTP请求周期中分离出来， 交给由Python实现的任务进程来完成，以保证请求响应速度。这些任务主要包括：邮件发送、数据索引、数据聚合和好友动态推送（稍候会有介绍）等等。通常这些任务由用户触发，并且，用户的一个行为可能会触发多种任务的执行。 比如，用户上传了一张新的照片，我们需要更新索引，也需要向他的朋友推送一条新的动态。PHP通过消息队列（我们用的是RabbitMQ）来触发任务执行。

**图2：**PHP和Python的协作

数据库一向是网站架构中最具挑战性的，瓶颈通常出现在这里。又拍网的照片数据量很大，数据库也几度出现严重的压力问题。 因此，这里我主要介绍一下又拍网在分库设计这方面的一些尝试。

分库设计

和很多使用MySQL的2.0站点一样，又拍网的MySQL集群经历了从最初的一个主库一个从库、到一个主库多个从库、 然后到多个主库多个从库的一个发展过程。

最初是由一台主库和一台从库组成，当时从库只用作备份和容灾，当主库出现故障时，从库就手动变成主库，一般情况下，从库不作读写操作（同步除外）。随着压力的增加，我们加上了memcached，当时只用其缓存单行数据。 但是，单行数据的缓存并不能很好地解决压力问题，因为单行数据的查询通常很快。所以我们把一些实时性要求不高的Query放到从库去执行。后面又通过添加多个从库来分流查询压力，不过随着数据量的增加，主库的写压力也越来越大。

在参考了一些相关产品和其它网站的做法后，我们决定进行数据库拆分。也就是将数据存放到不同的数据库服务器中，一般可以按两个纬度来拆分数据:

垂直拆分**:是指按功能模块拆分，比如可以将群组相关表和照片相关表存放在不同的数据库中，这种方式多个数据库之间的表结构不同**。

水平拆分**:而水平拆分是将同一个表的数据进行分块保存到不同的数据库中，这些数据库中的表结构完全相同**。

拆分方式

一般都会先进行垂直拆分，因为这种方式拆分方式实现起来比较简单，根据表名访问不同的数据库就可以了。但是垂直拆分方式并不能彻底解决所有压力问题，另外，也要看应用类型是否合适这种拆分方式。如果合适的话，也能很好的起到分散数据库压力的作用。比如对于豆瓣我觉得比较适合采用垂直拆分， 因为豆瓣的各核心业务/模块（书籍、电影、音乐）相对独立，数据的增加速度也比较平稳。不同的是，又拍网的核心业务对象是用户上传的照片，而照片数据的增加速度随着用户量的增加越来越快。压力基本上都在照片表上，显然垂直拆分并不能从根本上解决我们的问题，所以，我们采用水平拆分的方式。

拆分规则

水平拆分实现起来相对复杂，我们要先确定一个拆分规则，也就是按什么条件将数据进行切分。 一般2.0网站都以用户为中心，数据基本都跟随用户，比如用户的照片、朋友和评论等等。因此一个比较自然的选择是根据用户来切分。每个用户都对应一个数据库，访问某个用户的数据时， 我们要先确定他/她所对应的数据库，然后连接到该数据库进行实际的数据读写。

那么，怎么样对应用户和数据库呢？我们有这些选择：

按算法对应

最简单的算法是按用户ID的奇偶性来对应，将奇数ID的用户对应到数据库A，而偶数ID的用户则对应到数据库B。这个方法的最大问题是，只能分成两个库。另一个算法是按用户ID所在区间对应，比如ID在0-10000之间的用户对应到数据库A， ID在10000-20000这个范围的对应到数据库B，以此类推。按算法分实现起来比较方便，也比较高效，但是不能满足后续的伸缩性要求，如果需要增加数据库节点，必需调整算法或移动很大的数据集， 比较难做到在不停止服务的前提下进行扩充数据库节点。

按索引**/**映射表对应

这种方法是指建立一个索引表，保存每个用户的ID和数据库ID的对应关系，每次读写用户数据时先从这个表获取对应数据库。新用户注册后，在所有可用的数据库中随机挑选一个为其建立索引。这种方法比较灵活，有很好的伸缩性。一个缺点是增加了一次数据库访问，所以性能上没有按算法对应好。

比较之后，我们采用的是索引表的方式，我们愿意为其灵活性损失一些性能，更何况我们还有memcached， 因为索引数据基本不会改变的缘故，缓存命中率非常高。所以能很大程度上减少了性能损失。

**图4：**数据访问过程

索引表的方式能够比较方便地添加数据库节点，在增加节点时，只要将其添加到可用数据库列表里即可。 当然如果需要平衡各个节点的压力的话，还是需要进行数据的迁移，但是这个时候的迁移是少量的，可以逐步进行。要迁移用户A的数据，首先要将其状态置为迁移数据中，这个状态的用户不能进行写操作，并在页面上进行提示。 然后将用户A的数据全部复制到新增加的节点上后，更新映射表，然后将用户A的状态置为正常，最后将原来对应的数据库上的数据删除。这个过程通常会在临晨进行，所以，所以很少会有用户碰到迁移数据中的情况。

当然，有些数据是不属于某个用户的，比如系统消息、配置等等，我们把这些数据保存在一个全局库中。

问题

分库会给你在应用的开发和部署上都带来很多麻烦。

不能执行跨库的关联查询

如果我们需要查询的数据分布于不同的数据库，我们没办法通过JOIN的方式查询获得。比如要获得好友的最新照片，你不能保证所有好友的数据都在同一个数据库里。一个解决办法是通过多次查询，再进行聚合的方式。我们需要尽量避免类似的需求。有些需求可以通过保存多份数据来解决，比如User-A和User-B的数据库分别是DB-1和DB-2， 当User-A评论了User-B的照片时，我们会同时在DB-1和DB-2中保存这条评论信息，我们首先在DB-2中的photo_comments表中插入一条新的记录，然后在DB-1中的user_comments表中插入一条新的记录。这两个表的结构如下图所示。这样我们可以通过查询photo_comments表得到User-B的某张照片的所有评论， 也可以通过查询user_comments表获得User-A的所有评论。另外可以考虑使用全文检索工具来解决某些需求， 我们使用Solr来提供全站标签检索和照片搜索服务。

**图5：**评论表结构

不能保证数据的一致**/**完整性

跨库的数据没有外键约束，也没有事务保证。比如上面的评论照片的例子， 很可能出现成功插入photo_comments表，但是插入user_comments表时却出错了。一个办法是在两个库上都开启事务，然后先插入photo_comments，再插入user_comments， 然后提交两个事务。这个办法也不能完全保证这个操作的原子性。

所有查询必须提供数据库线索

比如要查看一张照片，仅凭一个照片ID是不够的，还必须提供上传这张照片的用户的ID（也就是数据库线索），才能找到它实际的存放位置。因此，我们必须重新设计很多URL地址，而有些老的地址我们又必须保证其仍然有效。我们把照片地址改成/photos/{username}/{photo_id}/的形式，然后对于系统升级前上传的照片ID， 我们又增加一张映射表，保存photo_id和user_id的对应关系。当访问老的照片地址时，我们通过查询这张表获得用户信息, 然后再重定向到新的地址。

自增****ID

如果要在节点数据库上使用自增字段，那么我们就不能保证全局唯一。这倒不是很严重的问题，但是当节点之间的数据发生关系时，就会使得问题变得比较麻烦。我们可以再来看看上面提到的评论的例子。如果photo_comments表中的comment_id的自增字段，当我们在DB-2.photo_comments表插入新的评论时， 得到一个新的comment_id，假如值为101，而User-A的ID为1，那么我们还需要在DB-1.user_comments表中插入(1, 101 …)。 User-A是个很活跃的用户，他又评论了User-C的照片，而User-C的数据库是DB-3。 很巧的是这条新评论的ID也是101，这种情况很用可能发生。那么我们又在DB-1.user_comments表中插入一行像这样(1, 101 …)的数据。 那么我们要怎么设置user_comments表的主键呢（标识一行数据）？可以不设啊，不幸的是有的时候（框架、缓存等原因）必需设置。那么可以以user_id、 comment_id和photo_id为组合主键，但是photo_id也有可能一样（的确很巧）。看来只能再加上photo_owner_id了， 但是这个结果又让我们实在有点无法接受，太复杂的组合键在写入时会带来一定的性能影响，这样的自然键看起来也很不自然。所以，我们放弃了在节点上使用自增字段，想办法让这些ID变成全局唯一。为此增加了一个专门用来生成ID的数据库，这个库中的表结构都很简单，只有一个自增字段id。 当我们要插入新的评论时，我们先在ID库的photo_comments表里插入一条空的记录，以获得一个唯一的评论ID。 当然这些逻辑都已经封装在我们的框架里了，对于开发人员是透明的。 为什么不用其它方案呢，比如一些支持incr操作的Key-Value数据库。我们还是比较放心把数据放在MySQL里。 另外，我们会定期清理ID库的数据，以保证获取新ID的效率。