linux运维趋势第16期 cdn缓存系统

002

《Linux 运维趋势》投稿信箱 : [email protected]

杂志订阅 : http://os.51cto.com/art/201011/233915.htm

51CTO 系统频道：http://os.51cto.com

目录Index

002

目录

人物·People

003 Theo Schlossnagle谈监控，统计学与运维的本质

交流·Interact

007 服务器虚拟化：如何选择合适的模式？

八卦·News

009 Hash冲突漏洞需修补 12306.cn引热议

专题·Special

011 web网站加速之CDN技术原理

014 大型网站后台架构的web server与缓存

016 Squid常用命令总结

018 [CDN]动态内容的缓存技术 CSI,SSI,ESI

019 squid/varnish/ats简单测试

020 使用Nginx代替squid充当代理缓存服务器

技巧·工具·脚本·DBA

023 MySQL性能优化教程之MySQL运维优化

026 建设一个靠谱的火车票网上订购系统

029 红帽虚拟桌面SPICE服务概述与安装指南

031 为什么要尽量避免重启你的Unix服务器

出版方：51CTO 系统频道（北京无忧创想信息技术有限公司）

杂志主编：杨赛

联系方法：[email protected] 010-68476606（分机 8035）

出版日期：2012 年 1 月 13 日

每月第 2 个星期五出版

订阅：http://os.51cto.com/art/201011/233915.htm

mailto:[email protected]

http://os.51cto.com/art/201011/233915.htm

http://os.51cto.com

http://os.51cto.com

mailto:yangsai%4051cto.com?subject=%E3%80%8ALinux%E8%BF%90%E7%BB%B4%E8%B6%8B%E5%8A%BF%E3%80%8B%E6%8A%95%E7%A8%BF%EF%BC%9A


003




人物People

003

Theo Schlossnagle谈监控，统计学与运维的本质

Theo Schlossnagle 是 OmniTI 的创始人和首脑，为高流量网站和其他

需要可靠、可扩展架构工程的客户设计和实施解决方案。他是高可扩展

的 Momentum MTA 架构师，Fontdeck CDN 的架构师，Circonus SaaS 监

控平台背后的导师。Theo 参与很多开源社区，包括 OpenSolaris，Linux，

Apache，PostgreSQL，perl 等等。他是可扩展系统和分布式系统方面的作家，

也是开源会议上的资深讲师。

51CTO 在 2011 年底的 Velocity 大会上对 Theo 进行了专访，探讨了运维

工程师成长方面的问题。

51CTO ：您在有关监控的课程中讲了很多统计学的内容。您认为 DBA 和

运维们需要了解这些知识吗？

Theo ：我认为对于工程师而言，了解基础程度的统计学是一项基本要求。

因为我们每天都在关注系统的各项数据：硬盘是不是慢了？网络是不是慢

了？我们将“太慢”这个概念量化成具体的数值，从而理解这个系统。如果

我们每天看这些数字，而没有统计学的基本知识，那就说不上真正理解这些

数字。

51CTO ：像是 Nagios 和 Cacti 这样的工具目前做到这一点了吗？

Theo ：算不上吧。Nagios 做的仅限于提供一些数字——目前大部分系统

都是这样做的，它们被设计隔一段时间做一次检查，比如每隔一分钟做点什

采访整理/lazycai



http://os.51cto.com

004




人物People

004

么动作，返回一个数字。而现实中，我

们面对的很多行为，好比硬盘读写的行

为，它往往在每一秒内会执行成百上千

次，所以如果我们能够仔细研究每一次

读写的实际行为，通过这样对硬盘读写

的理解，肯定要远远超过只是取一个每分钟的平均数。你想要了解最高值

是什么，最低值是什么，你想要了解一个分布的情况，98% 或者 99% 的读

写速度在一个什么值，如此这般。这个我认为是我们需要的。

Cacti 相对好一些，它目前提供了一些基本的统计功能，你可以查看数据

的标准偏差，但是其他的相关数据还很有限。

51CTO ：那么你们在 OmniTI 用的监控系统，是完全自己写的，不是通过其

他监控系统修改的是吗？

Theo ：是的，我们完全自己写的整个监控系统。这个系统是开源的，而且

监控数据写入数据库，你可以直接用来做统计分析，或者像很多专业数据分

析人士做得一样，将数据抽取出来，放到比如 R 这样专业的统计工具当中

去。用 R 来做统计相对高阶一些，但是很多时候我们通过借助手册的帮助，

也可以很容易的做一些基本的分析。

比如你在网站上放了 JavaScript 监控代码，它能够返回每次页面加载花

费的时间。假设它放在那里跑了一天之后，收集到 1 亿次用户点击，也就是

1 亿个 PV。你想知道的情况是，页面加载的速度如何。如果给你一个 1 亿

次页面加载时间的平均数，这个肯定是没啥用的；你想知道的是分布的情

况，有多少次访问在 1 秒，有多少次访问在 10 秒，等等。这样就会收集到很

多数据点，你需要一个视图的方式明白的呈现出来这些数据代表了什么意

思，那么这时候就可以用 R 语言。当然做这个也有其他的工具，但是 R 是最

简单、最便宜的。

51CTO ：运维工程师的工作，一直以来

都无非是部署、监控、安全、备份、排障、

调优这些。您认为这方面的工作在未来

会有变化吗？

Theo ：我认为这些工作不会有太大的变化，只不过是有些工作变得越来

越简单了。备份数据，部署新的系统，我觉得这些方面的技术已经越来越好，

越来越容易做。咱们每天工作按 8小时来算，以前你可能花 6个小时在分发、

打包、部署、备份这些工作上面，而现在你可能只需要 1 个小时了。这样下

来，你就有更多时间考虑性能优化、资源规划这些事情——你以前在这些事

情上可能只有 1 小时的时间，但它实际上值得你花每天 8 小时。

“以前你可能花6个小时在分发、打包、部署、

备份上面，而现在你可能只需要1个小时了。”



http://os.51cto.com

005




人物People

005

51CTO ：那您认为运维工程师这样的

技术人员应该多花时间去了解业务吗？

Theo ：哦，当然需要了。当然，他们不

需要了解所有的业务；不过他们至少需

要知道，自己管理的这些机器为什么在运转？我自己见过这样的事情：有

一个系统在运行了好几年之后，才发现这个系统早就没有人在用了。那是

一个数据仓库的业务。最开始你有一个数据库，以及一个数据仓库。后来，

又启动了一个新的数据仓库。所有用户从旧的数据仓库迁移到了一个新的

数据仓库，但是居然没有任何人通知系统管理员！所以旧的系统还一直在

跑着，磁盘阵列跑着，耗费着电力，还有一堆之前设计的自动化脚本在运转。

系统管理员一直也没去看这个系统，以为还有人在用；而业务方面的人则

没有一个想起来要把旧的系统关掉。

51CTO ：难道系统管理员不会觉得奇怪吗？比如发现一直没有用户请求之

类的。

Theo ：哦，这个系统很久以前就没有用户提需求的，因为都完全自动化

了。在一个数据仓库系统里面处理的任务可能是将每天的销售数据打包存

档，发邮件到某人的邮箱里面去。换了新系统之后，可能由于某种原因，也

一直没人去检查那个旧的邮箱，所以就这么一直跑着了。

还有另外一种情况，比如带宽的使用。你购买了一定的带宽，但实际上

未必需要用到那么多，不少企业对于这其中的成本浪费并不是特别明白。

还有另一个例子：我们有一个客户，他们的首页一开始不用缓存，因为页

面是动态显示数据的，客户说必须要让页面随时显示最新的数据，比如最热

卖的产品之类的。因为客户坚持不用缓存，最初我们在架构设计中只好为

这个首页安排了 60 台机器。每次在软件工程师提出要为页面做缓存的时

候，客户就大摇其头的否决：“不行不行，我们必须要显示最新的数据，不能

让首页显示老的数据”。最后一个 SA

实在受不了了，问道：“显示最新数据的

商业理由究竟是什么？难道 1 秒之前

的数据都不行吗？”客户反馈说：“这个

啊，1 秒钟当然是可以的啦。”所以最后，

60 台机器优化成了一台。

所以我觉得很多时候，是人们之间没有沟通清楚。我们没有真正明白，

究竟为什么要跑这个应用软件。客户丢过来一个问题，我们就埋头解决这

个问题，启动机器，然后看到没人抱怨，我们就当作没问题了——这其中其

实是很有问题的。

对于运维这个领域我一直是这样理解的：运维（Operations）的本质是让

业务跑起来，而不是让系统或是一堆计算机跑起来，所以身为运维，必须要

去了解业务。如果他们不去了解业务，那么他们就不会明白如何让业务最

优化的运行。在现实中，整个需求的传递往往是一条长链：业务需求传递

给产品经理，产品经理传递给软件工程师，软件工程师再传递给系统管理

员……而到了这里，可能我们早就不知道真实的需求到底是什么了。我认

为就是应该将最原始的需求拿出来，大家在一起讨论比较好。

51CTO ：您的意思是我们要尽量减少这些中间人的存在吗？让用户的需求

直接传达给实际干活儿的人？

Theo ：我认为这是一个平衡的问题。在优秀的公司当中，整个链条是存

在的，我们有产品经理，有专注交互的，有专注界面的，还有底层这些。我想

说的是，从一开始，我们就需要来自软件工程师、系统管理员和 DBA 们的参

与，让他们参与“定义问题”的过程。大家聚在一个屋子里面各抒己见，才

能够更好的理解各自的观点。

“所以我觉得很多时候，是人们之间没有沟通

清楚。”

006




人物People

006

51CTO ：您在早上提到了运维的职业

发展需要向“多面化”的方向走，那您认

为以后这个领域仍然会按照系统管理

员、运维、DBA 这些职业进行划分吗？

Theo ：哦，职业细分这方面肯定还是不会变的。你很难在每个方面都成

为专家的。所谓多面化的意思是这样的：在规模很大的公司里，尤其是在对

性能优化非常关注的互联网公司，比如淘宝这样为这么多用户提供服务的

网站，他们遇到的问题都是很难解决的问题，他们会需要对各方面都熟悉的

人才。因为在一屋子的人都是较窄领域的专家的时候，他们很难去“越界”

的处理问题，因为缺乏在其他领域的能力。好比你遇到一个数据库的问题，

而这个问题如果你对数据库下面的操作系统有一定了解的话，可能会很容

易就发现问题所在了。

51CTO ：那好比 OmniTI 招聘的话，你会期待一个什么样的工程师？

Theo ：这个问题真难……我们的话，首先会要求对方有很好的分析能力，

能够按照严格的科学方法去发现问题，然后解决问题。你知道，有太多的人

会在还没了解问题的时候就急急忙忙的跑去解决问题。我面试过的很多人，

他们之所以没有拿到这份工作正是因为这个原因。我会问他们一个问题，

比如“我们的网站很慢。你要怎么做？”而他们没有提出足够多的问题，而

是直接开始说“我会这样这样做”等等。他们根本连问题是什么样子的都

没搞明白。而相比之下，那些更善于挖掘问题的应聘者——他们往往是相

对不那么聪明的一群人——往往能够给出更好的答案。

这是方法方面。第二就是，这个人必须愿意学习。这样的人真的非常难

找！

51CTO ：那你们现在也会通过社交网

络等方式来寻找这样的人吗？

Theo ：实话说吧，在招聘方面我们算

不上多成功。我们的员工都非常的优

秀，但是我们招聘的速度实在是跟不上需求。

社交网络方面，我们主要关注代码社区，比如 Github ；传统的 Job List 方

法也在用，招聘网站什么的。反正是什么方法都用呗。

51CTO ：最后一个问题。随着云计算的发展，人们预测外包业务将会越来

越多。这种情况下，您认为系统运维的就业环境是否会变得越来越局限？

Theo ：这个我倒不完全这么认为。现在很多用云计算服务的主要还是小

企业，他们的需求也就在 50 台到 100 台机器上下，在内部系统方面，肯定 IT

管理员是会减少的，因为像是搭建 Exchange 邮件服务或是配置电话交换机

这种工作，放在哪个公司都差不多，外包在这个方向更有优势；但是网站和

Web 应用就不一样了，每一家网站的业务都是不一样的，有定制，有优化，不

太可能交给外包就能直接搞定。你搞电子商务的，把网站外包出去运营能

行吗？我觉得是不行的，因为这样你就失去了你的差异竞争力。

所以我觉得以后会是这样：Exchange 这样的同质化服务会趋向于外包；

小规模的网站会采用相对通用的云服务而不专门聘请一个 SA ；而对于有一

定规模的网站，即使他们的业务是托管在云平台上运行的，他们也仍会需要

一些了解企业业务的 SA——他们了解如何从不同的角度思考，而且会在凌

晨 3 点起来排障。他们可能会跟软件工程师这个岗位融合，但不管职位叫

什么，这些网站仍然需要这样一批人。

51CTO ：好的，十分感谢您接受我们的采访！本次访谈到此结束。

原文：http://os.51cto.com/art/201112/306406.htm

“他们了解如何从不同的角度思考，而且会在

凌晨3点起来排障。”


007




交流Interact

007

服务器虚拟化：如何选择合适的模式？

直连式虚拟化与分布式虚拟化，二者的冲突给意识形态带来了新的战

场。

直连式虚拟化比较简单，就是一台服务器，配备着托管数套虚拟机的本

地存储。它们利用由管理程序提供的 vSwitch 进行互相通信，而无需将数

据包经过网卡发送至网络的每个角落。

讨论

通常情况下，托管在直连方案中的虚拟机能够与处于主机系统之外的服

务器及客户机进行沟通，但大部分交

流仍然发生在同一套系统中的虚拟机

之间。

分布式虚拟化则完全不同。主机

服务器被尽可能当作一套整体的一次

性处理单元。存储资源采用集中式管理方案，并通过 SAN 中虚拟机与物理

交换机之间的通信被提供给多台主机。

每种模式都有各种的局限性。

直连式虚拟化速度快。每块 10Gb 网卡（目前 SAN 的标准接口）在理论

上可以提供最大 1280MBps 的传输速度。而目前相当普遍的 PCIe 8x 2.0

RAID 卡理论上的传输速度更高达 4000MBps。

不过用在实际工作中就没那么乐观了。我在 10Gb 网络附加存储系统上

所能得到的上限速度仅为 900MBps，而我自己的 SSD RAID 10 也只能带来

2200MBps 的实际表现。不过 2200MBps 已经远胜 900MBps，这样的存储速

度优势已经极具价值。如果大家愿意为某台指定的虚拟机搭配多套虚拟网

卡，那么速度还将进一步提升。

困境

当将分布式的非主机设备引入余下的网络中时，这些虚拟机就要争夺有

限的带宽。如果我们有三十套虚拟机系统，那么为它们各自配备 10Gb带宽，

与只拿出一块 10Gb 带宽的网卡让它们共用、由物理交换机负责网络处理是

完全不同的感觉。

如果仅从目前提出的数字出发，那么

分布式虚拟化看起来简直就是疯狂而不

可理喻的。但它仍然具备独特的优势。

直连式虚拟化所无法实现的就是从一台主机上的虚拟机中迅速迁移至

另一台。虚拟机本身可能就体积庞大，因此通过网络实施迁移会耗费大量

时间。

但分布式虚拟化采用了集中式存储模式，不会遇到这个问题。不仅如此，

分布式虚拟化还允许我们对不同主机上处于运行状态的虚拟机系统进行实

时迁移。

高度的可用性是分布式虚拟化的另一大重要卖点。

文/Trevor Pott编译/核子可乐

“如果大家愿意为某台指定的虚拟机搭配多套

虚拟网卡，那么速度还将进一步提升。”



http://os.51cto.com

008




交流Interact

008

直连式虚拟化依靠强劲且具备高度

容错性的虚拟主机来实现优秀的可用

性。分布式虚拟化则会在一台主机出

现故障并重启时将所有虚拟机在集群

中的其它主机上加以运行。使用的主机越多，分布式模式的优势就越明显。

分布式虚拟化的另一大优势是，尽管在传输速度上有所限制，但强制将

所有流量通过物理交换机处理使得网络管理具备更强的直观性及可管理

性。

设计概念

大家可以根据自己的需要选择合适的模式并加以部署，但这似乎还不能

完全令人满意。基于创新的思维方式，混合虚拟化模式开始出现。

新一代网卡已经开始模糊二者之间的界线，其中至关重要的一环是

802.1Qbg 这样的标准（也被称为边缘虚拟桥），或虚拟以太网端口聚合

（VEPA）。

VEPA 网卡自身所具备的能力足以被称为交换机。在使用中，主机上的

虚拟机绕过虚拟交换机，直接与网卡中集成的交换机对话。而网卡则能够

与管理软件直接对话，这样一来我们就既拥有了分布式网络带来的种种优

势，又不必担心由于所有虚拟机流量都被发往物理交换机而引起传输速度

瓶颈。

另一方面，802.1Qbh（也被称为桥口扩展或者 VN 标签）几乎完全是由

思科公司一手打造，它的使用需要对当前以太网规范加以延伸，即采用很多

新的硬件。

这与 VEPA 形成了鲜明的对比，因为 VEPA 并不需要我们更新网络设备。

在同一台主机上通过差异化配置来实现同时使用直连式存储与分布式

存储的作法也开始出现。我最近就完

成了一套部署，其中每台主机都拥有大

量本地存储以辅助备份工作。

每台主机都拥有一套虚拟备份设备

（简称 VBA），其作用是为分配给该主机的虚拟机进行基于镜像的备份，并将

镜像存储于本地缓冲驱动器中。这增加了备份速度。

中央 VBA 会从每台主机上读取备份内容，并不断将其转写至磁带上。磁

带驱动器被直接从主机映射到 VBA 上，而不是作为从网络接入的设备。

这种混合式处理方案尚未见诸白皮书，不过它的工作状态相当令人赞

赏，只要再稍加改进，我一定会在未来的部署工作中再次加以使用。

进步无止境

新技术组合的不断引入使得任何一套虚拟化模式都无法长久保持不变。

目前最新的好方案是 IOMMU，它承诺为单独的虚拟机系统提供直接访问系

统设备（例如显卡）的能力。

虚拟机将有能力充分发挥 GPGPU 计算带来的强大性能，而处理速度的提

升也会要求数据输入量达到光线通道传输能力的级别，这是分布式技术所

无法满足的。硬件容错能力的提高使单台主机方案更具可靠性，而新的网

络技术则将带宽扩大至 40Gb、100Gb 甚至更高。

到这里我们又说回起点。虚拟化始于大型机，而虚拟化又推动了 x86 在

采纳新技术的道路上渐行渐远，这使得台式机与大型机的运作方式越来越

接近。

原文：Server virtualisation: How to pick the right model

译文：http://server.51cto.com/sCollege-306706.htm

“VEPA网卡自身所具备的能力足以被称为交

换机。”



http://os.51cto.com

http://www.theregister.co.uk/2011/11/14/server_virtualisation/

http://server.51cto.com/sCollege-306706.htm

009




八卦News

009

Hash冲突漏洞需修补 12306.cn引热议

Nginx 的市场份额已经从今年年初的 5.9% 增长到了 10%，成为增长最

快的 Web 服务器。目前 Apache 仍占主导地位。


Linux Deepin 11.12 发布，使用了 Gnone Shell 作为默认桌面环境，并在

此基础上做了大量细节改进。


当前包括 PHP、Java、Ruby 在内的很多语言版本存在漏洞，攻击者可以通

过构造 Hash 冲突实现拒绝服务攻击。各语言的漏洞补丁已陆续放出，请抓

紧修补。


12306.cn ：这事儿聊的很多了，好文层出不穷：


http://bbs.hpx-party.org/thread-8488-1-1.html

http://hi.baidu.com/caoz/blog/item/f4f1d7caee09b558f21fe780.html

除了技术分析和针对招标、运量的分析之外，甚至还有往 SNS 方向拓展

的思路：

http://blog.codingnow.com/2012/01/12306_sns.html

发现问题比没发现好，有争论比没人谈论好，在有机会讨论的时候多讨

论，才能在明年更容易拿到回家的火车票。

——八卦，新闻与数字 2011.12 - 2012.01

【致歉声明】

15 期《虚拟化管理软件比较－－综合篇》一文的作者为蒋清野，

刊中误打印成了“蒋清扬”，特此勘误，并向蒋清野先生致歉！

蒋清野的博客：http://www.qyjohn.net/

蒋清野的微博：http://weibo.com/qyjohn

Linux 内核 3.2 正式版发布，改进了 EXT4 和 BTRFS 文件系统，改善延

迟的 TCP 包恢复算法，增加了 CPU 带宽控制，允许存储空间过度配置。下

载地址：

http://www.kernel.org/pub/linux/kernel/v3.0/

Fedora 工程筹划委员会 (FESCo) 近日举行会议，开发人员们批准了

Beefy Miracle Fedora 17 即将加入的几项关键新特性，包含 GNOME 3.4 和

OpenStack 等。


2012 年是阿兰·图灵诞生后的一百周年。为了纪念这位伟大的科学家，

Scaruffi.com 的创始人 Piero Scaruffi 在最近分享了一个 83 页的幻灯片：

Alan Turing and the Programmable Universe，对阿兰·图灵的故事进行了

很精彩的解读。51CTO 特将这份幻灯片翻译过来，跟大家分享。




http://os.51cto.com

010




专题Special

010

CDN服务缓存系统的选型与技巧

“当 YouTube 出现在世人面前的时候，人们为互联网的又一次革命而叫

好，而与此同时，人们看到了在 YouTube 后面的一个强大的 CDN 支持，是这

个 CDN 网络把 YouTube 的无数视频展现在人们面前，在这个时候，人们发

现 CDN 是不可或缺的，CDN 在经历了那么长时间的默默无闻以后，突然一

夜间闻达于诸侯，就象君士坦丁大帝把天主教定为国教一样，大家突然认识

到了一个不为人熟知的领域。但我们看到的是什么呢？君士坦丁介绍给罗

马的天主教是耶稣创立时的教义么？我们所看到的 CDN 是 MIT 创立时的

CDN 么？

人们开始搜索 CDN，研究 CDN，发现 CDN 是那么的简单，可以用一页 PPT

就把原理讲的清清楚楚，而网络硬件的厂商也会这样和互联网的客户说，我

们可以提供完整的 CDN 解决方案，你不需要做什么，买我们的硬件，它已经

能够解决你所有的 CDN 问题。

从此，CDN 变成了一个流行词汇，尤其是在高盛领投 LimeLight（全球第

二大 CDN 公司） 1.2 亿美金之后，突然之间，世界各地都出现了大大小小

的 CDN 公司，无数的投资蜂拥而至，就像那时的罗马，人人都开始信仰天主

教，也许是真的信仰，也许是为了圣餐，也许是为了研究，总之，“我们都爱

CDN”。

也许有人问：我们谈论的是同一个 CDN么，或者我们谈论的不是 CDN？”

—— via《看上去很美——国内 CDN 现状与美国对比》 by 阀域



http://os.51cto.com

http://blog.csdn.net/fayu0903/article/details/4022979

011




专题Special

011

web网站加速之CDN技术原理

在不同地域的用户访问网站的响应速度存在差异，为了提高用户访问的

响应速度、优化现有 Internet 中信息的流动，需要在用户和服务器间加入中

间层 CDN，使用户能以最快的速度，从最接近用户的地方获得所需的信息，

彻底解决网络拥塞，提高响应速度，是目前大型网站使用的流行的应用方

案。

1. CDN 概述

CDN 的全称是 Content Delivery Network，即内容分发网络。其目的是通

过在现有的 Internet 中增加一层新的 CACHE( 缓存 ) 层，将网站的内容发布

到最接近用户的网络 " 边缘 " 的节点，使用户可以就近取得所需的内容，提

高用户访问网站的响应速度。从技术上全面解决由于网络带宽小、用户访

问量大、网点分布不均等原因，提高用户访问网站的响应速度。

Cache 层的技术，消除数据峰值访问造成的结点设备阻塞。Cache 服务

器具有缓存功能，所以大部分网页对象（Web page object）, 如 html, htm,

php 等页面文件，gif,tif,png,bmp 等图片文件，以及其他格式的文件，在有

效期（TTL）内，对于重复的访问，不必从原始网站重新传送文件实体 , 只

需通过简单的认证（Freshness Validation）- 传送几十字节的 Header，即可

将本地的副本直接传送给访问者。由于缓存服务器通常部署在靠近用户端，

所以能获得近似局域网的响应速度，并有效减少广域带宽的消耗。不仅能

提高响应速度，节约带宽，对于加速 Web 服务器，有效减轻源服务器的负载

是非常有效的。

根据加速对象不同，分为客户端加速和服务器加速

客户端加速 : Cache 部署在网络出口处，把常访问的内容缓存在本地，

提高响应速度和节约带宽；

服务器加速 : Cache 部署在服务器前端，作为 Web 服务器的代理缓存

机，提高 Web 服务器的性能，加速访问速度

如果多台 Cache 加速服务器且分布在不同地域，需要通过有效地机制管

理 Cache 网络，引导用户就近访问 ( 比如通过 DNS 引导用户 )，全局负载均

文/北方人(@戒日祭)

012




专题Special

012

衡流量，这是 CDN 内容传输网络的基本思想。

CDN 对网络的优化作用主要体现在如下几个方面　- 解决服务器端的

“第一公里”问题　- 缓解甚至消除了不同运营商之间互联的瓶颈造成

的影响　- 减轻了各省的出口带宽压力　- 缓解了骨干网的压力　-

优化了网上热点内容的分布

2. CDN 的工作原理

2.1. 传统访问过程(未加速缓存服务)

我们先看传统的未加缓存服务的访问过程，以便了解 CDN 缓存访问方式

与未加缓存访问方式的差别：

由上图可见，用户访问未使用 CDN 缓存网站的过程为 :

用户输入访问的域名 , 操作系统向 LocalDNS 查询域名的 ip 地址 .

LocalDNS 向 ROOT DNS 查询域名的授权服务器 ( 这里假设 LocalDNS

缓存过期 )

ROOT DNS 将域名授权 DNS 记录回应给 LocalDNS

LocalDNS 得到域名的授权 DNS 记录后 , 继续向域名授权 DNS 查询域名

的 ip 地址

域名授权 DNS 查询域名记录后，回应给 LocalDNS

LocalDNS 将得到的域名 ip 地址，回应给用户端

用户得到域名 ip 地址后，访问站点服务器

站点服务器应答请求，将内容返回给客户端 .

2.2. CDN访问过程(使用缓存服务)

CDN 网络是在用户和服务器之间增加 Cache 层，主要是通过接管 DNS 实

现 , 将用户的请求引导到 Cache 上获得源服务器的数据

下面让我们看看访问使用 CDN 缓存后的网站的过程：

通过上图，我们可以了解到，使用了 CDN 缓存后的网站的访问过程变为：

用户输入访问的域名 , 操作系统向 LocalDNS 查询域名的 ip 地址 .

LocalDNS 向 ROOT DNS 查询域名的授权服务器 ( 这里假设 LocalDNS

013




专题Special

013

缓存过期 )

ROOT DNS 将域名授权 DNS 记录回应给 LocalDNS

LocalDNS 得到域名的授权 DNS 记录后 , 继续向域名授权 DNS 查询域名

的 ip 地址

域名授权 DNS 查询域名记录后 ( 一般是 CNAME)，回应给 LocalDNS

LocalDNS 得到域名记录后 , 向智能调度 DNS 查询域名的 ip 地址

智能调度 DNS 根据一定的算法和策略 ( 比如静态拓扑，容量等 ), 将最

适合的 CDN 节点 ip 地址回应给 LocalDNS

LocalDNS 将得到的域名 ip 地址，回应给用户端

用户得到域名 ip 地址后，访问站点服务器

CDN 节点服务器应答请求，将内容返回给客户端 .( 缓存服务器一方面

在本地进行保存，以备以后使用，二方面把获取的数据返回给客户端，完成

数据服务过程 )

通过以上的分析我们可以得到，为了实现对普通用户透明 ( 使用缓存后

用户客户端无需进行任何设置 ) 访问，需要使用 DNS( 域名解析 ) 来引导

用户来访问 Cache 服务器，以实现透明的加速服务 . 由于用户访问网站的

第一步就是域名解析 , 所以通过修改 DNS 来引导用户访问是最简单有效

的方式 .

2.3. CDN网络的组成要素

对于普通的 Internet 用户，每个 CDN 节点就相当于一个放置在它周围的

网站服务器 .

通过对 DNS 的接管，用户的请求被透明地指向离他最近的节点，节点中

CDN 服务器会像网站的原始服务器一样，响应用户的请求 .

由于它离用户更近，因而响应时间必然更快 .

从上面图中虚线圈起来的那块，就是 CDN 层 , 这层是位于用户端和

站点服务器之间 .

智能调度 DNS( 比如 f5 的 3DNS)

智能调度 DNS 是 CDN 服务中的关键系统 . 当用户访问加入 CDN 服务的

网站时，域名解析请求将最终由智能调度 DNS 负责处理 .

它通过一组预先定义好的策略，将当时最接近用户的节点地址提供给用

户，使用户可以得到快速的服务 .

同时它需要与分布在各地的 CDN 节点保持通信，跟踪各节点的健康状

态 , 容量等，确保将用户的请求分配到就近可用的节点上 .

缓存功能服务

负载均衡设备 ( 如 lvs,F5 的 BIG/IP)

内容 Cache 服务器 ( 如 squid）

共享存储 ( 根据缓存数据量多少决定是否需要 )

3. CDN 智能调度DNS 实例分析（略，见原文）

4. CDN的智能调度DNS 简化实现（略，见原文）

5. 总结(Summary）

在建立 CDN 网路时，最关键的就是智能调度 DNS，这个是 CDN 网络总

协调 , 通过高效的调度算法，可以使用户得到最佳的访问体验 .

其次就是 CDN 节点的管理 , 比如涉及到内容的同步机制，配置文件的

更新等等，都需要有一套机制来保证 .

原文：http://www.51know.info/system_performance/cdn/cdn.html

014




专题Special

014

大型网站后台架构的web server与缓存

计算机系统中，缓存有很多种。比如 CPU 内部的一级缓存、二级缓存。

文件系统的缓存，磁盘的缓存。在大型网站的后台部署过程中，也灵活运用

了各级缓存。主要有客户端的浏览器缓存，服务器端的 web server 自身缓

存，代理缓存，分布式缓存，数据库自身的缓存等。本节主要分析一下代理

缓存。

代理缓存

在网站后台架构中，代理缓存主要部署在 web server 之上，当用户对网

站后台发起连接请求时，用户请求先到代理缓存中去查找，如果命中，则将

请求返回给用户，如果没有命中，则代理缓存将请求发到 web server，然后

web sever 将请求复制一份到代理缓存中，同时把请求返回给客户。

常用的代理缓存有 varnish 和 squid。

Squid

Squid 是一个高性能的代理缓存服务器，可以用来加快浏览网页的速度，

提高客户机的访问命中率。Squid 不仅支持 HTTP 协议，还支持 FTP、SSL、

WAIS 等协议。Squid 用一个单独的、非模块化的、I/O 驱动的进程来处理所

有的客户端请求。

Squid 的原理如下：

(1) 每一台 squid 代理服务器上存有若干个颗磁盘。每颗磁盘又分割

成多个分区，每一个分区又可建立很多目录，目录下存放着具体的文件

(object)。

(2)squid 通过查询表的方式来定位某个资源的位置。所查询的表有两

种，一种是 Hash table，一种是 Digest table。Hash table 记录着所有 Digest

table 表信息，所以 Hash table 可以称之为目录或者提纲。而 Digest table 记

录了磁盘上每个分区、每个目录里存放的缓存摘要，所以 Digest table 可以

称之为摘要或者索引。所以，Squid 接到请求后先查询 Hashtable，根据 Hash

table 所指向的 Digest table，再查询所需要的文件。

(3)squid 服务器存在两种工作关系，一种为 Child-Parent，当 child squid

server 没有用户需要的数据时，就向 parent squid server 发送请求，并持续

等待，直到 parent squid server 回应为止；另一种为 Sibling，当本地 squid

server 没有用户请求的数据时，会向 sibling server 发送请求，如果 sibling

server 没有资料则会向上级 sibling 或者 internet 发送数据请求。

所以，综上所述，squid 运行模式如下：

当 Squid Server 没有资料时，先向 Sibling 的 Squid Server 查询数据，如

果 Sibling 没有，则跳过它直接向 Parent 查询，直到 Parent 提供资料为止 ( 如

果 Parent 没有资料，则到后端的 web server 上获取，当获取到数据后返回

给用户的同时，保留一份在自身的缓存中 )。如果不存在 Parent，则 Squid

Server 自身到后端的 web server 上获取数据，当获取到数据后返回给用户

的同时，保留一份在自身的缓存中。如果还是不能得到数据，则向用户端回

复不能得到数据。

文/凤凰舞者

015




专题Special

015

Varnish

Varnish 是一款高性能的开源 HTTP 加速器，挪威最大的在线报纸 Verdens

Gang 使用 3 台 Varnish 代替了原来的 12 台 Squid，性能比以前更好。

Varnish 的作者 Poul-Henning Kamp 是 FreeBSD 内核开发者之一，他认为

现在的计算机比起 1975 年已经复杂很多。在 1975 年时，存储媒介只有两

种：内存与硬盘。但现在计算机系统的内存除了主存外，还包括了 CPU 内

的 L1\L2\L3 等 cache。因此 Squid Cache 自行处理物件替换的架构不可

能得知这些情况而做到最佳化，但操作系统可以。所以这部分的工作应该

交给操作系统处理，这就是 Varnish cache 设计架构 [4]。Varnish 将所有的

HTTP object 存于一个单独的大文件中，该文件在工作进程初始化的时候，

将其整个映射到内存中。这样 Varnish 在该块内存中实现一个简单的文件

系统，具有分配、释放、修剪、合并内存等功能。

Varnish 文件缓存的工作流程：

Varnish 与一般服务器软件类似，分为 master 进程和 child 进程。其中

master 进程负责管理，child 进程负责 cache 工作。Master 进程读入命令，进

行一些初始化，然后 fork 并监控 child 进程。Child 进程分配若干线程进行

工作，主要包括管理线程和 worker 线程。如下图所示。

主进程 fork 子进程，主进程等待子进程的信号，子进程退出后，主进程重

新启动子进程，子进程生成若干线程：

(1)Accept 线程：接受请求，将请求挂在 overflow 队列上。

(2)Work 线程：有多个，负责从 overflow 队列上摘除请求，对请求进行处

理，直到完成，然后处理下一个请求。

(3)Epoll 线程：一个请求处理称为一个 session，在 session 周期内，处理

完请求后，会交给 Epoll 处理，监听是否还在事件发生。

(4)Expire 线程：对于缓存的 object，根据过期时间，组织成二叉堆，该线

程周期检查该堆得根，处理过期的文件。对过期的数据进行删除或重取操

作。

Varnish 分配缓存机制：

根据所读到的 object 大小，创建相应大小的缓存文件。为了读写方便，

程序将每个 object 的大小，转变为最接近其大小的内存页面倍数。然后从

现有的空闲存储结构体中查找，找到最合适的大小的空闲存储块，分配给

它。如果空闲块没有用完，则把多余的内存再组成一个空闲存储块，挂接到

管理结构体上。如果缓存已满，则根据 LRU 算法，把旧的 object 释放掉。

Varnish 释放缓存机制：

Expire 线程负责检测缓存中所有 object 的生存期 (TTL)。如果超过了设

定的 TTL，该 object 没有被访问，则删除该 object，并释放内存。释放的过程

会考虑内存的合并等操作。

原文：http://blog.csdn.net/longxibendi/article/details/6647024

推荐阅读：varnish 权威指南中文版

《互联网运营智慧》第 7 章“简单 cdn”正式版下载

http://blog.csdn.net/longxibendi/article/details/6647024

http://book.51cto.com/art/201011/234557.htm

http://sery.blog.51cto.com/10037/465141

016




专题Special

016

Squid常用命令总结

Squid安装设试命令:

1，初始化你在 squid.conf 里配置的 cache 目录

#/usr/local/squid/sbin/squid -z // 初始化缓存空间

如果有错误提示，请检查你的 cache 目录的权限。

2，对你的 squid.conf 排错，即验证 squid.conf 的语法和配置。

#/usr/local/squid/sbin/squid -k parse

如果 squid.conf 有语法或配置错误，这里会返回提示你，如果没有返回，

恭喜，可以尝试启动 squid。

3，在前台启动 squid，并输出启动过程。

#/usr/local/squid/sbin/squid -N -d1

如果有 ready to server reques，恭喜，启动成功。

然后 ctrl + c，停止 squid，并以后台运行的方式启动它。

4，启动 squid 在后台运行。

#/usr/local/squid/sbin/squid -s

这时候可以 ps -A 来查看系统进程，可以看到两个 squid 进程。

5，停止 squid

#/usr/local/squid/sbin/squid -k shutdown

这个不用解释吧。

6，重引导修改过的 squid.conf

#/usr/local/squid/sbin/squid -k reconfigure // 载入新的配置文件

这个估计用的时候比较多，当你发现你的配置有不尽你意的时候，可以

随时修改 squid.conf，然后别忘记对你的 squid.conf 排错，然后再执行此指

令，即可让 squid 重新按照你的 squid.conf 来运行。

7./usr/local/squid/sbin/squid -k rotate 轮循日志

8，把 squid 添加到系统启动项

编辑 /etc/rc.d/rc.local

添加如下行： /usr/local/squid/sbin/squid -s

利用 Runc 脚本 ........

再来点其他的。

1，修改 cache 缓存目录的权限。

#chown -R squid:squid /data/cache

我的 cache 缓存目录是 /data/cache,squid 执行用户和用户组是 squid，

squid。

收集整理/NetSeek

017




专题Special

017

2，修改 squid 日志目录的权限

#chown -R squid:squid /usr/local/squid/var/logs

这一步并不是适合每一个使用 squid 的用户 . 意为让 squid 有权限在该

目录进行写操作。

例如生成 access.log cache.log store.log

3，查看你的日志文档。

#more /usr/local/squid/var/logs/access.log | grep TCP_MEM_HIT

该指令可以看到在 squid运行过程中，有那些文件被 squid缓存到内存中，

并返回给访问用户。

#more /usr/local/squid/var/logs/access.log | grep TCP_HIT

该指令可以看到在 squid 运行过程中，有那些文件被 squid 缓存到 cache

目录中，并返回给访问用户。

#more /usr/local/squid/var/logs/access.log | grep TCP_MISS

该指令可以看到在 squid 运行过程中，有那些文件没有被 squid 缓存，而

是现重原始服务器获取并返回给访问用户。

关于 TCP_XXXX 等参数及代表的信息，请参看《squid 中文权威指南》

13.2.1 章节。

当然，grep 的部分可以修改为其他的参数，例如你的域名 www.xxxx.

com ，同样可以看到 access.log 里关于该域名的行。

squid命中率分析

squid/bin/squidclient -p 80 mgr:info

squid/bin/squidclient -p 80 mgr:5min

可以看到详细的性能情况 , 其中 PORT 是你的 proxy 的端口，5min 可以

是 60min

取得 squid 运行状态信息：

squidclient -p 80 mgr:info

* 取得 squid 内存使用情况：

squidclient -p 80 mgr:mem

* 取得 squid 已经缓存的列表：

squidclient -p 80 mgrbjects. use it carefully,it may crash

* 取得 squid 的磁盘使用情况：

squidclient -p 80 mgr:diskd

* 强制更新某个 url ：

squidclient -p 80 -m PURGE http://www.yejr.com/static.php

* 更多的请查看：

squidclient-h 或者 squidclient -p 80 mgr:

查命中率：

/usr/local/squid/bin/squidclient -h111.222.111.111 -p80 mgr:info

/usr/local/squid/bin/squidclient -h 具体的 IP -p80 mgr:info

原文：http://bbs.linuxtone.org/thread-137-1-1.html

前面的安装调试部分来自 CU 的这个帖子。

相关链接：《Squid 中文权威指南》在线阅读

http://bbs.chinaunix.net/forum.php?mod=viewthread&tid=960422

http://blog.s135.com/book/squid/

018




专题Special

018

[CDN]动态内容的缓存技术 CSI,SSI,ESI

CDN 中动态内容是不太好解决的，通常需要很麻烦的技术和方法来实现

这些功能，比如我设计过一种动态缓存的方法，基于 session 栏接，然后根

据热点来做动态缓存时间的控制。目前开放的实现 Cache 的技术主要有

CSI,SSI,ESI 之类几种。在一个动态网页中 , 内容不断更新和变化，但这并

不意味不能缓存，其实还是有 90% 的内容都可以做到 CDN 中的。只要

花点心思。但这些都对客户有更加高的要需求。下面是这向种技术的介绍。

动态 Cache 页面有如下一些方案：

1、Client Side Includes(CSI) ：

通过 iframe、javascript、ajax 等方式将另外一个页面的内容动态包含进

来。这样来实现动态化。

优点：能够利用浏览器客户端并行处理及装载的机制；这种技术基本不

需要服务器支持和修改，计算和操作放在客户端，能够降低服务器端压力

缺点：搜索引擎优化问题；javascript 兼容性问题；客户端缓存可能导致

服务器端内容更新后不能及时生效。常常通过加 js version 来解决 .

2、Server Side Includes(SSI) ：

SSI 它就是 HTML 文件中，可以通过注释行调用的命令或指针。实现整

个网站的内容更新。SSI 需要特殊的文件后缀 (shtml,inc).

优点：SSI 技术是通用技术，不受具体语言限制，只需要 Web 服务器或应

用服务器支持即可，Ngnix、Apache、Tomcat、Jboss 等对此都有较好的支持，

目前 Squid 不支持。

缺点：SSI 在语法上不能够直接包含其他服务器的 url，只能在当前服务

器上运行。所以通过 CDN 之类的 Cache 时，还是会失效，不灵活 .

3、Edge Side Includes (ESI) ：

Edge Side Includes(ESI) 和 Server Side Includes(SSI) 和功能类似。SSI

需要特殊的文件后缀 (shtml,inc)。ESI（Edge Side Include）通过使用简

单的标记语言来对那些可以加速和不能加速的网页中的内容片断进行描

述，每个网页都被划分成不同的小部分分别赋予不同的缓存控制策略，使

Cache 服务器可以根据这些策略在将完整的网页发送给用户之前将不同的

小部分动态地组合在一起。通过这种控制，可以有效地减少从服务器抓取

整个页面的次数，而只用从原服务器中提取少量的不能缓存的片断，因此

可以有效降低原服务器的负载，同时提高用户访问的响应时间。

优点： ESI 更适合用于缓存服务器上，缓存整个页面或页面片段，因此

ESI 特别适合用于缓存，CDN 的第一名的老大，Akamai 全力支持协议。对

于布置和 Cache 都是最友好的。

缺点：出来很久，一直没有多少人使用。会这个技术的程序员不多。

原文：

http://www.php-oa.com/2010/08/13/cdn-cache-csi-ssi-esi.html

文/扶凯

019




专题Special

019

squid/varnish/ats简单测试

简单的试试 varnish 和 apache traffic server。跟 squid 进行一下对比。

介于 varnish 和 ats 都是出现不太久的东西（至少是开源流行不长），选择其

最新开发版本测试，正巧都是 2.15 版。

varnish 配置文件，只修改了 backend 到具体某台 nginx 发布点上。其他

都是反向代理缓存的标配。（可参考张宴博客和 varnish 权威指南）

ats 说明更少，从目前的资料看，修改了 records.config 中的监听，cache.

config 遵循源站未改，remap.config 添加了 map 一条，绑定域名到同一台

nginx 上。

注：varnish 和 ats 都没有修改缓存路径，即分别为 var/varnish/varnish.

cache 和 var/trafficserver，都是磁盘。

然后从线上某台 squid2.7 上收集 www.domain.com 下的 html 页面 url

一共 164 条，存成 urllist。

使用 http_load 进行测试。第一遍，先用 http_load -r 100 -s 10 完成

cache 的加载；第二遍改用 -r 1000 -s 60 进行测试。

1、先是 varnish ：开另一个窗口看 netstat，发现在第一次加载的时候，

varnish 启动了相当多的链接到后端 nginx 请求数据！第二遍时，-r1000 一

直在刷 wrong，修改成 -r900 就没有问题。最后的报告显示 fetch/sec 还略

大于指定的 900 达到 990，建连时间平均 1.3ms，响应时间 1.8ms。

2、然后 ats ：-r1000 也报 wrong，于是同样使用 -r900，fetch/sec 和建连

时间与 varnish 相近，响应时间 2.1ms。

从 trafficserver_shell 的 show:proxy_stats 和 show:cache_stats 命令结果

来看，缓存命中率 98%，磁盘 IO 几乎没有。可见其实都在内存中返回了。

3、最后 squid2.7.9 ：-r900 时，fetch/sec 只有 880，响应时间 1.9ms ；提

高到 -r1000 时，没有 wrong 报错，fetch/sec 下降到 850，响应时间 2.3ms ；

另一个窗口的 netstat 命令直接卡住……

squid按照公司默认做法，缓存目录建在了 tmpfs上。从 squidclient来看，

98% 的命中率中只有三分之一是直接通过 cache_mem 返回的，另三分之二

是通过 cache_dir 的 tmpfs 返回。

另：最后 du -sh 查看三者的缓存目录大小，赫然发现 squid 的是 19M，

ats 是 39M，varnish 是 41M。这个差别也是比较怪异的，值得后续研究……

从这个简单测试结果看，squid 的稳定性依然没的说：对于大多数情况来

说，是乐于见到这种宁愿响应慢点点也要保证响应正确的情况的；varnish

在大批量回源时对后端服务器的冲击，显然比较让人担心；ats 和 varnish 具

有同样高效的响应速度（和高压下的错误……），而且其详细到甚至稍显繁

琐的那堆 config 文件的配置格式，相比 varnish 来说，更加贴近运维人员。

原文：http://chenlinux.com/2011/03/15/simple-test-between-

squid-varnish-ats.html

文/三斗室

http://blog.s135.com

http://linuxguest.blog.51cto.com/195664/354889

http://chenlinux.com/2011/03/15/simple-test-between-squid-varnish-ats.html

http://chenlinux.com/2011/03/15/simple-test-between-squid-varnish-ats.html

020




专题Special

020

使用Nginx代替squid充当代理缓存服务器

我的博客是 CentOS+nginx+php+mysql+eaccelerator 这种架构。只有一

台服务器，所以想到用在让两个 nginx 分别监听 IP:80 和 127.0.0.1:80。

1. 安装 nginx 和 nginx_cache_Purge.

wget http://labs.frickle.com/files/ngx_cache_purge-1.1.tar.gz

tar zxvf ngx_cache_purge-1.1.tar.gz

wget http://nginx.org/download/nginx-0.8.47.tar.gz

tar zxvf nginx-0.8.47.tar.gz

cd nginx-0.8.47/

./configure --prefix=/usr/local/nginx --user=www --group=www --add-

module=ngx_cache_purge-1.1 --with-http_stub_status_module --with-http_

ssl_module

make -j2 && make install

cd ../

2.nginx 配置

cat /usr/local/nginx/conf/nginx.conf

user www www;

worker_processes 1;

error_log /usr/local/nginx/logs/nginx_error.log crit;

pid /usr/local/nginx/nginx.pid;

#Specifies the value for maximum file descriptors that can be opened by this

process.

worker_rlimit_nofile 65535;

events

{

use epoll;

worker_connections 65535;

}

http

{

include mime.types;

default_type application/octet-stream;

charset gbk;

#source_charset gbk;

server_names_hash_bucket_size 128;

client_header_buffer_size 32k;

large_client_header_buffers 4 32k;

client_max_body_size 300m;

sendfile on;

tcp_nopush on;

keepalive_timeout 60;

tcp_nodelay on;

client_body_buffer_size 512k;

proxy_connect_timeout 5;

proxy_read_timeout 60;

proxy_send_timeout 5;

proxy_buffer_size 16k;

proxy_buffers 4 64k;

proxy_busy_buffers_size 128k;

proxy_temp_file_write_size 128k;

gzip on;

文/崔晓辉

021




专题Special

021

gzip_min_length 1k;

gzip_buffers 4 16k;

gzip_http_version 1.1;

gzip_comp_level 2;

gzip_types text/plain application/x-javascript text/css application/xml;

gzip_vary on;

proxy_temp_path /home/proxy_temp_dir;

proxy_cache_path /home/proxy_cache_dir levels=1:2 keys_zone=cache_

one:200m inactive=1d max_size=30g;

upstream backend_server {

server 127.0.0.1:80 weight=1 max_fails=2 fail_timeout=30s;

# server 192.168.8.44:80 weight=1 max_fails=2 fail_timeout=30s;

# server 192.168.8.45:80 weight=1 max_fails=2 fail_timeout=30s;

}

server

{

listen 222.134.x.x:80;

server_name www.freebsdsystem.org blog.freebsdsystem.org freebsdsystem.

org;

index index.html index.htm index.php;

root /usr/local/AUTOLEMP/www/www.freebsdsystem.org;

location /

{

proxy_next_upstream http_502 http_504 error timeout invalid_header;

proxy_cache cache_one;

proxy_cache_valid 200 304 12h;

proxy_cache_key $host$uri$is_args$args;

proxy_set_header Host $host;

proxy_set_header X-Forwarded-For $remote_addr;

proxy_pass http://backend_server;

add_header X-Cache HIT-FreeBSDSYSTEM.org;

expires 1d;

}

location ~ /purge(/.*)

{

allow 127.0.0.1;

allow 219.146.0.0/16;

deny all;

proxy_cache_purge cache_one $host$1$is_args$args;

}

location ~ .*\.(php|jsp|cgi)?$

{




}

access_log off;

}

server

{

listen 222.134.66.153:80;

server_name www.huaanjiuyuan.com;

index index.html index.htm index.php;

root /usr/local/AUTOLEMP/www/wwwroot;

location /

{

proxy_next_upstream http_502 http_504 error timeout invalid_header;

proxy_cache cache_one;

proxy_cache_valid 200 304 12h;

022




专题Special

022

【特别推荐】

大话IT第20期：

当Windows8遇上Linux控本期节目不但有微软最新的 Windows 8 操作系统登场，还有

Fedora16、Ubuntu 11.10、OpenSUSE 11.4 出马，更有最近密码泄漏事

件频发而被人关注的 keepass 工具……

三位编辑分别在用 Linux 做什么？

Windows8 又有啥特别的？

敬请收看本期的大话 IT。

在线观看：


IT 听听看官方微博：

http://weibo.com/itttkan

本期参与支持人员：

嘉文、周达洋、王文文、王玉平、杨赛、王丹、郭晗

proxy_cache_key $host$uri$is_args$args;




add_header X-Cache HIT-FreeBSDSYSTEM.org;

expires 1d;

}

location ~ /purge(/.*)

{

allow 127.0.0.1;

allow 219.146.0.0/16;

deny all;

proxy_cache_purge cache_one $host$1$is_args$args;

}

location ~ .*\.(php|jsp|cgi)?$

{




}

access_log off;

}

}

3. 修改 www.freebsdsystem.org 的 nginx.conf 将 server 中的 listen 80;

为 listen 127.0.0.1:80

4、重启两个 nginx。即可在 /home/proxy_cache_temp 看到缓存的目录！

5、不要在代理缓存服务器中加入 nginx_static_etags，不然你会哭的！

原文：http://coralzd.blog.51cto.com/90341/439030

023




运维DBADatabase

023

MySQL性能优化教程之MySQL运维优化

存储引擎类型

Myisam 速度快，响应快。表级锁是致命问题。

Innodb 目前主流存储引擎

行级锁

务必注意影响结果集的定义是什么

行级锁会带来更新的额外开销，但是通常情况下是值得的。

事务提交

对 i/o 效率提升的考虑

对安全性的考虑

HEAP 内存引擎

频繁更新和海量读取情况下仍会存在锁定状况

内存使用考量

理论上，内存越大，越多数据读取发生在内存，效率越高

Query cache 的使用

如果前端请求重复度不高，或者应用层已经充分缓存重复请求，

query cache 不必设置很大，甚至可以不设置。

如果前端请求重复度较高，无应用层缓存，query cache 是一个很

好的偷懒选择

对于中等以下规模数据库应用，偷懒不是一个坏选择。

如果确认使用 query cache，记得定时清理碎片，flush query

cache.

要考虑到现实的硬件资源和瓶颈分布

学会理解热点数据，并将热点数据尽可能内存化

所谓热点数据，就是最多被访问的数据。

通常数据库访问是不平均的，少数数据被频繁读写，而更多数据

鲜有读写。

学会制定不同的热点数据规则，并测算指标。

热点数据规模，理论上，热点数据越少越好，这样可以更好的

满足业务的增长趋势。

响应满足度，对响应的满足率越高越好。

比如依据最后更新时间，总访问量，回访次数等指标定义热

点数据，并测算不同定义模式下的热点数据规模

文/caoz



http://os.51cto.com

024




运维DBADatabase

024

性能与安全性考量

数据提交方式

innodb_flush_log_at_trx_commit = 1 每次自动提交，安全性高，

i/o 压力大

innodb_flush_log_at_trx_commit = 2 每秒自动提交，安全性略

有影响，i/o 承载强。

日志同步

Sync-binlog =1 每条自动更新，安全性高，i/o 压力大

Sync-binlog = 0 根据缓存设置情况自动更新，存在丢失数据

和同步延迟风险，i/o 承载力强。

个人建议保存 binlog日志文件，便于追溯更新操作和系统恢复。

如对日志文件的 i/o 压力有担心，在内存宽裕的情况下，可考虑

将 binlog 写入到诸如 /dev/shm 这样的内存映射分区，并定时

将旧有的 binlog 转移到物理硬盘。

性能与安全本身存在相悖的情况，需要在业务诉求层面决定取舍

学会区分什么场合侧重性能，什么场合侧重安全

学会将不同安全等级的数据库用不同策略管理

存储/写入压力优化

顺序读写性能远高于随机读写

将顺序写数据和随机读写数据分成不同的物理磁盘进行，有助于 i/

o 压力的疏解

• 数据库文件涉及索引等内容，写入是随即写

• binlog 文件是顺序写

• 淘宝数据库存储优化是这样处理的

部分安全要求不高的写入操作可以用 /dev/shm 分区存储，简单变

成内存写。

多块物理硬盘做 raid10，可以提升写入能力

关键存储设备优化，善于比对不同存储介质的压力测试数据。

• 例如 fusion-io 在新浪和淘宝都有较多使用。

涉及必须存储较为庞大的数据量时

• 压缩存储，可以通过增加 cpu 开销（压缩算法）减少 i/o 压力。前

提是你确认 cpu 相对空闲而 i/o 压力很大。新浪微博就是压缩

存储的典范。

• 通过 md5 去重存储，案例是 QQ 的文件共享，以及 dropbox 这样

的共享服务，如果你上传的是一个别人已有的文件，计算md5后，

直接通过 md5 定位到原有文件，这样可以极大减少存储量。涉

及文件共享，头像共享，相册等应用，通过这种方法可以减少超过

70% 的存储规模，对硬件资源的节省是相当巨大的。缺点是，删

除文件需要甄别该 md5 是否有其他人使用。去重存储，用户量

越多，上传文件越多，效率越高！

• 文件尽量不要存储到数据库内。尽量使用独立的文件系统存储，

该话题不展开。

运维监控体系

系统监控

服务器资源监控

025




运维DBADatabase

025

Cpu, 内存，硬盘空间，i/o 压力

设置阈值报警

服务器流量监控

外网流量，内网流量

设置阈值报警

连接状态监控

Show processlist 设置阈值，每分钟监测，超过阈值记录

应用监控

慢查询监控

慢查询日志

如果存在多台数据库服务器，应有汇总查阅机制。

请求错误监控

高频繁应用中，会出现偶发性数据库连接错误或执行错误，

将错误信息记录到日志，查看每日的比例变化。

偶发性错误，如果数量极少，可以不用处理，但是需时常监控

其趋势。

会存在恶意输入内容，输入边界限定缺乏导致执行出错，需

基于此防止恶意入侵探测行为。

微慢查询监控

高并发环境里，超过 0.01 秒的查询请求都应该关注一下。

频繁度监控

写操作，基于 binlog，定期分析。

读操作，在前端 db 封装代码中增加抽样日志，并输出执行时

间。

分析请求频繁度是开发架构进一步优化的基础

最好的优化就是减少请求次数！

总结：

监控与数据分析是一切优化的基础。

没有运营数据监测就不要妄谈优化！

监控要注意不要产生太多额外的负载，不要因监控带来太多额

外系统开销

本文摘录自 caoz 的文档《MySQL 性能优化教程》，下载地址：

http://wenku.baidu.com/view/aa43ecc3aa00b52acfc7ca94.html?st=1

推荐阅读：

MySQL 中创建及优化索引组织结构的思路

http://database.51cto.com/art/201110/296764.htm

MySQL 性能优化的 21 个最佳实践


专题：讲述 MySQL 索引和优化的故事


MySQL 技巧 : 结合相关参数做好 Limit 优化


026




新鲜事Freshy

026

建设一个靠谱的火车票网上订购系统

2012 年 1 月 11 日，@fenng 写了一篇文章，批评铁道部火车票网上订购

系统，http://www.12306.cn [1]。同时在新浪发了一条言辞激烈的微博，

“去你妈的‘海量事务高速处理系统’”，引起热议 [2]。

开发一套订票系统并不难，难在应对春运期间，日均 10 亿级别的洪峰

流量。日均 10 亿级别的洪峰请求，在中国这个人口全球第一大国，不算稀

罕，不仅火车票订票系统会遇到，而且电子商务在促销时，也会遇到，社交网

站遇到新闻热点时，也会遇到。

所以，能够在中国成功运行的云计算系统，推广到全球，一定也能成功。

但是在美国成功运行的云计算系统，移植到中国，却不一定成功。

如果我们能够设计建造一套，稳定而高效的铁路订票系统，不仅解决了

中国老百姓的实际问题，而且在全球高科技业界，也是一大亮点，而且是贴

着中国标签的前沿科技的亮点。

于是软件工程师们献计献策，讨论如何改进 12306 网上购票系统 [3]。

其中比较有代表性的，有两篇 [4,5]。

网友的评论中，有观点认为，[4] 利用“虚拟排队”的手段，将过程拉长负

载降低，是网游的设计思路。而 [5] 利用缓存技术，一层层地降低系统负

荷 , 是互联网的设计思路。

个人认为，[4] 和 [5] 并不是相互排斥的两种路线，两者着重解决的问

题不同，不妨结合起来使用，取长补短。下面介绍一下我们的设计草案，追

求实用，摈弃花哨。抛砖引玉，欢迎拍砖。

图一为 12306.cn 网站系统架构设想图，典型的“展现层”/ “业务层”/

“数据层”的三段论。

用户接入有两类，一个是运行在电脑里的浏览器，例如 IE，另一个是手

机。

无论用户用电脑浏览器，还是手机访问 http://www.12306.cn 网站，

用户请求首先被网站的负载均衡器接收。负载均衡器连接着一群门户服务

器，根据各个门户服务器的负载轻重，负载均衡器把用户请求，转发到某一

相对清闲的门户服务器。

门户服务器的任务类似于收发室老头儿，它只读每个用户请求的前几个

bytes，目的是确定用户请求的类型，然后把请求投放到相应类型的队列中

去。门户服务器的处理逻辑非常简单，这样做的好处，是让它能够快速处理

大批量用户请求。

根据 [5] 的分析，12306 处理的用户请求，大致分为三类，

文/林玥煜、邓侃(@邓侃)



http://os.51cto.com

027




新鲜事Freshy

027

1. 查询。用户订票前，查询车次以及余票。用户下订单后，查询是否已

经订上票。

2. 订票，包括确定车次和票数，然后付款。用户付款时，需要在网银等

网站上操作。

3. 第一次访问的用户，需要登记，包括姓名和信用卡等信息。

三类请求的业务处理过程，被分为两个阶段，

1. 运行于缓存中的任务队列。设置队列的目的，是防止处理过程耗时

太长，导致大量用户请求拥塞于门户服务器，导致系统瘫痪。

2. 业务处理处理器，对于每一类业务，分别有一群业务服务器。不同业

务的处理流程，各不相同。

图二为 12306.cn 网站查询和订票业务流程设想图，描述了查询和订票，

两个业务的处理流程。登记业务流程从略。

查询的业务流程，参见图二上半部，分五步。这里有两个问题需要注意，

1. 用户发出请求后，经过短暂的等待时间，能够迅速看到结果。平均等

待时间不能超过 1 秒。

2. 影响整个查询速度的关键，是“查询服务器”的设计。

查询任务可以进一步细化，大致分成三种。

1. 查询车次和时间表，这是静态内容，很少与数据库交互，数据量也不

大，可以缓存在内存中。

车次和时间表的数据结构，不妨采用 Key-Value 的方式，开发简单，使

用效率高。Key-Value 的具体实现有很多产品，[5] 建议使用 Redis。

这些是技术细节，不妨通过对比实验，针对火车票订票系统的实际流量，

以及峰值波动，确定哪一个产品最合适。

2. 查询某一班次的剩余车票，这需要调用数据库中不断更新的数据。

[5] 建议把剩余车票只分为两种，“有”或“无”，这样减少调用访问数据

库的次数，降低数据库的压力。但是这样做，不一定能够满足用户的需求，

说不定会招致网友的批评讥讽。

[4] 建议在订票队列中，增加测算订票队列长度的功能，根据订票队列长

度以及队列中每个请求的购票数量，可以计算出每个车次的剩余座位。如

果 12306.cn 网站只有一个后台系统，这个办法行之有效。

但是假如 12306.cn 网站采用分布式结构，每个铁路分局设有子系统，

分别管理各个铁路分局辖区内的各个车次。在分布式系统下，这个办法面

028




新鲜事Freshy

028

临任务转发的麻烦。不仅开发工作量大，而且会延长查询流程处理时间，导

致用户长久等待。

3. 已经下单的用户，查询是否已经成功地订上票。

每个用户通常只关心自己订的票。如果把每个用户订购的车票的所有

内容，都缓存在内存里，不仅非常耗用内存空间，内存空间使用效率低下，更

严重的问题是，访问数据库过于频繁，数据量大，增大数据库的压力。

解决上述分布式同步，以及数据库压力的两个问题，不妨从订票的流程

设计和数据结构设计入手。

假如有个北京用户在网上订购了一套联票，途经北京铁路局和郑州铁路

局辖区的两个车次。用户从北京上网，由北京铁路局的子系统，处理他的请

求。北京铁路局的订票服务器把他的请求一分为二，北京铁路局的车次的

订票，在北京子系统完成，郑州铁路局的车次在郑州子系统完成。

每个子系统处理四种 Key-Value 数据组。

1. 用户 ID ：多个 ( 订单 ID)s。

2. 订单 ID ：多个 ( 订票结果 ID)s。

3. 订票结果 ID: 一个 ( 用户 ID，车次 ID)。

4. 车次 ID ：一个 ( 日期 )，多个 ( 座位，用户 ID)。

北京订票服务器完成订票后，把上述四个数据组，写入北京子系统的数

据库，同时缓存进北京的查询服务器，参见图二下半部第 6 步和第 7 步。

郑州订票服务器完成订票后，把上述四个数据组，写入郑州子系统的数

据库，同时缓存进北京的查询服务器，而不是郑州的服务器。

让订票服务器把订票数据，同时写入数据库和查询服务器的缓存，目的

是让数据库永久保留订票记录，而让大多数查询，只访问缓存，降低数据库

的压力。

北京用户的订票数据，只缓存在北京的查询服务器，不跨域缓存，从而降

低缓存空间的占用，和同步的麻烦。这样做，有个前提假设，查询用户与订

票用户，基本上是同一个人，而且从同一个城市上网。

但是这里有个缺陷，某用户在北京上网订了票。过了几天，他在北京上

网，输入用户 ID 和密码后，就会看到他订购的所有车票。可是又过了几天，

他去了郑州，从郑州上网，同样输入用户 ID 和密码，却看不到他订购的所有

车票。

解决这个缺陷的办法并不麻烦，在用户查询订票信息时，需要注明订票

地点，系统根据订票地点，把查询请求转发到相应区域的子系统。

另外，每次订票的时候，网站会给他的手机发送短信，提供订票信息，参

见图二下半部第 8 步和第 9 步。

以上是一个初步设计，还有不少细节需要完善，例如防火墙如何布置等

等。这个设计不仅适用于单一的集中式部署，而且也适合分布式部署。

Reference，

[1] 海量事务高速处理系统。

[2] 去你妈的‘海量事务高速处理系统’。

[3] 火车订票系统的设想。

[4] 铁路订票系统的简单设计。

[5] 铁路订票网站个人的设计浅见。

原文：http://www.ifanr.com/68019

推荐阅读：由 12306.cn 谈谈网站性能技术 via coolshell

http://www.douban.com/note/195179318/

http://weibo.com/1577826897/y0jGYcZfW

http://weibo.com/1570303725/y0l9Y2mwE

http://blog.codingnow.com/2012/01/ticket_queue.html

http://hi.baidu.com/caoz/blog/item/f4f1d7caee09b558f21fe780.html

http://www.ifanr.com/68019

http://coolshell.cn/articles/6470.html

029




工具Tools

029

红帽虚拟桌面SPICE服务概述与安装指南

SPICE（独立计算环境简单协议）是红帽企业虚拟化桌面版的三大主要

技术组件之一，具有自适应能力的远程提交协议，能够提供与物理桌面完全

相同的最终用户体验。它包含有 3 个组件：

SPICE Driver ：SPICE 驱动器存在于每个虚拟桌面内的组件；

SPICE Device ：SPICE 设备存在于红帽企业虚拟化 Hypervisor 内的组件；

SPICE Client ：SPICE 客户端存在于终端设备上的组件，可以是瘦客户机

或专用的 PC，用于接入每个虚拟桌面。

这三个组件协作运行，确定处理图形的最高效位置，以能够最大程度改

善用户体验并降低系统负荷。如果客户机足够强大，SPICE 向客户机发送

图形命令，并在客户机中对图形进行处理，显著减轻服务器的负荷。另一方

面，如果客户机不够强大，SPICE 在主机处理图形，从 CPU 的角度讲，图形处

理并不需要太多费用。

SPICE 的工作原理是创建几个通用接口或“通道”，它们都高度抽象，所以

能在各种平台上使用。通道主要包括六个：

主通道

显示通道

输入通道

鼠标控制通道

播放通道

记录通道

每个通道可以是一个单独的数据流。SPICE 和 VNC 对比如下表。

SPICE VNC

BIOS 屏幕显示能能

全彩支持能能

更改分辨率能能

多显示器多显示器支持（高达 4 画面）只有一个屏幕图像传输图像和图形传输图像传输

视频播放支持 GPU 加速支持不能

音频传输双向语音可以控制不能

鼠标控制客户端服务器都可以控制服务器端控制

USB 传输 USB 可以通过网络传输不能加密通讯可以使用 SSL 进行加密不能

Spice 的未来的功能：

直接借助对 DirectX 和 API 来实现一个虚拟视频卡。加快 CAD 应用和多

媒体应用。更快的切换与游戏画面直接绘制过程减少闪烁。

视频加速（DXVA）视频播放应用程序支持 DXVA，如 Windows 媒体播放

器，可以减少对客户端的 CPU 利用率。

3D 加速会更快地运行在一个虚拟的桌面，如 OpenGL 和 3D 应用程序，

文/曹江华



http://os.51cto.com

030




工具Tools

030

Windows Aero 的支持，使用虚拟桌面时可以使用 Windows Vista 和 7

现在不可以。可以动态地改变虚拟桌面分辨率。

兼容 iPhone 和 ipad 通过智能手机，如 iPhone 和 iPad 等设备控制。

剪贴板共享你可以共享与虚拟桌面环境的剪贴板，数据将允许相互合作

可用于无缝连接。

网络打印机共享：打印机被允许从网络访问，提高可用性。

Linux 下有三种方式配置 SPICE 服务器：命令行、virt-manager、直接修改

配置文件。篇幅所限，下面只大概介绍命令行配置方式。

CentOS 6、RHEL 6安装配置SPICE服务器的方法

这里是直接修改配置文件方式，首先安装软件包：

#yum -y install spice-server

首先建立一个普通名称是 web 的虚拟机，可以使用 virt-manager 虚拟机

管理工具和命令行两种方法。

下面编辑虚拟机文件添加 spice 参数：

...

<input type='tablet' bus='usb'/>

# add

<graphics type='spice' port='5930' autoport='no' listen='192.168.0.13 '

passwd='password'/>

<video>

<model type='qxl' vram='32768' heads='1'/>

<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>

</video>

<memballoon model='virtio'>

<address type= 'pc i ' domain= '0x0000 ' bus= '0x00 ' s lo t= '0x04 '

function='0x0'/>

</memballoon>

</devices>

</domain>

启动虚拟机：

#virsh start web

Domain web started

Linux下使用SPICE客户机

#yum -y install spice-client

Linux 下使用 spicec 命令连接：

# /usr/libexec/spicec -h 192.168.0.13 -p 5930 -w password

-h 参数是 kvm 虚拟机 ip 地址

-p 参数是 kvm 虚拟机端口

-w 参数是密码

Windows下使用SPICE客户机

从 http://www.spice-space.org/download.html 下载两个文件：

spice-client-win32-0.6.3.zip

spice_libs_win32_063_and_earlier.zip

然后解压缩。spicec.exe 文件复制到 spice_libs_win32_063_and_earlier\

lib 目录下，运行 spicec.exe 即可。

原文：http://os.51cto.com/art/201201/311464.htm

http://www.spice-space.org/download.html


031




技巧Tips

031

为什么要尽量避免重启你的Unix服务器

Windows 管理员们往往把重启当成故障排查工作的首要步骤之一，而

Unix 团队则一般只在束手无策的情况下才进行尝试。

Unix服务器重启的两种情况

服务器重启操作应该极少出现。在这里我列举内核更新与硬件更换作

为例子，因为它们是 Unix 领域中引发重启的两大主要原因。有些人一直在

鼓吹什么不重启服务器的话会带来某些严重的安全风险，这简直是一派胡

言。如果服务项目与应用程序中确实存在安全风险，那么打上漏洞补丁就

能解决问题了，补丁往往不要求重启设备。而如果安全风险在内核模块中，

一般来说只需卸载对应模块、安装补丁，最后重新加载模块。没错，一旦内

核中存在安全风险，那么重启操作的确是必要的；但在这种情况之外，大家

根本没有切实的理由重新启动 Unix 服务器。

有些人认为如果不进行重启，其它形式的风险往往会接踵而至，如某些

关键性服务项目在开机时没有正确启动而导致一系列隐患。当然，这种说

法本身是正确的，但只有刚刚接掌服务器设备的菜鸟才会忘记正确设置服

务的启动参数。话说回来，如果大家的服务器正处于构建阶段，且其中还不

涉及任何生产方面的内容，那么不妨随意进行各类重启测试。这不会带来

任何不良影响，而且我认为这正是熟悉重启机制的最好时机。

但还有另一方面需要考虑：那些将重启操作当成故障排查重要步骤之一

的家伙是抱着死猪不怕开水烫的心态，打算一次性把问题都暴露出来。就

说一套已经出现问题的 Unix 设备吧，某些还处于运行中的服务项实际上已

经无法再次启动，而这一点在重启之后就会显现出来——也许是由于分段

故障或者其它稀奇古怪的原因。

造成Unix服务器重启的原因

如果我们只是简单查看几分钟之后就一拍脑门决定重启设备，那么也许

故障的真正原因就彻底湮没在时光中了——也许是某位初级管理员在运行

一套自己编写的愚蠢脚本时无意中删除了 /boot 目录或者 /etc、/usr/lib64

下的部分内容。这正是引发分段故障以及设备不稳定情况的罪魁祸首。然

而一旦我们直接重启服务器而没有深入挖掘问题，那么显然问题会变得更

加严重，接下来不出意外的话大家应该会启动恢复镜像——这就代表需要

面对大量恢复工作——而与此同时生产服务器也将陷入停机状态。

以上只是我们在 Unix 领域中应该尽量避免重启操作的原因之一。总之，

没人能利用 /var 分区重启设备就完全修正错误（另外请别提什么打开文件

句柄这类迂腐的蠢话——我想大家应该理解我的意思）。

服务器重启前请做完你该做的工作

在大多数情况下，不进行重启是极其重要的，因为系统中能够帮助我们

修复问题的关键性信息在重启前是一定存在的，但在重启后却未必还在。

今后大家在面对问题时，如果有某个家伙说什么“嘿，不如先重启一下看

看”，不妨直接给他两个大嘴巴。

原文：When in doubt, reboot? Not Unix boxes

译文：http://os.51cto.com/art/201112/310712.htm

文/Paul Venezia 编译/核子可乐



http://os.51cto.com

http://www.infoworld.com/t/unix/when-in-doubt-reboot-not-unix-boxes-061


招募启事《Linux 运维趋势》的建设需要您的加入！

您可以通过如下方式参与我们杂志的建设：

1、推荐文章

无论是您在互联网上看到的好文章，还是您自己总结 / 整理的资

料；无论是英文还是中文；无论是入门的还是高端的，都欢迎推荐！

您可以直接在《Linux 运维趋势》新浪微群中分享：

http://q.weibo.com/121303

2、投稿

如果您愿意与大家分享您技术经验的热诚，那么欢迎您的投稿！

原创或译文均可，稿件在 51CTO 首发可领取稿酬：）

投稿信箱：[email protected]

3、推广与意见

如果您喜欢我们的杂志，认为这本杂志对于您的工作有所帮助，请

向您的 Linux 好友、同事们推荐它！如果您觉得这份杂志还有什么地

方需要改进或补充，也希望您能够提出您的宝贵意见！

反馈可至《Linux 运维趋势》新浪微群：


或在新浪微博

@51CTO 系统频道

本刊发布日期：每个月的第二个星期五

您可以通过如下方式检查新刊发布：

1、电子邮件订阅：http://os.51cto.com/art/201011/233915.htm

2、RSS 订阅：http://www.51cto.com/php/rss.php?typeid=777

3、iPad 订阅：在《读览天下》客户端中可以搜索下载新刊到本地阅读！

本期杂志封面由 lazycai 制作

《Linux 运维趋势》是由 51CTO 系统频道策划、针对 Linux/Unix 系

统运维人员的一份电子杂志，内容从基础的技巧心得、实际操作案例

到中、高端的运维技术趋势与理念等均有覆盖。

《Linux 运维趋势》是开放的非盈利性电子杂志，其中所有内容均收

集整理自国内外互联网（包含 51CTO 系统频道本身的内容）。对于来

自国内的内容，编辑都会事先征求原作者的许可（八卦，趣闻 & 数字

栏目例外）。如果您认为本杂志的内容侵犯到了您的版权，可发信至

[email protected] 进行投诉。


mailto:yangsai%4051cto.com?subject=%E3%80%8ALinux%E8%BF%90%E7%BB%B4%E8%B6%8B%E5%8A%BF%E3%80%8B%E6%8A%95%E7%A8%BF%EF%BC%9A


http://weibo.com/51ctoos


http://www.51cto.com/php/rss.php?typeid=777

mailto:yangsai%4051cto.com?subject=%E3%80%8ALinux%E8%BF%90%E7%BB%B4%E8%B6%8B%E5%8A%BF%E3%80%8B%E6%8A%95%E8%AF%89%EF%BC%9A

linux运维趋势 第16期 cdn缓存系统

Technology

linux运维趋势第16期 cdn缓存系统