SlideShare a Scribd company logo
目录
杂志订阅 : http://os.51cto.com/art/201011/233915.htm   Index
《Linux 运维趋势》投稿信箱 : yangsai@51cto.com




 目录
           人物·People                                             技巧·工具·脚本·DBA
 003       Theo Schlossnagle谈监控,统计学与运维的本质                  023   MySQL性能优化教程之MySQL运维优化
           交流·Interact                                     026   建设一个靠谱的火车票网上订购系统
 007       服务器虚拟化:如何选择合适的模式?                               029   红帽虚拟桌面SPICE服务概述与安装指南
           八卦·News                                         031   为什么要尽量避免重启你的Unix服务器
 009       Hash冲突漏洞需修补 12306.cn引热议
           专题·Special
 011       web网站加速之CDN技术原理
 014       大型网站后台架构的web server与缓存
 016       Squid常用命令总结
 018       [CDN]动态内容的缓存技术 CSI,SSI,ESI
                                                            出版方 :
                                                                51CTO 系统频道(北京无忧创想信息技术有限公司)
 019       squid/varnish/ats简单测试                            杂志主编 :
                                                                 杨赛
 020       使用Nginx代替squid充当代理缓存服务器                          联系方法 :
                                                                 yangsai@51cto.com 010-68476606(分机 8035)
                                                            出版日期 :
                                                                 2012 年 1 月 13 日
                                                                    每月第 2 个星期五出版
                                                            订阅 :
                                                               http://os.51cto.com/art/201011/233915.htm




                                                   002                                    51CTO 系统频道 :
                                                                                                     http://os.51cto.com
人物
杂志订阅 : http://os.51cto.com/art/201011/233915.htm   People
《Linux 运维趋势》投稿信箱 : yangsai@51cto.com




Theo Schlossnagle谈监控,统计学与运维的本质
                                                                                                     采访整理/lazycai




                                                            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 做的仅限于提供一些数字——目前大部分系统
                                                          都是这样做的,它们被设计隔一段时间做一次检查,比如每隔一分钟做点什


                                                    003                                   51CTO 系统频道 :
                                                                                                     http://os.51cto.com
人物
杂志订阅 : http://os.51cto.com/art/201011/233915.htm             People
《Linux 运维趋势》投稿信箱 : yangsai@51cto.com



 么 动 作, 回 一 个 数 字。 而 现 实 中,
       返                   我                                                           51CTO :
                                                                                             运维工程师的工作,一直以来
 们面对的很多行为,好比硬盘读写的行                                  “以前你可能花6个小时在分发、打包、部署、            都无非是部署、监控、安全、备份、排障、
 为,它往往在每一秒内会执行成百上千                                 备份上面,而现在你可能只需要1个小时了。”             调优这些。您认为这方面的工作在未来
 次,所以如果我们能够仔细研究每一次                                                                   会有变化吗?
 读写的实际行为,通过这样对硬盘读写
 的理解,肯定要远远超过只是取一个每分钟的平均数。你想要了解最高值
 是什么,最低值是什么,你想要了解一个分布的情况,98% 或者 99% 的读
 写速度在一个什么值,如此这般。这个我认为是我们需要的。

    Cacti 相对好一些,它目前提供了一些基本的统计功能,你可以查看数据
 的标准偏差,但是其他的相关数据还很有限。


    51CTO :
          那么你们在 OmniTI 用的监控系统,是完全自己写的,不是通过其
 他监控系统修改的是吗?

    Theo :
         是的,我们完全自己写的整个监控系统。这个系统是开源的,而且
 监控数据写入数据库,你可以直接用来做统计分析,或者像很多专业数据分
 析人士做得一样,将数据抽取出来,放到比如 R 这样专业的统计工具当中
 去。用 R 来做统计相对高阶一些,但是很多时候我们通过借助手册的帮助,
 也可以很容易的做一些基本的分析。

    比如你在网站上放了 JavaScript 监控代码,它能够返回每次页面加载花
 费的时间。假设它放在那里跑了一天之后,收集到 1 亿次用户点击,也就是                                  Theo :
                                                                           我认为这些工作不会有太大的变化,只不过是有些工作变得越来
 1 亿个 PV。你想知道的情况是,页面加载的速度如何。如果给你一个 1 亿                              越简单了。备份数据,部署新的系统,我觉得这些方面的技术已经越来越好,
 次页面加载时间的平均数,这个肯定是没啥用的 ;
                       你想知道的是分布的情                                   越来越容易做。咱们每天工作按 8 小时来算,以前你可能花 6 个小时在分发、
 况,有多少次访问在 1 秒,有多少次访问在 10 秒,等等。这样就会收集到很                             打包、部署、备份这些工作上面,而现在你可能只需要 1 个小时了。这样下
 多数据点,你需要一个视图的方式明白的呈现出来这些数据代表了什么意                                   来,你就有更多时间考虑性能优化、资源规划这些事情——你以前在这些事
 思,那么这时候就可以用 R 语言。当然做这个也有其他的工具,但是 R 是最                              情上可能只有 1 小时的时间,但它实际上值得你花每天 8 小时。
 简单、最便宜的。


                                                              004                          51CTO 系统频道 :
                                                                                                      http://os.51cto.com
人物
杂志订阅 : http://os.51cto.com/art/201011/233915.htm            People
《Linux 运维趋势》投稿信箱 : yangsai@51cto.com



    51CTO :
          那您认为运维工程师这样的                                                               让 首 页 显 示 老 的 数 据” 最 后 一 个 SA
                                                                                                       。
 技术人员应该多花时间去了解业务吗?                                  “所以我觉得很多时候,是人们之间没有沟通             实在受不了了,问道 : 显示最新数据的
                                                                                               “

    Theo : 当然需要了。当然,
         哦,         他们不
                                                   清楚。”                              商 业 理 由 究 竟 是 什 么? 难 道 1 秒 之 前
                                                                                     的数据都不行吗? 客户反馈说 : 这个
                                                                                             ”      “
 需要了解所有的业务 ;
           不过他们至少需
                                                                                     啊, 秒钟当然是可以的啦。 所以最后,
                                                                                       1          ”
 要知道,自己管理的这些机器为什么在运转?我自己见过这样的事情 :
                                有
                                                                   60 台机器优化成了一台。
 一个系统在运行了好几年之后,才发现这个系统早就没有人在用了。那是
 一个数据仓库的业务。最开始你有一个数据库,以及一个数据仓库。后来,                                   所以我觉得很多时候,是人们之间没有沟通清楚。我们没有真正明白,
 又启动了一个新的数据仓库。所有用户从旧的数据仓库迁移到了一个新的                                  究竟为什么要跑这个应用软件。客户丢过来一个问题,我们就埋头解决这
 数据仓库,但是居然没有任何人通知系统管理员!所以旧的系统还一直在                                  个问题,启动机器,然后看到没人抱怨,我们就当作没问题了——这其中其
 跑着,磁盘阵列跑着,耗费着电力,还有一堆之前设计的自动化脚本在运转。                                实是很有问题的。
 系统管理员一直也没去看这个系统,以为还有人在用 ;
                         而业务方面的人则
                                                                     对于运维这个领域我一直是这样理解的 : (Operations)的本质是让
                                                                                       运维
 没有一个想起来要把旧的系统关掉。
                                                                   业务跑起来,而不是让系统或是一堆计算机跑起来,所以身为运维,必须要
                                                                   去了解业务。如果他们不去了解业务,那么他们就不会明白如何让业务最
    51CTO :
          难道系统管理员不会觉得奇怪吗?比如发现一直没有用户请求之                             优化的运行。在现实中,整个需求的传递往往是一条长链 :
                                                                                             业务需求传递
 类的。                                                               给产品经理,产品经理传递给软件工程师,软件工程师再传递给系统管理
    Theo : 这个系统很久以前就没有用户提需求的,
         哦,                  因为都完全自动化                              员……而到了这里,可能我们早就不知道真实的需求到底是什么了。我认
 了。在一个数据仓库系统里面处理的任务可能是将每天的销售数据打包存                                  为就是应该将最原始的需求拿出来,大家在一起讨论比较好。
 档,发邮件到某人的邮箱里面去。换了新系统之后,可能由于某种原因,也
一直没人去检查那个旧的邮箱,所以就这么一直跑着了。                                            51CTO :
                                                                           您的意思是我们要尽量减少这些中间人的存在吗?让用户的需求
                                                                   直接传达给实际干活儿的人?
    还有另外一种情况,比如带宽的使用。你购买了一定的带宽,但实际上
 未必需要用到那么多,不少企业对于这其中的成本浪费并不是特别明白。                                    Theo :
                                                                          我认为这是一个平衡的问题。在优秀的公司当中,整个链条是存
                                                                   在的,我们有产品经理,有专注交互的,有专注界面的,还有底层这些。我想
    还有另一个例子 :
            我们有一个客户,他们的首页一开始不用缓存,因为页
                                                                   说的是,从一开始,我们就需要来自软件工程师、系统管理员和 DBA 们的参
 面是动态显示数据的,客户说必须要让页面随时显示最新的数据,比如最热
                                                                   与,让他们参与“定义问题”的过程。大家聚在一个屋子里面各抒己见,才
 卖的产品之类的。因为客户坚持不用缓存,最初我们在架构设计中只好为
                                                                   能够更好的理解各自的观点。
 这个首页安排了 60 台机器。每次在软件工程师提出要为页面做缓存的时
 候,客户就大摇其头的否决 : 不行不行,
              “      我们必须要显示最新的数据,不能

                                                             005                             51CTO 系统频道 :
                                                                                                        http://os.51cto.com
人物
杂志订阅 : http://os.51cto.com/art/201011/233915.htm            People
《Linux 运维趋势》投稿信箱 : yangsai@51cto.com



    51CTO :
          您在早上提到了运维的职业                                                                           51CTO :
                                                                                                       那你们现在也会通过社交网
 发展需要向“多面化”的方向走,那您认                                 “他们了解如何从不同的角度思考,而且会在                       络等方式来寻找这样的人吗?
 为以后这个领域仍然会按照系统管理                                  凌晨3点起来排障。”                                    Theo :
                                                                                                      实话说吧,在招聘方面我们算
 员、运维、DBA 这些职业进行划分吗?
                                                                                               不上多成功。我们的员工都非常的优
    Theo : 职业细分这方面肯定还是不会变的。你很难在每个方面都成
         哦,                                                        秀,但是我们招聘的速度实在是跟不上需求。
 为专家的。所谓多面化的意思是这样的 :
                   在规模很大的公司里,尤其是在对
                                                                     社交网络方面,我们主要关注代码社区,比如 Github ;
                                                                                                 传统的 Job List 方
 性能优化非常关注的互联网公司,比如淘宝这样为这么多用户提供服务的
                                                                   法也在用,招聘网站什么的。反正是什么方法都用呗。
 网站,他们遇到的问题都是很难解决的问题,他们会需要对各方面都熟悉的
 人才。因为在一屋子的人都是较窄领域的专家的时候,他们很难去“越界”
                                                                     51CTO :
                                                                           最后一个问题。随着云计算的发展,人们预测外包业务将会越来
 的处理问题,因为缺乏在其他领域的能力。好比你遇到一个数据库的问题,
                                                                   越多。这种情况下,您认为系统运维的就业环境是否会变得越来越局限?
而这个问题如果你对数据库下面的操作系统有一定了解的话,可能会很容
易就发现问题所在了。                                                           Theo :
                                                                          这个我倒不完全这么认为。现在很多用云计算服务的主要还是小
                                                                   企业,他们的需求也就在 50 台到 100 台机器上下,在内部系统方面,肯定 IT

   51CTO :
         那好比 OmniTI 招聘的话,你会期待一个什么样的工程师?                            管理员是会减少的,因为像是搭建 Exchange 邮件服务或是配置电话交换机
                                                                   这种工作,放在哪个公司都差不多,外包在这个方向更有优势 ;
                                                                                               但是网站和
   Theo :
        这个问题真难……我们的话,首先会要求对方有很好的分析能力,
                                                                   Web 应用就不一样了,每一家网站的业务都是不一样的,有定制,有优化,不
能够按照严格的科学方法去发现问题,然后解决问题。你知道,有太多的人
                                                                   太可能交给外包就能直接搞定。你搞电子商务的,把网站外包出去运营能
会在还没了解问题的时候就急急忙忙的跑去解决问题。我面试过的很多人,
                                                                   行吗?我觉得是不行的,因为这样你就失去了你的差异竞争力。
他们之所以没有拿到这份工作正是因为这个原因。我会问他们一个问题,
比如“我们的网站很慢。你要怎么做? 而他们没有提出足够多的问题,
                 ”              而                                    所以我觉得以后会是这样 :
                                                                                 Exchange 这样的同质化服务会趋向于外包 ;

 是直接开始说“我会这样这样做”等等。他们根本连问题是什么样子的都                                  小规模的网站会采用相对通用的云服务而不专门聘请一个 SA ;
                                                                                                而对于有一

 没搞明白。而相比之下,那些更善于挖掘问题的应聘者——他们往往是相                                  定规模的网站,即使他们的业务是托管在云平台上运行的,他们也仍会需要

 对不那么聪明的一群人——往往能够给出更好的答案。                                          一些了解企业业务的 SA——他们了解如何从不同的角度思考,而且会在凌
                                                                   晨 3 点起来排障。他们可能会跟软件工程师这个岗位融合,但不管职位叫
    这是方法方面。第二就是,这个人必须愿意学习。这样的人真的非常难
                                                                   什么,这些网站仍然需要这样一批人。
 找!
                                                                     51CTO :
                                                                           好的,十分感谢您接受我们的采访!本次访谈到此结束。

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


                                                             006                                        51CTO 系统频道 :
                                                                                                                   http://os.51cto.com
交流
杂志订阅 : http://os.51cto.com/art/201011/233915.htm        Interact
《Linux 运维趋势》投稿信箱 : yangsai@51cto.com




 服务器虚拟化:如何选择合适的模式?
                                                                                                         文/Trevor Pott
                                                                                                         编译/核子可乐


    直连式虚拟化与分布式虚拟化,二者的冲突给意识形态带来了新的战                             所能得到的上限速度仅为 900MBps,而我自己的 SSD RAID 10 也只能带来
 场。                                                            2200MBps 的实际表现。不过 2200MBps 已经远胜 900MBps,这样的存储速
                                                               度优势已经极具价值。如果大家愿意为某台指定的虚拟机搭配多套虚拟网
    直连式虚拟化比较简单,就是一台服务器,配备着托管数套虚拟机的本
                                                               卡,那么速度还将进一步提升。
 地存储。它们利用由管理程序提供的 vSwitch 进行互相通信,而无需将数
 据包经过网卡发送至网络的每个角落。                                             困境

 讨论                                                                当将分布式的非主机设备引入余下的网络中时,这些虚拟机就要争夺有
                                                               限的带宽。如果我们有三十套虚拟机系统,那么为它们各自配备 10Gb 带宽,
   通常情况下,托管在直连方案中的虚拟机能够与处于主机系统之外的服
                                                               与只拿出一块 10Gb 带宽的网卡让它们共用、由物理交换机负责网络处理是
务器及客户机进行沟通,但大部分交
                                                                                   完全不同的感觉。
流仍然发生在同一套系统中的虚拟机
                                               “如果大家愿意为某台指定的虚拟机搭配多套
之间。                                                                                  如 果 仅 从 目 前 提 出 的 数 字 出 发, 么
                                                                                                               那
                                              虚拟网卡,那么速度还将进一步提升。”
                                                                                   分布式虚拟化看起来简直就是疯狂而不
   分布式虚拟化则完全不同。主机
                                                                                   可理喻的。但它仍然具备独特的优势。
服务器被尽可能当作一套整体的一次
性处理单元。存储资源采用集中式管理方案,并通过 SAN 中虚拟机与物理                                直连式虚拟化所无法实现的就是从一台主机上的虚拟机中迅速迁移至
交换机之间的通信被提供给多台主机。                                              另一台。虚拟机本身可能就体积庞大,因此通过网络实施迁移会耗费大量
                                                               时间。
   每种模式都有各种的局限性。
                                                                   但分布式虚拟化采用了集中式存储模式,不会遇到这个问题。不仅如此,
   直连式虚拟化速度快。每块 10Gb 网卡(目前 SAN 的标准接口)在理论
                                                               分布式虚拟化还允许我们对不同主机上处于运行状态的虚拟机系统进行实
上可以提供最大 1280MBps 的传输速度。而目前相当普遍的 PCIe 8x 2.0
                                                               时迁移。
RAID 卡理论上的传输速度更高达 4000MBps。
                                                                   高度的可用性是分布式虚拟化的另一大重要卖点。
   不过用在实际工作中就没那么乐观了。我在 10Gb 网 络附加存储系统上



                                                         007                                51CTO 系统频道 :
                                                                                                       http://os.51cto.com
交流
杂志订阅 : http://os.51cto.com/art/201011/233915.htm            Interact
《Linux 运维趋势》投稿信箱 : yangsai@51cto.com



    直连式虚拟化依靠强劲且具备高度                                                                                  存储的作法也开始出现。我最近就完
 容错性的虚拟主机来实现优秀的可用                                   “VEPA网卡自身所具备的能力足以被称为交                           成了一套部署,其中每台主机都拥有大
 性。分布式虚拟化则会在一台主机出                                  换机。”                                             量本地存储以辅助备份工作。
 现故障并重启时将所有虚拟机在集群
                                                                                                       每台主机都拥有一套虚拟备份设备
 中的其它主机上加以运行。使用的主机越多,分布式模式的优势就越明显。
                                                                 (简称 VBA) 其作用是为分配给该主机的虚拟机进行基于镜像的备份,
                                                                         ,                         并将
    分布式虚拟化的另一大优势是,尽管在传输速度上有所限制,但强制将                                镜像存储于本地缓冲驱动器中。这增加了备份速度。
 所有流量通过物理交换机处理使得网络管理具备更强的直观性及可管理
                                                                       中央 VBA 会从每台主机上读取备份内容,并不断将其转写至磁带上。磁
 性。
                                                                   带驱动器被直接从主机映射到 VBA 上,而不是作为从网络接入的设备。
 设计概念
                                                                       这种混合式处理方案尚未见诸白皮书,不过它的工作状态相当令人赞
    大家可以根据自己的需要选择合适的模式并加以部署,但这似乎还不能                                赏,只要再稍加改进,我一定会在未来的部署工作中再次加以使用。
 完全令人满意。基于创新的思维方式,混合虚拟化模式开始出现。
                                                                   进步无止境
    新 一 代 网 卡 已 经 开 始 模 糊 二 者 之 间 的 界 线, 中 至 关 重 要 的 一 环 是
                                        其
                                                                       新技术组合的不断引入使得任何一套虚拟化模式都无法长久保持不变。
 802.1Qbg 这 样 的 标 准(也 被 称 为 边 缘 虚 拟 桥) 或 虚 拟 以 太 网 端 口 聚 合
                                      ,
                                                                   目前最新的好方案是 IOMMU,它承诺为单独的虚拟机系统提供直接访问系
(VEPA)。
                                                                   统设备(例如显卡)的能力。
   VEPA 网卡自身所具备的能力足以被称为交换机。在使用中,主机上的
                                                                       虚拟机将有能力充分发挥 GPGPU 计算带来的强大性能,而处理速度的提
虚拟机绕过虚拟交换机,直接与网卡中集成的交换机对话。而网卡则能够
                                                                   升也会要求数据输入量达到光线通道传输能力的级别,这是分布式技术所
 与管理软件直接对话,这样一来我们就既拥有了分布式网络带来的种种优
                                                                   无法满足的。硬件容错能力的提高使单台主机方案更具可靠性,而新的网
 势,又不必担心由于所有虚拟机流量都被发往物理交换机而引起传输速度
                                                                   络技术则将带宽扩大至 40Gb、100Gb 甚至更高。
 瓶颈。
                                                                       到这里我们又说回起点。虚拟化始于大型机,而虚拟化又推动了 x86 在
    另一方面,802.1Qbh(也被称为桥口扩展或者 VN 标签)几乎完全是由
                                                                   采纳新技术的道路上渐行渐远,这使得台式机与大型机的运作方式越来越
 思科公司一手打造,它的使用需要对当前以太网规范加以延伸,即采用很多
                                                                   接近。
 新的硬件。
                                                                       原文 :
                                                                          Server virtualisation: How to pick the right model
   这与 VEPA 形成了鲜明的对比,因为 VEPA 并不需要我们更新网络设备。
                                                                       译文 :
                                                                          http://server.51cto.com/sCollege-306706.htm
   在同一台主机上通过差异化配置来实现同时使用直连式存储与分布式


                                                             008                                               51CTO 系统频道 :
                                                                                                                          http://os.51cto.com
八卦
杂志订阅 : http://os.51cto.com/art/201011/233915.htm                       News
《Linux 运维趋势》投稿信箱 : yangsai@51cto.com




 Hash冲突漏洞需修补 12306.cn引热议
                                                                                                         ——八卦,新闻与数字 2011.12 - 2012.01

    Nginx 的市场份额已经从今年年初的 5.9% 增长到了 10%,成为增长最                                    Linux 内核 3.2 正式版发布,改进了 EXT4 和 BTRFS 文件系统,改善延
 快的 Web 服务器。目前 Apache 仍占主导地位。                                                迟的 TCP 包恢复算法,增加了 CPU 带宽控制,允许存储空间过度配置。下
                                                                             载地址 :
    http://os.51cto.com/art/201112/310103.htm
                                                                               http://www.kernel.org/pub/linux/kernel/v3.0/
    Linux Deepin 11.12 发布,使用了 Gnone Shell 作为默认桌面环境,并在
 此基础上做了大量细节改进。                                                                 Fedora 工 程 筹 划 委 员 会 (FESCo) 近 日 举 行 会 议, 发 人 员 们 批 准 了
                                                                                                                        开
                                                                             Beefy Miracle Fedora 17 即将加入的几项关键新特性,包含 GNOME 3.4 和
    http://os.51cto.com/art/201112/310727.htm
                                                                             OpenStack 等。
    当前包括 PHP、Java、Ruby 在内的很多语言版本存在漏洞,攻击者可以通
                                                                               http://os.51cto.com/art/201201/312305.htm
 过构造 Hash 冲突实现拒绝服务攻击。各语言的漏洞补丁已陆续放出,请抓
 紧修补。                                                                          2012 年是阿兰·图灵诞生后的一百周年。为了纪念这位伟大的科学家,
                                                                             Scaruffi.com 的 创 始 人 Piero Scaruffi 在 最 近 分 享 了 一 个 83 页 的 幻 灯 片 :
    http://os.51cto.com/art/201112/310756.htm
                                                                             Alan Turing and the Programmable Universe,对阿兰·图灵的故事进行了
    12306.cn :
             这事儿聊的很多了,好文层出不穷 :                                               很精彩的解读。51CTO 特将这份幻灯片翻译过来,跟大家分享。
    http://os.51cto.com/art/201201/311396.htm                                  http://os.51cto.com/art/201201/312017.htm
    http://bbs.hpx-party.org/thread-8488-1-1.html

    http://hi.baidu.com/caoz/blog/item/f4f1d7caee09b558f21fe780.html                    【致歉声明】
    除了技术分析和针对招标、运量的分析之外,甚至还有往 SNS 方向拓展                                            15 期《虚拟化管理软件比较 -- 综合篇》一文的作者为蒋清野,
 的思路 :                                                                         刊中误打印成了“蒋清扬” 特此勘误,
                                                                                           ,     并向蒋清野先生致歉!

    http://blog.codingnow.com/2012/01/12306_sns.html                              蒋清野的博客 :
                                                                                         http://www.qyjohn.net/

    发现问题比没发现好,有争论比没人谈论好,在有机会讨论的时候多讨                                               蒋清野的微博 :
                                                                                         http://weibo.com/qyjohn
 论,才能在明年更容易拿到回家的火车票。


                                                                       009                                           51CTO 系统频道 :
                                                                                                                                http://os.51cto.com
专题
杂志订阅 : http://os.51cto.com/art/201011/233915.htm   Special
《Linux 运维趋势》投稿信箱 : yangsai@51cto.com




                  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 阀域



                                                    010                                51CTO 系统频道 :
                                                                                                  http://os.51cto.com
专题
杂志订阅 : http://os.51cto.com/art/201011/233915.htm   Special
《Linux 运维趋势》投稿信箱 : yangsai@51cto.com




 web网站加速之CDN技术原理
                                                                                                  文/北方人(@戒日祭)



    在不同地域的用户访问网站的响应速度存在差异,为了提高用户访问的                         过在现有的 Internet 中增加一层新的 CACHE( 缓存 ) 层,将网站的内容发布
 响应速度、优化现有 Internet 中信息的流动,需要在用户和服务器间加入中                    到最接近用户的网络 " 边缘 " 的节点,使用户可以就近取得所需的内容,提
 间层 CDN,使用户能以最快的速度,从最接近用户的地方获得所需的信息,                        高用户访问网站的响应速度。从技术上全面解决由于网络带宽小、用户访
 彻底解决网络拥塞,提高响应速度,是目前大型网站使用的流行的应用方                           问量大、网点分布不均等原因,提高用户访问网站的响应速度。
 案。
                                                             Cache 层的技术,消除数据峰值访问造成的结点设备阻塞。Cache 服务
 1. CDN 概述                                                  器具有缓存功能,所以大部分网页对象(Web page object) 如 html, htm,
                                                                                              ,
                                                            php 等页面文件,gif,tif,png,bmp 等图片文件,以及其他格式的文件,在有
    CDN 的全称是 Content Delivery Network,即内容分发网络。其目的是通
                                                            效期(TTL)内,对于重复的访问,不必从原始网站重新传送文件实体 , 只
                                                            需通过简单的认证(Freshness Validation) 传送几十字节的 Header,
                                                                                          -               即可
                                                            将本地的副本直接传送给访问者。由于缓存服务器通常部署在靠近用户端,
                                                            所以能获得近似局域网的响应速度,并有效减少广域带宽的消耗。不仅能
                                                            提高响应速度,节约带宽,对于加速 Web 服务器,有效减轻源服务器的负载
                                                            是非常有效的。

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

                                                             客户端加速 : Cache 部署在网络出口处,把常访问的内容缓存在本地,
                                                            提高响应速度和节约带宽 ;

                                                             服务器加速 : Cache 部署在服务器前端,作为 Web 服务器的代理缓存
                                                            机,提高 Web 服务器的性能,加速访问速度

                                                             如果多台 Cache 加速服务器且分布在不同地域,需要通过有效地机制管
                                                            理 Cache 网络,引导用户就近访问 ( 比如通过 DNS 引导用户 ),全局负载均


                                                      011                                 51CTO 系统频道 :
                                                                                                     http://os.51cto.com
专题
杂志订阅 : http://os.51cto.com/art/201011/233915.htm   Special
《Linux 运维趋势》投稿信箱 : yangsai@51cto.com



 衡流量,这是 CDN 内容传输网络的基本思想。                                     LocalDNS 得到域名的授权 DNS 记录后 , 继续向域名授权 DNS 查询域名
                                                          的 ip 地址
    CDN 对网络的优化作用主要体现在如下几个方面  - 解决服务器端的
“第一公里”问题  - 缓解甚至消除了不同运营商之间互联的瓶颈造成                            域名授权 DNS 查询域名记录后,回应给 LocalDNS
 的影响  - 减轻了各省的出口带宽压力  - 缓解了骨干网的压力  -
                                                             LocalDNS 将得到的域名 ip 地址,回应给 用户端
 优化了网上热点内容的分布
                                                             用户得到域名 ip 地址后,访问站点服务器
 2. CDN 的工作原理
                                                             站点服务器应答请求,将内容返回给客户端 .
 2.1. 传统访问过程(未加速缓存服务)
                                                          2.2. CDN访问过程(使用缓存服务)
   我们先看传统的未加缓存服务的访问过程,以便了解 CDN 缓存访问方式
与未加缓存访问方式的差别 :                                               CDN 网络是在用户和服务器之间增加 Cache 层,主要是通过接管 DNS 实
                                                          现 , 将用户的请求引导到 Cache 上获得源服务器的数据

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




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

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

   LocalDNS 向 ROOT DNS 查询域名的授权服务器 ( 这里假设 LocalDNS
                                                             通过上图,我们可以了解到,使用了 CDN 缓存后的网站的访问过程变为 :
缓存过期 )
                                                             用户输入访问的域名 , 操作系统向 LocalDNS 查询域名的 ip 地址 .
   ROOT DNS 将域名授权 DNS 记录回应给 LocalDNS
                                                             LocalDNS 向 ROOT DNS 查询域名的授权服务器 ( 这里假设 LocalDNS

                                                    012                                  51CTO 系统频道 :
                                                                                                    http://os.51cto.com
专题
杂志订阅 : http://os.51cto.com/art/201011/233915.htm   Special
《Linux 运维趋势》投稿信箱 : yangsai@51cto.com



 缓存过期 )                                                      由于它离用户更近,因而响应时间必然更快 .

    ROOT DNS 将域名授权 DNS 记录回应给 LocalDNS                        从上面图中 虚线圈起来的那块,就是 CDN 层 , 这层是位于 用户端 和
                                                          站点服务器之间 .
    LocalDNS 得到域名的授权 DNS 记录后 , 继续向域名授权 DNS 查询域名
 的 ip 地址                                                     智能调度 DNS( 比如 f5 的 3DNS)

    域名授权 DNS 查询域名记录后 ( 一般是 CNAME),回应给 LocalDNS               智能调度 DNS 是 CDN 服务中的关键系统 . 当用户访问加入 CDN 服务的
                                                          网站时,域名解析请求将最终由 智能调度 DNS 负责处理 .
    LocalDNS 得到域名记录后 , 向智能调度 DNS 查询域名的 ip 地址
                                                             它通过一组预先定义好的策略,将当时最接近用户的节点地址提供给用
    智能调度 DNS 根据一定的算法和策略 ( 比如静态拓扑,容量等 ), 将最
                                                          户,使用户可以得到快速的服务 .
 适合的 CDN 节点 ip 地址回应给 LocalDNS
                                                             同时它需要与分布在各地的 CDN 节点保持通信,跟踪各节点的健康状
    LocalDNS 将得到的域名 ip 地址,回应给 用户端
                                                          态 , 容量等,确保将用户的请求分配到就近可用的节点上 .
    用户得到域名 ip 地址后,访问站点服务器
                                                             缓存功能服务
    CDN 节点服务器应答请求,将内容返回给客户端 .( 缓存服务器一方面
                                                             负载均衡设备 ( 如 lvs,F5 的 BIG/IP)
 在本地进行保存,以备以后使用,二方面把获取的数据返回给客户端,完成
 数据服务过程 )                                                    内容 Cache 服务器 ( 如 squid)

    通过以上的分析我们可以得到,为了实现对普通用户透明 ( 使用缓存后                        共享存储 ( 根据缓存数据量多少决定是否需要 )
 用户客户端无需进行任何设置 ) 访问,需要使用 DNS( 域名解析 ) 来引导
                                                          3. CDN 智能调度DNS 实例分析(略,见原文)
 用户来访问 Cache 服务器,以实现透明的加速服务 . 由于用户访问网站的
 第一步就是 域名解析 , 所以通过修改 DNS 来引导用户访问是最简单有效                    4. CDN的 智能调度DNS 简化实现(略,见原文)

 的方式 .                                                    5. 总结(Summary)

 2.3. CDN网络的组成要素                                             在建立 CDN 网路时,最关键的就是 智能调度 DNS,这个是 CDN 网络总

    对于普通的 Internet 用户,每个 CDN 节点就相当于一个放置在它周围的              协调 , 通过高效的调度算法,可以使用户得到最佳的访问体验 .

 网站服务器 .                                                     其次就是 CDN 节点的管理 , 比如涉及到 内容的同步机制,配置文件的

    通过对 DNS 的接管,用户的请求被透明地指向离他最近的节点,节点中                    更新等等,都需要有一套机制来保证 .

 CDN 服务器会像网站的原始服务器一样,响应用户的请求 .                               原文 :
                                                                http://www.51know.info/system_performance/cdn/cdn.html

                                                    013                                          51CTO 系统频道 :
                                                                                                            http://os.51cto.com
专题
杂志订阅 : http://os.51cto.com/art/201011/233915.htm      Special
《Linux 运维趋势》投稿信箱 : yangsai@51cto.com




 大型网站后台架构的web server与缓存
                                                                                                                       文/凤凰舞者



    计算机系统中,缓存有很多种。比如 CPU 内部的一级缓存、二级缓存。                           (object)。
 文件系统的缓存,磁盘的缓存。在大型网站的后台部署过程中,也灵活运用
                                                                   (2)squid 通过查询表的方式来定位某个资源的位置。所查询的表有两
 了各级缓存。主要有客户端的浏览器缓存,服务器端的 web server 自身缓
                                                                 种,一种是 Hash table,一种是 Digest table。Hash table 记录着所有 Digest
 存,代理缓存,分布式缓存,数据库自身的缓存等。本节主要分析一下代理
                                                                 table 表信息,所以 Hash table 可以称之为目录或者提纲。而 Digest table 记
 缓存。
                                                                 录了磁盘上每个分区、每个目录里存放的缓存摘要,所以 Digest table 可以
 代理缓存                                                            称之为摘要或者索引。所以,Squid 接到请求后先查询 Hashtable,根据 Hash
                                                                 table 所指向的 Digest table,再查询所需要的文件。
    在网站后台架构中,代理缓存主要部署在 web server 之上,当用户对网
 站后台发起连接请求时,用户请求先到代理缓存中去查找,如果命中,则将                                 (3)squid 服务器存在两种工作关系,一种为 Child-Parent, child squid
                                                                                                         当
 请求返回给用户,如果没有命中,则代理缓存将请求发到 web server,然后                         server 没有用户需要的数据时,就向 parent squid server 发送请求,并持续
 web sever 将请求复制一份到代理缓存中,同时把请求返回给客户。                             等 待, 到 parent squid server 回 应 为 止 ; 一 种 为 Sibling, 本 地 squid
                                                                     直                              另               当
                                                                 server 没有用户请求的数据时,会向 sibling server 发送请求,如果 sibling
    常用的代理缓存有 varnish 和 squid。
                                                                 server 没有资料则会向上级 sibling 或者 internet 发送数据请求。
 Squid
                                                                   所以,综上所述,squid 运行模式如下 :
    Squid 是一个高性能的代理缓存服务器,可以用来加快浏览网页的速度,
                                                                   当 Squid Server 没有资料时,先向 Sibling 的 Squid Server 查询数据,如
 提高客户机的访问命中率。Squid 不仅支持 HTTP 协议,还支持 FTP、SSL、
                                                                 果 Sibling 没有,则跳过它直接向 Parent 查询,直到 Parent 提供资料为止 ( 如
 WAIS 等协议。Squid 用一个单独的、非模块化的、 驱动的进程来处理所
                             I/O
                                                                 果 Parent 没有资料,则到后端的 web server 上获取,当获取到数据后返回
 有的客户端请求。
                                                                 给用户的同时,保留一份在自身的缓存中 )。如果不存在 Parent, Squid
                                                                                                   则
    Squid 的原理如下 :                                                Server 自身到后端的 web server 上获取数据,当获取到数据后返回给用户
    (1) 每一台 squid 代理服务器上存有若干个颗磁盘。每颗磁盘又分割                         的同时,保留一份在自身的缓存中。如果还是不能得到数据,则向用户端回
 成 多 个 分 区, 一 个 分 区 又 可 建 立 很 多 目 录, 录 下 存 放 着 具 体 的 文 件
           每                        目                            复不能得到数据。



                                                           014                                         51CTO 系统频道 :
                                                                                                                  http://os.51cto.com
专题
杂志订阅 : http://os.51cto.com/art/201011/233915.htm            Special
《Linux 运维趋势》投稿信箱 : yangsai@51cto.com



 Varnish                                                                主进程 fork 子进程,主进程等待子进程的信号,子进程退出后,主进程重
                                                                       新启动子进程,子进程生成若干线程 :
    Varnish 是一款高性能的开源 HTTP 加速器,挪威最大的在线报纸 Verdens
 Gang 使用 3 台 Varnish 代替了原来的 12 台 Squid,性能比以前更好。                         (1)Accept 线程 :
                                                                                     接受请求,将请求挂在 overflow 队列上。

    Varnish 的作者 Poul-Henning Kamp 是 FreeBSD 内核开发者之一,他认为                 (2)Work 线程 :
                                                                                   有多个,负责从 overflow 队列上摘除请求,对请求进行处
 现在的计算机比起 1975 年已经复杂很多。在 1975 年时,存储媒介只有两                               理,直到完成,然后处理下一个请求。
 种:
  内存与硬盘。但现在计算机系统的内存除了主存外,还包括了 CPU 内
                                                                        (3)Epoll 线程 :
                                                                                    一个请求处理称为一个 session, session 周期内,
                                                                                                       在            处理
 的 L1L2L3 等 cache。因此 Squid Cache 自行处理物件替换的架构不可
                                                                       完请求后,会交给 Epoll 处理,监听是否还在事件发生。
 能得知这些情况而做到最佳化,但操作系统可以。所以这部分的工作应该
 交给操作系统处理,这就是 Varnish cache 设计架构 [4]。Varnish 将所有的                       (4)Expire 线程 :
                                                                                     对于缓存的 object,根据过期时间,组织成二叉堆,该线

 HTTP object 存于一个单独的大文件中,该文件在工作进程初始化的时候,                               程周期检查该堆得根,处理过期的文件。对过期的数据进行删除或重取操

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

 系统,具有分配、释放、修剪、
              合并内存等功能。                                                  Varnish 分配缓存机制 :

    Varnish 文件缓存的工作流程 :                                                 根据所读到的 object 大小,创建相应大小的缓存文件。为了读写方便,

    Varnish 与 一 般 服 务 器 软 件 类 似, 为 master 进 程 和 child 进 程。 其 中
                                分                                      程序将每个 object 的大小,转变为最接近其大小的内存页面倍数。然后从

 master 进程负责管理,child 进程负责 cache 工作。Master 进程读入命令,进                     现有的空闲存储结构体中查找,找到最合适的大小的空闲存储块,分配给

 行一些初始化,然后 fork 并监控 child 进程。Child 进程分配若干线程进行                          它。如果空闲块没有用完,则把多余的内存再组成一个空闲存储块,挂接到

 工作,主要包括管理线程和 worker 线程。如下图所示。                                         管理结构体上。如果缓存已满,则根据 LRU 算法,把旧的 object 释放掉。

                                                                        Varnish 释放缓存机制 :

                                                                        Expire 线程负责检测缓存中所有 object 的生存期 (TTL)。如果超过了设
                                                                       定的 TTL, object 没有被访问,
                                                                              该             则删除该 object,并释放内存。释放的过程
                                                                       会考虑内存的合并等操作。

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

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

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


                                                                 015                                           51CTO 系统频道 :
                                                                                                                          http://os.51cto.com
专题
杂志订阅 : http://os.51cto.com/art/201011/233915.htm           Special
《Linux 运维趋势》投稿信箱 : yangsai@51cto.com




 Squid常用命令总结
                                                                                                                     收集整理/NetSeek



 Squid安装设试命令:                                                        #/usr/local/squid/sbin/squid -k shutdown

    1,初始化你在 squid.conf 里配置的 cache 目录                                 这个不用解释吧。

    #/usr/local/squid/sbin/squid -z           // 初始化缓存空间             6,重引导修改过的 squid.conf

    如果有错误提示,请检查你的 cache 目录的权限。                                       #/usr/local/squid/sbin/squid -k reconfigure // 载入新的配置文件

    2,对你的 squid.conf 排错,即验证 squid.conf 的 语法和配置。                      这个估计用的时候比较多,当你发现你的配置有不尽你意的时候,可以
                                                                  随时修改 squid.conf,然后别忘记对你的 squid.conf 排错,然后再执行此指
    #/usr/local/squid/sbin/squid -k parse
                                                                  令,即可让 squid 重新按照你的 squid.conf 来运行。
    如果 squid.conf 有语法或配置错误,这里会返回提示你,如果没有返回,
                                                                     7./usr/local/squid/sbin/squid -k rotate 轮循日志
 恭喜,可以尝试启动 squid。
                                                                     8, squid 添加到系统启动项
                                                                       把
    3,在前台启动 squid,并输出启动过程。
                                                                     编辑 /etc/rc.d/rc.local
    #/usr/local/squid/sbin/squid -N -d1
                                                                     添加如下行 : /usr/local/squid/sbin/squid -s
    如果有 ready to server reques,恭喜,启动成功。
                                                                     利用 Runc 脚本 ........
    然后 ctrl + c,停止 squid,并以后台运行的方式启动它。
                                                                     再来点其他的。
    4,启动 squid 在后台运行。
                                                                     1,修改 cache 缓存目录的权限。
    #/usr/local/squid/sbin/squid -s
                                                                     #chown -R squid:squid /data/cache
    这时候可以 ps -A 来查看系统进程,可以看到两个 squid 进程。
                                                                     我的 cache 缓存目录是 /data/cache,squid 执行用户和用户组是 squid,
    5,停止 squid
                                                                  squid。


                                                            016                                            51CTO 系统频道 :
                                                                                                                      http://os.51cto.com
专题
杂志订阅 : http://os.51cto.com/art/201011/233915.htm                       Special
《Linux 运维趋势》投稿信箱 : yangsai@51cto.com



    2,修改 squid 日志目录的权限                                                             可以看到详细的性能情况 , 其中 PORT 是你的 proxy 的端口,5min 可以
                                                                                 是 60min
    #chown -R squid:squid /usr/local/squid/var/logs
                                                                                   取得 squid 运行状态信息 :
   这一步并不是适合每一个使用 squid 的用户 . 意为让 squid 有权限在该
 目录进行写操作 。                                                                         squidclient -p 80 mgr:info

    例如生成         access.log       cache.log        store.log                       * 取得 squid 内存使用情况 :

    3,查看你的日志文档。                                                                     squidclient -p 80 mgr:mem

    #more /usr/local/squid/var/logs/access.log | grep TCP_MEM_HIT                  * 取得 squid 已经缓存的列表 :

    该指令可以看到在 squid 运行过程中,有那些文件被 squid 缓存到内存中,                                       squidclient -p 80 mgrbjects. use it carefully,it may crash
 并返回给访问用户。
                                                                                   * 取得 squid 的磁盘使用情况 :
    #more /usr/local/squid/var/logs/access.log | grep TCP_HIT
                                                                                   squidclient -p 80 mgr:diskd
    该指令可以看到在 squid 运行过程中,有那些文件被 squid 缓存到 cache
                                                                                   * 强制更新某个 url :
 目录中,并返回给访问用户。
                                                                                   squidclient -p 80 -m PURGE http://www.yejr.com/static.php
    #more /usr/local/squid/var/logs/access.log | grep TCP_MISS
                                                                                   * 更多的请查看 :
    该指令可以看到在 squid 运行过程中,有那些文件没有被 squid 缓存,而
 是现重原始服务器获取并返回给访问用户。                                                               squidclient-h 或者 squidclient -p 80 mgr:

    关于 TCP_XXXX 等参数及代表的信息,请参看《squid 中文权威指南》                                        查命中率 :

 13.2.1 章节。                                                                        /usr/local/squid/bin/squidclient -h111.222.111.111 -p80 mgr:info

   当然,grep 的部分可以修改为其他的参数,例如你的域名                                www.xxxx.           /usr/local/squid/bin/squidclient -h 具体的 IP -p80 mgr:info
 com ,同样可以看到 access.log 里关于该域名的行。
                                                                                   原文 :
                                                                                      http://bbs.linuxtone.org/thread-137-1-1.html
 squid命中率分析
                                                                                   前面的安装调试部分来自 CU 的这个帖子。
    squid/bin/squidclient -p 80 mgr:info
                                                                                   相关链接 : Squid 中文权威指南》
                                                                                        《              在线阅读
    squid/bin/squidclient -p 80 mgr:5min

                                                                           017                                               51CTO 系统频道 :
                                                                                                                                        http://os.51cto.com
专题
杂志订阅 : http://os.51cto.com/art/201011/233915.htm       Special
《Linux 运维趋势》投稿信箱 : yangsai@51cto.com




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



    CDN 中动态内容是不太好解决的,通常需要很麻烦的技术和方法来实现                            目前 Squid 不支持。
 这些功能,比如我设计过一种动态缓存的方法,基于 session 栏接,然后根
                                                                  缺点 : 在语法上不能够直接包含其他服务器的 url,
                                                                     SSI                     只能在当前服务
 据热点来做动态缓存时间的控制。目前开放的实现 Cache 的技术主要有
                                                                 器上运行。所以通过 CDN 之类的 Cache 时,还是会失效,不灵活 .
 CSI,SSI,ESI 之类几种。在一个动态网页中 , 内容不断更新和变化,但这并
 不意味不能缓存,其实还是有 90% 的内容都可以做到 CDN                    中的。只要          3、Edge Side Includes (ESI) :

 花点心思。但这些都对客户有更加高的要需求。下面是这向种技术的介绍。                                Edge Side Includes(ESI) 和 Server Side Includes(SSI) 和功能类似。SSI

    动态 Cache 页面有如下一些方案 :                                         需要特殊的文件后缀 (shtml,inc)。ESI(Edge Side Include)通过使用简
                                                                 单的标记语言来对那些可以加速和不能加速的网页中的内容片断进行描
    1、Client Side Includes(CSI) :
                                                                 述,每个网页都被划分成不同的小部分分别赋予不同的缓存控制 策略,使
    通过 iframe、javascript、ajax 等方式将另外一个页面的内容动态包含进                 Cache 服务器可以根据这些策略在将完整的网页发送给用户之前将不同的
 来。这样来实现动态化。                                                     小部分动态地组合在一起。通过这种控制,可以有效地减少从服务器抓取
                                                                 整个 页面的次数,而只用从原服务器中提取少量的不能缓存的片断,因此
    优点 :
       能够利用浏览器客户端并行处理及装载的机制 ;
                            这种技术基本不
                                                                 可以有效降低原服务器的负载,同时提高用户访问的响应时间。
 需要服务器支持和修改,计算和操作放在客户端,能够降低服务器端压力
                                                                  优点 : ESI 更适合用于缓存服务器上,缓存整个页面或页面片段,因此
     缺点 :
        搜索引擎优化问题 ;
                 javascript 兼容性问题 ;
                                  客户端缓存可能导致
                                                                 ESI 特别适合用于缓存,CDN 的第一名的老大,Akamai 全力支持协议。对
 服务器端内容更新后不能及时生效。常常通过加 js version 来解决 .
                                                                 于布置和 Cache 都是最友好的。
    2、Server Side Includes(SSI) :
                                                                  缺点 : 出来很久,一直没有多少人使用。会这个技术的程序员不多。
    SSI 它就是 HTML 文件中,可以通过注释行调用的命令或指针。实现整
                                                                  原文 :
 个网站的内容更新。SSI 需要特殊的文件后缀 (shtml,inc).
                                                                  http://www.php-oa.com/2010/08/13/cdn-cache-csi-ssi-esi.html
    优点 : 技术是通用技术,
       SSI       不受具体语言限制,只需要 Web 服务器或应
 用服务器支持即可,Ngnix、Apache、Tomcat、Jboss 等对此都有较好的支持,


                                                           018                                         51CTO 系统频道 :
                                                                                                                  http://os.51cto.com
专题
杂志订阅 : http://os.51cto.com/art/201011/233915.htm                Special
《Linux 运维趋势》投稿信箱 : yangsai@51cto.com




 squid/varnish/ats简单测试
                                                                                                                                    文/三斗室



    简 单 的 试 试 varnish 和 apache traffic server。 跟 squid 进 行 一 下 对 比。     时间与 varnish 相近,响应时间 2.1ms。
 介于 varnish 和 ats 都是出现不太久的东西(至少是开源流行不长) 选择其
                                       ,
                                                                          从 trafficserver_shell 的 show:proxy_stats 和 show:cache_stats 命令结果
 最新开发版本测试,正巧都是 2.15 版。
                                                                        来看,缓存命中率 98%,磁盘 IO 几乎没有。可见其实都在内存中返回了。
    varnish 配置文件,只修改了 backend 到具体某台 nginx 发布点上。其他
                                                                          3、最后 squid2.7.9 :
                                                                                          -r900 时,fetch/sec 只有 880,响应时间 1.9ms ;
                                                                                                                              提
 都是反向代理缓存的标配。(可参考张宴博客和 varnish 权威指南)
                                                                        高到 -r1000 时,没有 wrong 报错,fetch/sec 下降到 850,响应时间 2.3ms ;
    ats 说明更少,从目前的资料看,修改了 records.config 中的监听,cache.                     另一个窗口的 netstat 命令直接卡住……
 config 遵 循 源 站 未 改,remap.config 添 加 了 map 一 条, 定 域 名 到 同 一 台
                                               绑
                                                                          squid 按照公司默认做法,缓存目录建在了 tmpfs 上。从 squidclient 来看,
 nginx 上。
                                                                        98% 的命中率中只有三分之一是直接通过 cache_mem 返回的,另三分之二
    注:
     varnish 和 ats 都没有修改缓存路径,即分别为 var/varnish/varnish.                  是通过 cache_dir 的 tmpfs 返回。
 cache 和 var/trafficserver,都是磁盘。
                                                                          另:
                                                                           最后 du -sh 查看三者的缓存目录大小,赫然发现 squid 的是 19M,
    然后从线上某台 squid2.7 上收集 www.domain.com 下的 html 页面 url                  ats 是 39M,varnish 是 41M。这个差别也是比较怪异的,值得后续研究……
 一共 164 条,存成 urllist。
                                                                          从这个简单测试结果看,squid 的稳定性依然没的说 :
                                                                                                     对于大多数情况来
    使用 http_load 进行测试。第一遍,先用 http_load -r 100 -s 10 完成                  说,是乐于见到这种宁愿响应慢点点也要保证响应正确的情况的 ;
                                                                                                     varnish
 cache 的加载 ;
           第二遍改用 -r 1000 -s 60 进行测试。                                    在大批量回源时对后端服务器的冲击,显然比较让人担心 ; 和 varnish 具
                                                                                                  ats
                                                                        有同样高效的响应速度(和高压下的错误……) 而且其详细到甚至稍显繁
                                                                                             ,
    1、 是 varnish : 另 一 个 窗 口 看 netstat, 现 在 第 一 次 加 载 的 时 候,
      先           开                    发
                                                                        琐的那堆 config 文件的配置格式,相比 varnish 来说,更加贴近运维人员。
 varnish 启动了相当多的链接到后端 nginx 请求数据!第二遍时,-r1000 一
 直在刷 wrong,修改成 -r900 就没有问题。最后的报告显示 fetch/sec 还略                           原    文:
                                                                                http://chenlinux.com/2011/03/15/simple-test-between-
 大于指定的 900 达到 990,建连时间平均 1.3ms,响应时间 1.8ms。                              squid-varnish-ats.html

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


                                                                  019                                            51CTO 系统频道 :
                                                                                                                            http://os.51cto.com
专题
杂志订阅 : http://os.51cto.com/art/201011/233915.htm                             Special
《Linux 运维趋势》投稿信箱 : yangsai@51cto.com




 使用Nginx代替squid充当代理缓存服务器
                                                                                                                                                    文/崔晓辉

    我的博客是 CentOS+nginx+php+mysql+eaccelerator 这种架构。只有一                                  worker_connections 65535;
 台服务器,所以想到用在让两个 nginx 分别监听 IP:80 和 127.0.0.1:80。                                        }
                                                                                        http
   1. 安装 nginx 和 nginx_cache_Purge.
                                                                                        {
   wget http://labs.frickle.com/files/ngx_cache_purge-1.1.tar.gz
                                                                                        include mime.types;
   tar zxvf ngx_cache_purge-1.1.tar.gz
                                                                                        default_type application/octet-stream;
   wget http://nginx.org/download/nginx-0.8.47.tar.gz
                                                                                        charset gbk;
   tar zxvf nginx-0.8.47.tar.gz
                                                                                        #source_charset gbk;
   cd nginx-0.8.47/
                                                                                        server_names_hash_bucket_size 128;
   ./configure --prefix=/usr/local/nginx --user=www --group=www --add-
                                                                                        client_header_buffer_size 32k;
       module=ngx_cache_purge-1.1 --with-http_stub_status_module --with-http_
                                                                                        large_client_header_buffers 4 32k;
       ssl_module
                                                                                        client_max_body_size 300m;
   make -j2 && make install
                                                                                        sendfile on;
   cd ../
                                                                                        tcp_nopush on;
   2.nginx 配置
                                                                                        keepalive_timeout 60;
   cat /usr/local/nginx/conf/nginx.conf
                                                                                        tcp_nodelay on;
   user www www;
                                                                                        client_body_buffer_size 512k;
   worker_processes 1;
                                                                                        proxy_connect_timeout 5;
   error_log /usr/local/nginx/logs/nginx_error.log crit;
                                                                                        proxy_read_timeout 60;
   pid /usr/local/nginx/nginx.pid;
                                                                                        proxy_send_timeout 5;
   #Specifies the value for maximum file descriptors that can be opened by this
                                                                                        proxy_buffer_size 16k;
       process.
                                                                                        proxy_buffers 4 64k;
   worker_rlimit_nofile 65535;
                                                                                        proxy_busy_buffers_size 128k;
   events
                                                                                        proxy_temp_file_write_size 128k;
   {
                                                                                        gzip on;
   use epoll;

                                                                                  020                                            51CTO 系统频道 :
                                                                                                                                            http://os.51cto.com
专题
杂志订阅 : http://os.51cto.com/art/201011/233915.htm                               Special
《Linux 运维趋势》投稿信箱 : yangsai@51cto.com



    gzip_min_length 1k;                                                                  proxy_pass http://backend_server;
    gzip_buffers 4 16k;                                                                  add_header X-Cache HIT-FreeBSDSYSTEM.org;
    gzip_http_version 1.1;                                                               expires 1d;
    gzip_comp_level 2;                                                                   }
    gzip_types text/plain application/x-javascript text/css application/xml;             location ~ /purge(/.*)
    gzip_vary on;                                                                        {
    proxy_temp_path /home/proxy_temp_dir;                                                allow 127.0.0.1;
    proxy_cache_path /home/proxy_cache_dir levels=1:2 keys_zone=cache_                   allow 219.146.0.0/16;
        one:200m inactive=1d max_size=30g;                                               deny all;
                                                                                         proxy_cache_purge cache_one $host$1$is_args$args;
    upstream backend_server {                                                            }
    server 127.0.0.1:80 weight=1 max_fails=2 fail_timeout=30s;                           location ~ .*.(php|jsp|cgi)?$
    # 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;                      proxy_set_header Host $host;
    }                                                                                    proxy_set_header X-Forwarded-For $remote_addr;
    server                                                                               proxy_pass http://backend_server;
    {                                                                                    }
    listen 222.134.x.x:80;                                                               access_log off;
    server_name www.freebsdsystem.org blog.freebsdsystem.org freebsdsystem.              }
        org;                                                                             server
    index index.html index.htm index.php;                                                {
    root /usr/local/AUTOLEMP/www/www.freebsdsystem.org;                                  listen 222.134.66.153:80;
    location /                                                                           server_name www.huaanjiuyuan.com;
    {                                                                                    index index.html index.htm index.php;
    proxy_next_upstream http_502 http_504 error timeout invalid_header;                  root /usr/local/AUTOLEMP/www/wwwroot;
    proxy_cache cache_one;                                                               location /
    proxy_cache_valid 200 304 12h;                                                       {
    proxy_cache_key $host$uri$is_args$args;                                              proxy_next_upstream http_502 http_504 error timeout invalid_header;
    proxy_set_header Host $host;                                                         proxy_cache cache_one;
    proxy_set_header X-Forwarded-For $remote_addr;                                       proxy_cache_valid 200 304 12h;


                                                                                021                                                    51CTO 系统频道 :
                                                                                                                                                  http://os.51cto.com
专题
杂志订阅 : http://os.51cto.com/art/201011/233915.htm                 Special
《Linux 运维趋势》投稿信箱 : yangsai@51cto.com



    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;                                       大话IT第20期:
    add_header X-Cache HIT-FreeBSDSYSTEM.org;
    expires 1d;
    }
                                                                                    当Windows8遇上Linux控
    location ~ /purge(/.*)                                                    本 期 节 目 不 但 有 微 软 最 新 的 Windows 8 操 作 系 统 登 场, 有
                                                                                                                            还
    {                                                                       Fedora16、Ubuntu 11.10、OpenSUSE 11.4 出马,更有最近密码泄漏事
    allow 127.0.0.1;
                                                                            件频发而被人关注的 keepass 工具……
    allow 219.146.0.0/16;
    deny all;                                                                 三位编辑分别在用 Linux 做什么?
    proxy_cache_purge cache_one $host$1$is_args$args;
                                                                              Windows8 又有啥特别的?
    }
    location ~ .*.(php|jsp|cgi)?$                                            敬请收看本期的大话 IT。
    {
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $remote_addr;                            在线观看 :
    proxy_pass http://backend_server;
                                                                              http://os.51cto.com/art/201112/310499.htm
    }
    access_log off;                                                           IT 听听看官方微博 :
    }
                                                                              http://weibo.com/itttkan
    }
    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



                                                                      022                                        51CTO 系统频道 :
                                                                                                                            http://os.51cto.com
运维DBA
杂志订阅 : http://os.51cto.com/art/201011/233915.htm    Database
《Linux 运维趋势》投稿信箱 : yangsai@51cto.com




 MySQL性能优化教程之MySQL运维优化
                                                                                                              文/caoz




 存储引擎类型                                                         	如果前端请求重复度较高,无应用层缓存,query cache 是一个很
                                                                  好的偷懒选择
    	Myisam 速度快,响应快。表级锁是致命问题。
                                                                  	对于中等以下规模数据库应用,偷懒不是一个坏选择。
    	Innodb 目前主流存储引擎
                                                                  	如果确认使用 query cache,记得定时清理碎片,flush query
        	行级锁
                                                                    cache.
            	务必注意影响结果集的定义是什么
                                                               	要考虑到现实的硬件资源和瓶颈分布
    行级锁会带来更新的额外开销,但是通常情况下是值得的。
                                                               	学会理解热点数据,并将热点数据尽可能内存化
        	事务提交
                                                                	所谓热点数据,就是最多被访问的数据。
            	 i/o 效率提升的考虑
              对
                                                                	通常数据库访问是不平均的,少数数据被频繁读写,而更多数据
            	对安全性的考虑                                             鲜有读写。

    	HEAP 内存引擎                                                 	学会制定不同的热点数据规则,并测算指标。

        	频繁更新和海量读取情况下仍会存在锁定状况                                    	热点数据规模,理论上,热点数据越少越好,这样可以更好的
 内存使用考量                                                             满足业务的增长趋势。

    	理论上,内存越大,越多数据读取发生在内存,效率越高                                   	响应满足度,对响应的满足率越高越好。

    	Query cache 的使用                                             	比如依据最后更新时间,总访问量,回访次数等指标定义热
                                                                    点数据,并测算不同定义模式下的热点数据规模
        	如果前端请求重复度不高,或者应用层已经充分缓存重复请求,
            query cache 不必设置很大,甚至可以不设置。


                                                      023                                51CTO 系统频道 :
                                                                                                    http://os.51cto.com
运维DBA
杂志订阅 : http://os.51cto.com/art/201011/233915.htm      Database
《Linux 运维趋势》投稿信箱 : yangsai@51cto.com



 性能与安全性考量                                                           •	 binlog 文件是顺序写

    	数据提交方式                                                        •	 淘宝数据库存储优化是这样处理的

        	innodb_flush_log_at_trx_commit = 1 每次自动提交,安全性高,         	部分安全要求不高的写入操作可以用 /dev/shm 分区存储,简单变
            i/o 压力大                                                 成内存写。

        	innodb_flush_log_at_trx_commit = 2 每秒自动提交,安全性略          	多块物理硬盘做 raid10,可以提升写入能力
            有影响, 承载强。
                i/o
                                                                  	关键存储设备优化,善于比对不同存储介质的压力测试数据。
    	日志同步
                                                                    •	 例如 fusion-io 在新浪和淘宝都有较多使用。
        	Sync-binlog =1 每条自动更新,安全性高, 压力大
                                     i/o
                                                                  	涉及必须存储较为庞大的数据量时
        	Sync-binlog = 0 根据缓存设置情况自动更新,存在丢失数据
                                                                    •	 压缩存储,可以通过增加 cpu 开销(压缩算法)减少 i/o 压力。前
            和同步延迟风险, 承载力强。
                    i/o
                                                                      提是你确认 cpu 相对空闲而 i/o 压力很大。 新浪微博就是压缩
        	个人建议保存 binlog 日志文件,便于追溯 更新操作和系统恢复。                          存储的典范。

        	如对日志文件的 i/o 压力有担心,在内存宽裕的情况下,可考虑                           •	 通过 md5 去重存储,案例是 QQ 的文件共享,以及 dropbox 这样
            将 binlog 写入到诸如 /dev/shm 这样的内存映射分区,并定时                     的共享服务,如果你上传的是一个别人已有的文件,计算 md5 后,
            将旧有的 binlog 转移到物理硬盘。                                      直接通过 md5 定位到原有文件,这样可以极大减少存储量。涉
                                                                      及文件共享,头像共享,相册等应用,通过这种方法可以减少超过
    	性能与安全本身存在相悖的情况,需要在业务诉求层面决定取舍
                                                                      70% 的存储规模,对硬件资源的节省是相当巨大的。缺点是,删
        	学会区分什么场合侧重性能,什么场合侧重安全                                       除文件需要甄别该 md5 是否有其他人使用。 去重存储,用户量

        	学会将不同安全等级的数据库用不同策略管理                                        越多,上传文件越多,效率越高!

 存储/写入压力优化                                                          •	 文件尽量不要存储到数据库内。尽量使用独立的文件系统存储,
                                                                      该话题不展开。
    	顺序读写性能远高于随机读写
                                                                 运维监控体系
    	将顺序写数据和随机读写数据分成不同的物理磁盘进行,有助于 i/
        o 压力的疏解                                                   	系统监控

        •	 数据库文件涉及索引等内容,写入是随即写                                      	服务器资源监控


                                                           024                              51CTO 系统频道 :
                                                                                                       http://os.51cto.com
Linux运维趋势 第16期 cdn缓存系统
Linux运维趋势 第16期 cdn缓存系统
Linux运维趋势 第16期 cdn缓存系统
Linux运维趋势 第16期 cdn缓存系统
Linux运维趋势 第16期 cdn缓存系统
Linux运维趋势 第16期 cdn缓存系统
Linux运维趋势 第16期 cdn缓存系统
Linux运维趋势 第16期 cdn缓存系统

More Related Content

Similar to Linux运维趋势 第16期 cdn缓存系统

Linux运维趋势 第0期 运维自动化
Linux运维趋势 第0期 运维自动化Linux运维趋势 第0期 运维自动化
Linux运维趋势 第0期 运维自动化
51CTO
 
51 cto linuxops_issue2
51 cto linuxops_issue251 cto linuxops_issue2
51 cto linuxops_issue2Yiwei Ma
 
Linux运维趋势 第14期 高性能电子商务网站
Linux运维趋势 第14期 高性能电子商务网站Linux运维趋势 第14期 高性能电子商务网站
Linux运维趋势 第14期 高性能电子商务网站
51CTO
 
《Linux运维趋势》2012年2月号:运维安全准则
《Linux运维趋势》2012年2月号:运维安全准则《Linux运维趋势》2012年2月号:运维安全准则
《Linux运维趋势》2012年2月号:运维安全准则
51CTO
 
微信201204
微信201204微信201204
微信201204drewz lin
 
微信之道201204
微信之道201204微信之道201204
微信之道201204shaomeng shi
 
数据中心操作系统浅析
数据中心操作系统浅析数据中心操作系统浅析
数据中心操作系统浅析
Li Jiansheng
 
做一个“懒惰”的程序员-LCP框架系列交流
做一个“懒惰”的程序员-LCP框架系列交流做一个“懒惰”的程序员-LCP框架系列交流
做一个“懒惰”的程序员-LCP框架系列交流
lichengdongdong
 
Virtual Datacenter
Virtual DatacenterVirtual Datacenter
Virtual Datacenter
LRYANG
 
20120524 App開發流程與小工具分享@UI Cafe
20120524 App開發流程與小工具分享@UI Cafe20120524 App開發流程與小工具分享@UI Cafe
20120524 App開發流程與小工具分享@UI CafeJustin Lee
 
Data Analyse Black Horse - ClickHouse
Data Analyse Black Horse - ClickHouseData Analyse Black Horse - ClickHouse
Data Analyse Black Horse - ClickHouse
Jack Gao
 
微服務對IT人員的衝擊
微服務對IT人員的衝擊微服務對IT人員的衝擊
微服務對IT人員的衝擊
Philip Zheng
 
易思捷云操作系统概述
易思捷云操作系统概述易思捷云操作系统概述
易思捷云操作系统概述
炳富 杨
 
Open Source community 2.0
Open Source community 2.0Open Source community 2.0
Open Source community 2.0OpenSourceCamp
 
大規模微服務導入 - #2 從零開始的微服務 .NET Core 框架設計
大規模微服務導入 - #2 從零開始的微服務 .NET Core 框架設計大規模微服務導入 - #2 從零開始的微服務 .NET Core 框架設計
大規模微服務導入 - #2 從零開始的微服務 .NET Core 框架設計
Andrew Wu
 
Youtube's Success Story - Case Study II (Python-based Company)
Youtube's Success Story - Case Study II (Python-based Company)Youtube's Success Story - Case Study II (Python-based Company)
Youtube's Success Story - Case Study II (Python-based Company)
Sting Chen
 
A Concept of Network Analysis Tool by Data Mining
A Concept of Network Analysis Tool by Data MiningA Concept of Network Analysis Tool by Data Mining
A Concept of Network Analysis Tool by Data Mining
Jhang Raymond
 
The way to continuous delivery
The way to continuous deliveryThe way to continuous delivery
The way to continuous delivery
Qiao Liang
 
IoT Cloud Platforms- Players, Vendors and Vertical Segments -20160519
IoT Cloud Platforms- Players, Vendors and Vertical Segments -20160519IoT Cloud Platforms- Players, Vendors and Vertical Segments -20160519
IoT Cloud Platforms- Players, Vendors and Vertical Segments -20160519
August Lin
 

Similar to Linux运维趋势 第16期 cdn缓存系统 (20)

Linux运维趋势 第0期 运维自动化
Linux运维趋势 第0期 运维自动化Linux运维趋势 第0期 运维自动化
Linux运维趋势 第0期 运维自动化
 
51 cto linuxops_issue2
51 cto linuxops_issue251 cto linuxops_issue2
51 cto linuxops_issue2
 
Linux运维趋势 第14期 高性能电子商务网站
Linux运维趋势 第14期 高性能电子商务网站Linux运维趋势 第14期 高性能电子商务网站
Linux运维趋势 第14期 高性能电子商务网站
 
《Linux运维趋势》2012年2月号:运维安全准则
《Linux运维趋势》2012年2月号:运维安全准则《Linux运维趋势》2012年2月号:运维安全准则
《Linux运维趋势》2012年2月号:运维安全准则
 
微信201204
微信201204微信201204
微信201204
 
微信之道201204
微信之道201204微信之道201204
微信之道201204
 
数据中心操作系统浅析
数据中心操作系统浅析数据中心操作系统浅析
数据中心操作系统浅析
 
做一个“懒惰”的程序员-LCP框架系列交流
做一个“懒惰”的程序员-LCP框架系列交流做一个“懒惰”的程序员-LCP框架系列交流
做一个“懒惰”的程序员-LCP框架系列交流
 
Virtual Datacenter
Virtual DatacenterVirtual Datacenter
Virtual Datacenter
 
20120524 App開發流程與小工具分享@UI Cafe
20120524 App開發流程與小工具分享@UI Cafe20120524 App開發流程與小工具分享@UI Cafe
20120524 App開發流程與小工具分享@UI Cafe
 
Data Analyse Black Horse - ClickHouse
Data Analyse Black Horse - ClickHouseData Analyse Black Horse - ClickHouse
Data Analyse Black Horse - ClickHouse
 
微服務對IT人員的衝擊
微服務對IT人員的衝擊微服務對IT人員的衝擊
微服務對IT人員的衝擊
 
易思捷云操作系统概述
易思捷云操作系统概述易思捷云操作系统概述
易思捷云操作系统概述
 
Hello openstack 2014
Hello openstack 2014Hello openstack 2014
Hello openstack 2014
 
Open Source community 2.0
Open Source community 2.0Open Source community 2.0
Open Source community 2.0
 
大規模微服務導入 - #2 從零開始的微服務 .NET Core 框架設計
大規模微服務導入 - #2 從零開始的微服務 .NET Core 框架設計大規模微服務導入 - #2 從零開始的微服務 .NET Core 框架設計
大規模微服務導入 - #2 從零開始的微服務 .NET Core 框架設計
 
Youtube's Success Story - Case Study II (Python-based Company)
Youtube's Success Story - Case Study II (Python-based Company)Youtube's Success Story - Case Study II (Python-based Company)
Youtube's Success Story - Case Study II (Python-based Company)
 
A Concept of Network Analysis Tool by Data Mining
A Concept of Network Analysis Tool by Data MiningA Concept of Network Analysis Tool by Data Mining
A Concept of Network Analysis Tool by Data Mining
 
The way to continuous delivery
The way to continuous deliveryThe way to continuous delivery
The way to continuous delivery
 
IoT Cloud Platforms- Players, Vendors and Vertical Segments -20160519
IoT Cloud Platforms- Players, Vendors and Vertical Segments -20160519IoT Cloud Platforms- Players, Vendors and Vertical Segments -20160519
IoT Cloud Platforms- Players, Vendors and Vertical Segments -20160519
 

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

  • 1.
  • 2. 目录 杂志订阅 : http://os.51cto.com/art/201011/233915.htm Index 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 目录 人物·People 技巧·工具·脚本·DBA 003 Theo Schlossnagle谈监控,统计学与运维的本质 023 MySQL性能优化教程之MySQL运维优化 交流·Interact 026 建设一个靠谱的火车票网上订购系统 007 服务器虚拟化:如何选择合适的模式? 029 红帽虚拟桌面SPICE服务概述与安装指南 八卦·News 031 为什么要尽量避免重启你的Unix服务器 009 Hash冲突漏洞需修补 12306.cn引热议 专题·Special 011 web网站加速之CDN技术原理 014 大型网站后台架构的web server与缓存 016 Squid常用命令总结 018 [CDN]动态内容的缓存技术 CSI,SSI,ESI 出版方 : 51CTO 系统频道(北京无忧创想信息技术有限公司) 019 squid/varnish/ats简单测试 杂志主编 : 杨赛 020 使用Nginx代替squid充当代理缓存服务器 联系方法 : yangsai@51cto.com 010-68476606(分机 8035) 出版日期 : 2012 年 1 月 13 日 每月第 2 个星期五出版 订阅 : http://os.51cto.com/art/201011/233915.htm 002 51CTO 系统频道 : http://os.51cto.com
  • 3. 人物 杂志订阅 : http://os.51cto.com/art/201011/233915.htm People 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com Theo Schlossnagle谈监控,统计学与运维的本质 采访整理/lazycai 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 做的仅限于提供一些数字——目前大部分系统 都是这样做的,它们被设计隔一段时间做一次检查,比如每隔一分钟做点什 003 51CTO 系统频道 : http://os.51cto.com
  • 4. 人物 杂志订阅 : http://os.51cto.com/art/201011/233915.htm People 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 么 动 作, 回 一 个 数 字。 而 现 实 中, 返 我 51CTO : 运维工程师的工作,一直以来 们面对的很多行为,好比硬盘读写的行 “以前你可能花6个小时在分发、打包、部署、 都无非是部署、监控、安全、备份、排障、 为,它往往在每一秒内会执行成百上千 备份上面,而现在你可能只需要1个小时了。” 调优这些。您认为这方面的工作在未来 次,所以如果我们能够仔细研究每一次 会有变化吗? 读写的实际行为,通过这样对硬盘读写 的理解,肯定要远远超过只是取一个每分钟的平均数。你想要了解最高值 是什么,最低值是什么,你想要了解一个分布的情况,98% 或者 99% 的读 写速度在一个什么值,如此这般。这个我认为是我们需要的。 Cacti 相对好一些,它目前提供了一些基本的统计功能,你可以查看数据 的标准偏差,但是其他的相关数据还很有限。 51CTO : 那么你们在 OmniTI 用的监控系统,是完全自己写的,不是通过其 他监控系统修改的是吗? Theo : 是的,我们完全自己写的整个监控系统。这个系统是开源的,而且 监控数据写入数据库,你可以直接用来做统计分析,或者像很多专业数据分 析人士做得一样,将数据抽取出来,放到比如 R 这样专业的统计工具当中 去。用 R 来做统计相对高阶一些,但是很多时候我们通过借助手册的帮助, 也可以很容易的做一些基本的分析。 比如你在网站上放了 JavaScript 监控代码,它能够返回每次页面加载花 费的时间。假设它放在那里跑了一天之后,收集到 1 亿次用户点击,也就是 Theo : 我认为这些工作不会有太大的变化,只不过是有些工作变得越来 1 亿个 PV。你想知道的情况是,页面加载的速度如何。如果给你一个 1 亿 越简单了。备份数据,部署新的系统,我觉得这些方面的技术已经越来越好, 次页面加载时间的平均数,这个肯定是没啥用的 ; 你想知道的是分布的情 越来越容易做。咱们每天工作按 8 小时来算,以前你可能花 6 个小时在分发、 况,有多少次访问在 1 秒,有多少次访问在 10 秒,等等。这样就会收集到很 打包、部署、备份这些工作上面,而现在你可能只需要 1 个小时了。这样下 多数据点,你需要一个视图的方式明白的呈现出来这些数据代表了什么意 来,你就有更多时间考虑性能优化、资源规划这些事情——你以前在这些事 思,那么这时候就可以用 R 语言。当然做这个也有其他的工具,但是 R 是最 情上可能只有 1 小时的时间,但它实际上值得你花每天 8 小时。 简单、最便宜的。 004 51CTO 系统频道 : http://os.51cto.com
  • 5. 人物 杂志订阅 : http://os.51cto.com/art/201011/233915.htm People 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 51CTO : 那您认为运维工程师这样的 让 首 页 显 示 老 的 数 据” 最 后 一 个 SA 。 技术人员应该多花时间去了解业务吗? “所以我觉得很多时候,是人们之间没有沟通 实在受不了了,问道 : 显示最新数据的 “ Theo : 当然需要了。当然, 哦, 他们不 清楚。” 商 业 理 由 究 竟 是 什 么? 难 道 1 秒 之 前 的数据都不行吗? 客户反馈说 : 这个 ” “ 需要了解所有的业务 ; 不过他们至少需 啊, 秒钟当然是可以的啦。 所以最后, 1 ” 要知道,自己管理的这些机器为什么在运转?我自己见过这样的事情 : 有 60 台机器优化成了一台。 一个系统在运行了好几年之后,才发现这个系统早就没有人在用了。那是 一个数据仓库的业务。最开始你有一个数据库,以及一个数据仓库。后来, 所以我觉得很多时候,是人们之间没有沟通清楚。我们没有真正明白, 又启动了一个新的数据仓库。所有用户从旧的数据仓库迁移到了一个新的 究竟为什么要跑这个应用软件。客户丢过来一个问题,我们就埋头解决这 数据仓库,但是居然没有任何人通知系统管理员!所以旧的系统还一直在 个问题,启动机器,然后看到没人抱怨,我们就当作没问题了——这其中其 跑着,磁盘阵列跑着,耗费着电力,还有一堆之前设计的自动化脚本在运转。 实是很有问题的。 系统管理员一直也没去看这个系统,以为还有人在用 ; 而业务方面的人则 对于运维这个领域我一直是这样理解的 : (Operations)的本质是让 运维 没有一个想起来要把旧的系统关掉。 业务跑起来,而不是让系统或是一堆计算机跑起来,所以身为运维,必须要 去了解业务。如果他们不去了解业务,那么他们就不会明白如何让业务最 51CTO : 难道系统管理员不会觉得奇怪吗?比如发现一直没有用户请求之 优化的运行。在现实中,整个需求的传递往往是一条长链 : 业务需求传递 类的。 给产品经理,产品经理传递给软件工程师,软件工程师再传递给系统管理 Theo : 这个系统很久以前就没有用户提需求的, 哦, 因为都完全自动化 员……而到了这里,可能我们早就不知道真实的需求到底是什么了。我认 了。在一个数据仓库系统里面处理的任务可能是将每天的销售数据打包存 为就是应该将最原始的需求拿出来,大家在一起讨论比较好。 档,发邮件到某人的邮箱里面去。换了新系统之后,可能由于某种原因,也 一直没人去检查那个旧的邮箱,所以就这么一直跑着了。 51CTO : 您的意思是我们要尽量减少这些中间人的存在吗?让用户的需求 直接传达给实际干活儿的人? 还有另外一种情况,比如带宽的使用。你购买了一定的带宽,但实际上 未必需要用到那么多,不少企业对于这其中的成本浪费并不是特别明白。 Theo : 我认为这是一个平衡的问题。在优秀的公司当中,整个链条是存 在的,我们有产品经理,有专注交互的,有专注界面的,还有底层这些。我想 还有另一个例子 : 我们有一个客户,他们的首页一开始不用缓存,因为页 说的是,从一开始,我们就需要来自软件工程师、系统管理员和 DBA 们的参 面是动态显示数据的,客户说必须要让页面随时显示最新的数据,比如最热 与,让他们参与“定义问题”的过程。大家聚在一个屋子里面各抒己见,才 卖的产品之类的。因为客户坚持不用缓存,最初我们在架构设计中只好为 能够更好的理解各自的观点。 这个首页安排了 60 台机器。每次在软件工程师提出要为页面做缓存的时 候,客户就大摇其头的否决 : 不行不行, “ 我们必须要显示最新的数据,不能 005 51CTO 系统频道 : http://os.51cto.com
  • 6. 人物 杂志订阅 : http://os.51cto.com/art/201011/233915.htm People 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 51CTO : 您在早上提到了运维的职业 51CTO : 那你们现在也会通过社交网 发展需要向“多面化”的方向走,那您认 “他们了解如何从不同的角度思考,而且会在 络等方式来寻找这样的人吗? 为以后这个领域仍然会按照系统管理 凌晨3点起来排障。” Theo : 实话说吧,在招聘方面我们算 员、运维、DBA 这些职业进行划分吗? 不上多成功。我们的员工都非常的优 Theo : 职业细分这方面肯定还是不会变的。你很难在每个方面都成 哦, 秀,但是我们招聘的速度实在是跟不上需求。 为专家的。所谓多面化的意思是这样的 : 在规模很大的公司里,尤其是在对 社交网络方面,我们主要关注代码社区,比如 Github ; 传统的 Job List 方 性能优化非常关注的互联网公司,比如淘宝这样为这么多用户提供服务的 法也在用,招聘网站什么的。反正是什么方法都用呗。 网站,他们遇到的问题都是很难解决的问题,他们会需要对各方面都熟悉的 人才。因为在一屋子的人都是较窄领域的专家的时候,他们很难去“越界” 51CTO : 最后一个问题。随着云计算的发展,人们预测外包业务将会越来 的处理问题,因为缺乏在其他领域的能力。好比你遇到一个数据库的问题, 越多。这种情况下,您认为系统运维的就业环境是否会变得越来越局限? 而这个问题如果你对数据库下面的操作系统有一定了解的话,可能会很容 易就发现问题所在了。 Theo : 这个我倒不完全这么认为。现在很多用云计算服务的主要还是小 企业,他们的需求也就在 50 台到 100 台机器上下,在内部系统方面,肯定 IT 51CTO : 那好比 OmniTI 招聘的话,你会期待一个什么样的工程师? 管理员是会减少的,因为像是搭建 Exchange 邮件服务或是配置电话交换机 这种工作,放在哪个公司都差不多,外包在这个方向更有优势 ; 但是网站和 Theo : 这个问题真难……我们的话,首先会要求对方有很好的分析能力, Web 应用就不一样了,每一家网站的业务都是不一样的,有定制,有优化,不 能够按照严格的科学方法去发现问题,然后解决问题。你知道,有太多的人 太可能交给外包就能直接搞定。你搞电子商务的,把网站外包出去运营能 会在还没了解问题的时候就急急忙忙的跑去解决问题。我面试过的很多人, 行吗?我觉得是不行的,因为这样你就失去了你的差异竞争力。 他们之所以没有拿到这份工作正是因为这个原因。我会问他们一个问题, 比如“我们的网站很慢。你要怎么做? 而他们没有提出足够多的问题, ” 而 所以我觉得以后会是这样 : Exchange 这样的同质化服务会趋向于外包 ; 是直接开始说“我会这样这样做”等等。他们根本连问题是什么样子的都 小规模的网站会采用相对通用的云服务而不专门聘请一个 SA ; 而对于有一 没搞明白。而相比之下,那些更善于挖掘问题的应聘者——他们往往是相 定规模的网站,即使他们的业务是托管在云平台上运行的,他们也仍会需要 对不那么聪明的一群人——往往能够给出更好的答案。 一些了解企业业务的 SA——他们了解如何从不同的角度思考,而且会在凌 晨 3 点起来排障。他们可能会跟软件工程师这个岗位融合,但不管职位叫 这是方法方面。第二就是,这个人必须愿意学习。这样的人真的非常难 什么,这些网站仍然需要这样一批人。 找! 51CTO : 好的,十分感谢您接受我们的采访!本次访谈到此结束。 原文 : http://os.51cto.com/art/201112/306406.htm 006 51CTO 系统频道 : http://os.51cto.com
  • 7. 交流 杂志订阅 : http://os.51cto.com/art/201011/233915.htm Interact 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 服务器虚拟化:如何选择合适的模式? 文/Trevor Pott 编译/核子可乐 直连式虚拟化与分布式虚拟化,二者的冲突给意识形态带来了新的战 所能得到的上限速度仅为 900MBps,而我自己的 SSD RAID 10 也只能带来 场。 2200MBps 的实际表现。不过 2200MBps 已经远胜 900MBps,这样的存储速 度优势已经极具价值。如果大家愿意为某台指定的虚拟机搭配多套虚拟网 直连式虚拟化比较简单,就是一台服务器,配备着托管数套虚拟机的本 卡,那么速度还将进一步提升。 地存储。它们利用由管理程序提供的 vSwitch 进行互相通信,而无需将数 据包经过网卡发送至网络的每个角落。 困境 讨论 当将分布式的非主机设备引入余下的网络中时,这些虚拟机就要争夺有 限的带宽。如果我们有三十套虚拟机系统,那么为它们各自配备 10Gb 带宽, 通常情况下,托管在直连方案中的虚拟机能够与处于主机系统之外的服 与只拿出一块 10Gb 带宽的网卡让它们共用、由物理交换机负责网络处理是 务器及客户机进行沟通,但大部分交 完全不同的感觉。 流仍然发生在同一套系统中的虚拟机 “如果大家愿意为某台指定的虚拟机搭配多套 之间。 如 果 仅 从 目 前 提 出 的 数 字 出 发, 么 那 虚拟网卡,那么速度还将进一步提升。” 分布式虚拟化看起来简直就是疯狂而不 分布式虚拟化则完全不同。主机 可理喻的。但它仍然具备独特的优势。 服务器被尽可能当作一套整体的一次 性处理单元。存储资源采用集中式管理方案,并通过 SAN 中虚拟机与物理 直连式虚拟化所无法实现的就是从一台主机上的虚拟机中迅速迁移至 交换机之间的通信被提供给多台主机。 另一台。虚拟机本身可能就体积庞大,因此通过网络实施迁移会耗费大量 时间。 每种模式都有各种的局限性。 但分布式虚拟化采用了集中式存储模式,不会遇到这个问题。不仅如此, 直连式虚拟化速度快。每块 10Gb 网卡(目前 SAN 的标准接口)在理论 分布式虚拟化还允许我们对不同主机上处于运行状态的虚拟机系统进行实 上可以提供最大 1280MBps 的传输速度。而目前相当普遍的 PCIe 8x 2.0 时迁移。 RAID 卡理论上的传输速度更高达 4000MBps。 高度的可用性是分布式虚拟化的另一大重要卖点。 不过用在实际工作中就没那么乐观了。我在 10Gb 网 络附加存储系统上 007 51CTO 系统频道 : http://os.51cto.com
  • 8. 交流 杂志订阅 : http://os.51cto.com/art/201011/233915.htm Interact 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 直连式虚拟化依靠强劲且具备高度 存储的作法也开始出现。我最近就完 容错性的虚拟主机来实现优秀的可用 “VEPA网卡自身所具备的能力足以被称为交 成了一套部署,其中每台主机都拥有大 性。分布式虚拟化则会在一台主机出 换机。” 量本地存储以辅助备份工作。 现故障并重启时将所有虚拟机在集群 每台主机都拥有一套虚拟备份设备 中的其它主机上加以运行。使用的主机越多,分布式模式的优势就越明显。 (简称 VBA) 其作用是为分配给该主机的虚拟机进行基于镜像的备份, , 并将 分布式虚拟化的另一大优势是,尽管在传输速度上有所限制,但强制将 镜像存储于本地缓冲驱动器中。这增加了备份速度。 所有流量通过物理交换机处理使得网络管理具备更强的直观性及可管理 中央 VBA 会从每台主机上读取备份内容,并不断将其转写至磁带上。磁 性。 带驱动器被直接从主机映射到 VBA 上,而不是作为从网络接入的设备。 设计概念 这种混合式处理方案尚未见诸白皮书,不过它的工作状态相当令人赞 大家可以根据自己的需要选择合适的模式并加以部署,但这似乎还不能 赏,只要再稍加改进,我一定会在未来的部署工作中再次加以使用。 完全令人满意。基于创新的思维方式,混合虚拟化模式开始出现。 进步无止境 新 一 代 网 卡 已 经 开 始 模 糊 二 者 之 间 的 界 线, 中 至 关 重 要 的 一 环 是 其 新技术组合的不断引入使得任何一套虚拟化模式都无法长久保持不变。 802.1Qbg 这 样 的 标 准(也 被 称 为 边 缘 虚 拟 桥) 或 虚 拟 以 太 网 端 口 聚 合 , 目前最新的好方案是 IOMMU,它承诺为单独的虚拟机系统提供直接访问系 (VEPA)。 统设备(例如显卡)的能力。 VEPA 网卡自身所具备的能力足以被称为交换机。在使用中,主机上的 虚拟机将有能力充分发挥 GPGPU 计算带来的强大性能,而处理速度的提 虚拟机绕过虚拟交换机,直接与网卡中集成的交换机对话。而网卡则能够 升也会要求数据输入量达到光线通道传输能力的级别,这是分布式技术所 与管理软件直接对话,这样一来我们就既拥有了分布式网络带来的种种优 无法满足的。硬件容错能力的提高使单台主机方案更具可靠性,而新的网 势,又不必担心由于所有虚拟机流量都被发往物理交换机而引起传输速度 络技术则将带宽扩大至 40Gb、100Gb 甚至更高。 瓶颈。 到这里我们又说回起点。虚拟化始于大型机,而虚拟化又推动了 x86 在 另一方面,802.1Qbh(也被称为桥口扩展或者 VN 标签)几乎完全是由 采纳新技术的道路上渐行渐远,这使得台式机与大型机的运作方式越来越 思科公司一手打造,它的使用需要对当前以太网规范加以延伸,即采用很多 接近。 新的硬件。 原文 : Server virtualisation: How to pick the right model 这与 VEPA 形成了鲜明的对比,因为 VEPA 并不需要我们更新网络设备。 译文 : http://server.51cto.com/sCollege-306706.htm 在同一台主机上通过差异化配置来实现同时使用直连式存储与分布式 008 51CTO 系统频道 : http://os.51cto.com
  • 9. 八卦 杂志订阅 : http://os.51cto.com/art/201011/233915.htm News 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com Hash冲突漏洞需修补 12306.cn引热议 ——八卦,新闻与数字 2011.12 - 2012.01 Nginx 的市场份额已经从今年年初的 5.9% 增长到了 10%,成为增长最 Linux 内核 3.2 正式版发布,改进了 EXT4 和 BTRFS 文件系统,改善延 快的 Web 服务器。目前 Apache 仍占主导地位。 迟的 TCP 包恢复算法,增加了 CPU 带宽控制,允许存储空间过度配置。下 载地址 : http://os.51cto.com/art/201112/310103.htm http://www.kernel.org/pub/linux/kernel/v3.0/ Linux Deepin 11.12 发布,使用了 Gnone Shell 作为默认桌面环境,并在 此基础上做了大量细节改进。 Fedora 工 程 筹 划 委 员 会 (FESCo) 近 日 举 行 会 议, 发 人 员 们 批 准 了 开 Beefy Miracle Fedora 17 即将加入的几项关键新特性,包含 GNOME 3.4 和 http://os.51cto.com/art/201112/310727.htm OpenStack 等。 当前包括 PHP、Java、Ruby 在内的很多语言版本存在漏洞,攻击者可以通 http://os.51cto.com/art/201201/312305.htm 过构造 Hash 冲突实现拒绝服务攻击。各语言的漏洞补丁已陆续放出,请抓 紧修补。 2012 年是阿兰·图灵诞生后的一百周年。为了纪念这位伟大的科学家, Scaruffi.com 的 创 始 人 Piero Scaruffi 在 最 近 分 享 了 一 个 83 页 的 幻 灯 片 : http://os.51cto.com/art/201112/310756.htm Alan Turing and the Programmable Universe,对阿兰·图灵的故事进行了 12306.cn : 这事儿聊的很多了,好文层出不穷 : 很精彩的解读。51CTO 特将这份幻灯片翻译过来,跟大家分享。 http://os.51cto.com/art/201201/311396.htm http://os.51cto.com/art/201201/312017.htm http://bbs.hpx-party.org/thread-8488-1-1.html http://hi.baidu.com/caoz/blog/item/f4f1d7caee09b558f21fe780.html 【致歉声明】 除了技术分析和针对招标、运量的分析之外,甚至还有往 SNS 方向拓展 15 期《虚拟化管理软件比较 -- 综合篇》一文的作者为蒋清野, 的思路 : 刊中误打印成了“蒋清扬” 特此勘误, , 并向蒋清野先生致歉! http://blog.codingnow.com/2012/01/12306_sns.html 蒋清野的博客 : http://www.qyjohn.net/ 发现问题比没发现好,有争论比没人谈论好,在有机会讨论的时候多讨 蒋清野的微博 : http://weibo.com/qyjohn 论,才能在明年更容易拿到回家的火车票。 009 51CTO 系统频道 : http://os.51cto.com
  • 10. 专题 杂志订阅 : http://os.51cto.com/art/201011/233915.htm Special 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 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 阀域 010 51CTO 系统频道 : http://os.51cto.com
  • 11. 专题 杂志订阅 : http://os.51cto.com/art/201011/233915.htm Special 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com web网站加速之CDN技术原理 文/北方人(@戒日祭) 在不同地域的用户访问网站的响应速度存在差异,为了提高用户访问的 过在现有的 Internet 中增加一层新的 CACHE( 缓存 ) 层,将网站的内容发布 响应速度、优化现有 Internet 中信息的流动,需要在用户和服务器间加入中 到最接近用户的网络 " 边缘 " 的节点,使用户可以就近取得所需的内容,提 间层 CDN,使用户能以最快的速度,从最接近用户的地方获得所需的信息, 高用户访问网站的响应速度。从技术上全面解决由于网络带宽小、用户访 彻底解决网络拥塞,提高响应速度,是目前大型网站使用的流行的应用方 问量大、网点分布不均等原因,提高用户访问网站的响应速度。 案。 Cache 层的技术,消除数据峰值访问造成的结点设备阻塞。Cache 服务 1. CDN 概述 器具有缓存功能,所以大部分网页对象(Web page object) 如 html, htm, , php 等页面文件,gif,tif,png,bmp 等图片文件,以及其他格式的文件,在有 CDN 的全称是 Content Delivery Network,即内容分发网络。其目的是通 效期(TTL)内,对于重复的访问,不必从原始网站重新传送文件实体 , 只 需通过简单的认证(Freshness Validation) 传送几十字节的 Header, - 即可 将本地的副本直接传送给访问者。由于缓存服务器通常部署在靠近用户端, 所以能获得近似局域网的响应速度,并有效减少广域带宽的消耗。不仅能 提高响应速度,节约带宽,对于加速 Web 服务器,有效减轻源服务器的负载 是非常有效的。 根据加速对象不同,分为 客户端加速 和 服务器加速 客户端加速 : Cache 部署在网络出口处,把常访问的内容缓存在本地, 提高响应速度和节约带宽 ; 服务器加速 : Cache 部署在服务器前端,作为 Web 服务器的代理缓存 机,提高 Web 服务器的性能,加速访问速度 如果多台 Cache 加速服务器且分布在不同地域,需要通过有效地机制管 理 Cache 网络,引导用户就近访问 ( 比如通过 DNS 引导用户 ),全局负载均 011 51CTO 系统频道 : http://os.51cto.com
  • 12. 专题 杂志订阅 : http://os.51cto.com/art/201011/233915.htm Special 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 衡流量,这是 CDN 内容传输网络的基本思想。 LocalDNS 得到域名的授权 DNS 记录后 , 继续向域名授权 DNS 查询域名 的 ip 地址 CDN 对网络的优化作用主要体现在如下几个方面  - 解决服务器端的 “第一公里”问题  - 缓解甚至消除了不同运营商之间互联的瓶颈造成 域名授权 DNS 查询域名记录后,回应给 LocalDNS 的影响  - 减轻了各省的出口带宽压力  - 缓解了骨干网的压力  - LocalDNS 将得到的域名 ip 地址,回应给 用户端 优化了网上热点内容的分布 用户得到域名 ip 地址后,访问站点服务器 2. CDN 的工作原理 站点服务器应答请求,将内容返回给客户端 . 2.1. 传统访问过程(未加速缓存服务) 2.2. CDN访问过程(使用缓存服务) 我们先看传统的未加缓存服务的访问过程,以便了解 CDN 缓存访问方式 与未加缓存访问方式的差别 : CDN 网络是在用户和服务器之间增加 Cache 层,主要是通过接管 DNS 实 现 , 将用户的请求引导到 Cache 上获得源服务器的数据 下面让我们看看访问使用 CDN 缓存后的网站的过程 : 由上图可见,用户访问未使用 CDN 缓存网站的过程为 : 用户输入访问的域名 , 操作系统向 LocalDNS 查询域名的 ip 地址 . LocalDNS 向 ROOT DNS 查询域名的授权服务器 ( 这里假设 LocalDNS 通过上图,我们可以了解到,使用了 CDN 缓存后的网站的访问过程变为 : 缓存过期 ) 用户输入访问的域名 , 操作系统向 LocalDNS 查询域名的 ip 地址 . ROOT DNS 将域名授权 DNS 记录回应给 LocalDNS LocalDNS 向 ROOT DNS 查询域名的授权服务器 ( 这里假设 LocalDNS 012 51CTO 系统频道 : http://os.51cto.com
  • 13. 专题 杂志订阅 : http://os.51cto.com/art/201011/233915.htm Special 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 缓存过期 ) 由于它离用户更近,因而响应时间必然更快 . ROOT DNS 将域名授权 DNS 记录回应给 LocalDNS 从上面图中 虚线圈起来的那块,就是 CDN 层 , 这层是位于 用户端 和 站点服务器之间 . LocalDNS 得到域名的授权 DNS 记录后 , 继续向域名授权 DNS 查询域名 的 ip 地址 智能调度 DNS( 比如 f5 的 3DNS) 域名授权 DNS 查询域名记录后 ( 一般是 CNAME),回应给 LocalDNS 智能调度 DNS 是 CDN 服务中的关键系统 . 当用户访问加入 CDN 服务的 网站时,域名解析请求将最终由 智能调度 DNS 负责处理 . LocalDNS 得到域名记录后 , 向智能调度 DNS 查询域名的 ip 地址 它通过一组预先定义好的策略,将当时最接近用户的节点地址提供给用 智能调度 DNS 根据一定的算法和策略 ( 比如静态拓扑,容量等 ), 将最 户,使用户可以得到快速的服务 . 适合的 CDN 节点 ip 地址回应给 LocalDNS 同时它需要与分布在各地的 CDN 节点保持通信,跟踪各节点的健康状 LocalDNS 将得到的域名 ip 地址,回应给 用户端 态 , 容量等,确保将用户的请求分配到就近可用的节点上 . 用户得到域名 ip 地址后,访问站点服务器 缓存功能服务 CDN 节点服务器应答请求,将内容返回给客户端 .( 缓存服务器一方面 负载均衡设备 ( 如 lvs,F5 的 BIG/IP) 在本地进行保存,以备以后使用,二方面把获取的数据返回给客户端,完成 数据服务过程 ) 内容 Cache 服务器 ( 如 squid) 通过以上的分析我们可以得到,为了实现对普通用户透明 ( 使用缓存后 共享存储 ( 根据缓存数据量多少决定是否需要 ) 用户客户端无需进行任何设置 ) 访问,需要使用 DNS( 域名解析 ) 来引导 3. CDN 智能调度DNS 实例分析(略,见原文) 用户来访问 Cache 服务器,以实现透明的加速服务 . 由于用户访问网站的 第一步就是 域名解析 , 所以通过修改 DNS 来引导用户访问是最简单有效 4. CDN的 智能调度DNS 简化实现(略,见原文) 的方式 . 5. 总结(Summary) 2.3. CDN网络的组成要素 在建立 CDN 网路时,最关键的就是 智能调度 DNS,这个是 CDN 网络总 对于普通的 Internet 用户,每个 CDN 节点就相当于一个放置在它周围的 协调 , 通过高效的调度算法,可以使用户得到最佳的访问体验 . 网站服务器 . 其次就是 CDN 节点的管理 , 比如涉及到 内容的同步机制,配置文件的 通过对 DNS 的接管,用户的请求被透明地指向离他最近的节点,节点中 更新等等,都需要有一套机制来保证 . CDN 服务器会像网站的原始服务器一样,响应用户的请求 . 原文 : http://www.51know.info/system_performance/cdn/cdn.html 013 51CTO 系统频道 : http://os.51cto.com
  • 14. 专题 杂志订阅 : http://os.51cto.com/art/201011/233915.htm Special 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 大型网站后台架构的web server与缓存 文/凤凰舞者 计算机系统中,缓存有很多种。比如 CPU 内部的一级缓存、二级缓存。 (object)。 文件系统的缓存,磁盘的缓存。在大型网站的后台部署过程中,也灵活运用 (2)squid 通过查询表的方式来定位某个资源的位置。所查询的表有两 了各级缓存。主要有客户端的浏览器缓存,服务器端的 web server 自身缓 种,一种是 Hash table,一种是 Digest table。Hash table 记录着所有 Digest 存,代理缓存,分布式缓存,数据库自身的缓存等。本节主要分析一下代理 table 表信息,所以 Hash table 可以称之为目录或者提纲。而 Digest table 记 缓存。 录了磁盘上每个分区、每个目录里存放的缓存摘要,所以 Digest table 可以 代理缓存 称之为摘要或者索引。所以,Squid 接到请求后先查询 Hashtable,根据 Hash table 所指向的 Digest table,再查询所需要的文件。 在网站后台架构中,代理缓存主要部署在 web server 之上,当用户对网 站后台发起连接请求时,用户请求先到代理缓存中去查找,如果命中,则将 (3)squid 服务器存在两种工作关系,一种为 Child-Parent, child squid 当 请求返回给用户,如果没有命中,则代理缓存将请求发到 web server,然后 server 没有用户需要的数据时,就向 parent squid server 发送请求,并持续 web sever 将请求复制一份到代理缓存中,同时把请求返回给客户。 等 待, 到 parent squid server 回 应 为 止 ; 一 种 为 Sibling, 本 地 squid 直 另 当 server 没有用户请求的数据时,会向 sibling server 发送请求,如果 sibling 常用的代理缓存有 varnish 和 squid。 server 没有资料则会向上级 sibling 或者 internet 发送数据请求。 Squid 所以,综上所述,squid 运行模式如下 : Squid 是一个高性能的代理缓存服务器,可以用来加快浏览网页的速度, 当 Squid Server 没有资料时,先向 Sibling 的 Squid Server 查询数据,如 提高客户机的访问命中率。Squid 不仅支持 HTTP 协议,还支持 FTP、SSL、 果 Sibling 没有,则跳过它直接向 Parent 查询,直到 Parent 提供资料为止 ( 如 WAIS 等协议。Squid 用一个单独的、非模块化的、 驱动的进程来处理所 I/O 果 Parent 没有资料,则到后端的 web server 上获取,当获取到数据后返回 有的客户端请求。 给用户的同时,保留一份在自身的缓存中 )。如果不存在 Parent, Squid 则 Squid 的原理如下 : Server 自身到后端的 web server 上获取数据,当获取到数据后返回给用户 (1) 每一台 squid 代理服务器上存有若干个颗磁盘。每颗磁盘又分割 的同时,保留一份在自身的缓存中。如果还是不能得到数据,则向用户端回 成 多 个 分 区, 一 个 分 区 又 可 建 立 很 多 目 录, 录 下 存 放 着 具 体 的 文 件 每 目 复不能得到数据。 014 51CTO 系统频道 : http://os.51cto.com
  • 15. 专题 杂志订阅 : http://os.51cto.com/art/201011/233915.htm Special 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com Varnish 主进程 fork 子进程,主进程等待子进程的信号,子进程退出后,主进程重 新启动子进程,子进程生成若干线程 : Varnish 是一款高性能的开源 HTTP 加速器,挪威最大的在线报纸 Verdens Gang 使用 3 台 Varnish 代替了原来的 12 台 Squid,性能比以前更好。 (1)Accept 线程 : 接受请求,将请求挂在 overflow 队列上。 Varnish 的作者 Poul-Henning Kamp 是 FreeBSD 内核开发者之一,他认为 (2)Work 线程 : 有多个,负责从 overflow 队列上摘除请求,对请求进行处 现在的计算机比起 1975 年已经复杂很多。在 1975 年时,存储媒介只有两 理,直到完成,然后处理下一个请求。 种: 内存与硬盘。但现在计算机系统的内存除了主存外,还包括了 CPU 内 (3)Epoll 线程 : 一个请求处理称为一个 session, session 周期内, 在 处理 的 L1L2L3 等 cache。因此 Squid Cache 自行处理物件替换的架构不可 完请求后,会交给 Epoll 处理,监听是否还在事件发生。 能得知这些情况而做到最佳化,但操作系统可以。所以这部分的工作应该 交给操作系统处理,这就是 Varnish cache 设计架构 [4]。Varnish 将所有的 (4)Expire 线程 : 对于缓存的 object,根据过期时间,组织成二叉堆,该线 HTTP object 存于一个单独的大文件中,该文件在工作进程初始化的时候, 程周期检查该堆得根,处理过期的文件。对过期的数据进行删除或重取操 将其整个映射到内存中。这样 Varnish 在该块内存中实现一个简单的文件 作。 系统,具有分配、释放、修剪、 合并内存等功能。 Varnish 分配缓存机制 : Varnish 文件缓存的工作流程 : 根据所读到的 object 大小,创建相应大小的缓存文件。为了读写方便, Varnish 与 一 般 服 务 器 软 件 类 似, 为 master 进 程 和 child 进 程。 其 中 分 程序将每个 object 的大小,转变为最接近其大小的内存页面倍数。然后从 master 进程负责管理,child 进程负责 cache 工作。Master 进程读入命令,进 现有的空闲存储结构体中查找,找到最合适的大小的空闲存储块,分配给 行一些初始化,然后 fork 并监控 child 进程。Child 进程分配若干线程进行 它。如果空闲块没有用完,则把多余的内存再组成一个空闲存储块,挂接到 工作,主要包括管理线程和 worker 线程。如下图所示。 管理结构体上。如果缓存已满,则根据 LRU 算法,把旧的 object 释放掉。 Varnish 释放缓存机制 : Expire 线程负责检测缓存中所有 object 的生存期 (TTL)。如果超过了设 定的 TTL, object 没有被访问, 该 则删除该 object,并释放内存。释放的过程 会考虑内存的合并等操作。 原文 : http://blog.csdn.net/longxibendi/article/details/6647024 推荐阅读 : varnish 权威指南 中文版 《互联网运营智慧》 7 章 第 “简单 cdn”正式版下载 015 51CTO 系统频道 : http://os.51cto.com
  • 16. 专题 杂志订阅 : http://os.51cto.com/art/201011/233915.htm Special 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com Squid常用命令总结 收集整理/NetSeek Squid安装设试命令: #/usr/local/squid/sbin/squid -k shutdown 1,初始化你在 squid.conf 里配置的 cache 目录 这个不用解释吧。 #/usr/local/squid/sbin/squid -z // 初始化缓存空间 6,重引导修改过的 squid.conf 如果有错误提示,请检查你的 cache 目录的权限。 #/usr/local/squid/sbin/squid -k reconfigure // 载入新的配置文件 2,对你的 squid.conf 排错,即验证 squid.conf 的 语法和配置。 这个估计用的时候比较多,当你发现你的配置有不尽你意的时候,可以 随时修改 squid.conf,然后别忘记对你的 squid.conf 排错,然后再执行此指 #/usr/local/squid/sbin/squid -k parse 令,即可让 squid 重新按照你的 squid.conf 来运行。 如果 squid.conf 有语法或配置错误,这里会返回提示你,如果没有返回, 7./usr/local/squid/sbin/squid -k rotate 轮循日志 恭喜,可以尝试启动 squid。 8, squid 添加到系统启动项 把 3,在前台启动 squid,并输出启动过程。 编辑 /etc/rc.d/rc.local #/usr/local/squid/sbin/squid -N -d1 添加如下行 : /usr/local/squid/sbin/squid -s 如果有 ready to server reques,恭喜,启动成功。 利用 Runc 脚本 ........ 然后 ctrl + c,停止 squid,并以后台运行的方式启动它。 再来点其他的。 4,启动 squid 在后台运行。 1,修改 cache 缓存目录的权限。 #/usr/local/squid/sbin/squid -s #chown -R squid:squid /data/cache 这时候可以 ps -A 来查看系统进程,可以看到两个 squid 进程。 我的 cache 缓存目录是 /data/cache,squid 执行用户和用户组是 squid, 5,停止 squid squid。 016 51CTO 系统频道 : http://os.51cto.com
  • 17. 专题 杂志订阅 : http://os.51cto.com/art/201011/233915.htm Special 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 2,修改 squid 日志目录的权限 可以看到详细的性能情况 , 其中 PORT 是你的 proxy 的端口,5min 可以 是 60min #chown -R squid:squid /usr/local/squid/var/logs 取得 squid 运行状态信息 : 这一步并不是适合每一个使用 squid 的用户 . 意为让 squid 有权限在该 目录进行写操作 。 squidclient -p 80 mgr:info 例如生成 access.log cache.log store.log * 取得 squid 内存使用情况 : 3,查看你的日志文档。 squidclient -p 80 mgr:mem #more /usr/local/squid/var/logs/access.log | grep TCP_MEM_HIT * 取得 squid 已经缓存的列表 : 该指令可以看到在 squid 运行过程中,有那些文件被 squid 缓存到内存中, squidclient -p 80 mgrbjects. use it carefully,it may crash 并返回给访问用户。 * 取得 squid 的磁盘使用情况 : #more /usr/local/squid/var/logs/access.log | grep TCP_HIT squidclient -p 80 mgr:diskd 该指令可以看到在 squid 运行过程中,有那些文件被 squid 缓存到 cache * 强制更新某个 url : 目录中,并返回给访问用户。 squidclient -p 80 -m PURGE http://www.yejr.com/static.php #more /usr/local/squid/var/logs/access.log | grep TCP_MISS * 更多的请查看 : 该指令可以看到在 squid 运行过程中,有那些文件没有被 squid 缓存,而 是现重原始服务器获取并返回给访问用户。 squidclient-h 或者 squidclient -p 80 mgr: 关于 TCP_XXXX 等参数及代表的信息,请参看《squid 中文权威指南》 查命中率 : 13.2.1 章节。 /usr/local/squid/bin/squidclient -h111.222.111.111 -p80 mgr:info 当然,grep 的部分可以修改为其他的参数,例如你的域名 www.xxxx. /usr/local/squid/bin/squidclient -h 具体的 IP -p80 mgr:info com ,同样可以看到 access.log 里关于该域名的行。 原文 : http://bbs.linuxtone.org/thread-137-1-1.html squid命中率分析 前面的安装调试部分来自 CU 的这个帖子。 squid/bin/squidclient -p 80 mgr:info 相关链接 : Squid 中文权威指南》 《 在线阅读 squid/bin/squidclient -p 80 mgr:5min 017 51CTO 系统频道 : http://os.51cto.com
  • 18. 专题 杂志订阅 : http://os.51cto.com/art/201011/233915.htm Special 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com [CDN]动态内容的缓存技术 CSI,SSI,ESI 文/扶凯 CDN 中动态内容是不太好解决的,通常需要很麻烦的技术和方法来实现 目前 Squid 不支持。 这些功能,比如我设计过一种动态缓存的方法,基于 session 栏接,然后根 缺点 : 在语法上不能够直接包含其他服务器的 url, SSI 只能在当前服务 据热点来做动态缓存时间的控制。目前开放的实现 Cache 的技术主要有 器上运行。所以通过 CDN 之类的 Cache 时,还是会失效,不灵活 . CSI,SSI,ESI 之类几种。在一个动态网页中 , 内容不断更新和变化,但这并 不意味不能缓存,其实还是有 90% 的内容都可以做到 CDN 中的。只要 3、Edge Side Includes (ESI) : 花点心思。但这些都对客户有更加高的要需求。下面是这向种技术的介绍。 Edge Side Includes(ESI) 和 Server Side Includes(SSI) 和功能类似。SSI 动态 Cache 页面有如下一些方案 : 需要特殊的文件后缀 (shtml,inc)。ESI(Edge Side Include)通过使用简 单的标记语言来对那些可以加速和不能加速的网页中的内容片断进行描 1、Client Side Includes(CSI) : 述,每个网页都被划分成不同的小部分分别赋予不同的缓存控制 策略,使 通过 iframe、javascript、ajax 等方式将另外一个页面的内容动态包含进 Cache 服务器可以根据这些策略在将完整的网页发送给用户之前将不同的 来。这样来实现动态化。 小部分动态地组合在一起。通过这种控制,可以有效地减少从服务器抓取 整个 页面的次数,而只用从原服务器中提取少量的不能缓存的片断,因此 优点 : 能够利用浏览器客户端并行处理及装载的机制 ; 这种技术基本不 可以有效降低原服务器的负载,同时提高用户访问的响应时间。 需要服务器支持和修改,计算和操作放在客户端,能够降低服务器端压力 优点 : ESI 更适合用于缓存服务器上,缓存整个页面或页面片段,因此 缺点 : 搜索引擎优化问题 ; javascript 兼容性问题 ; 客户端缓存可能导致 ESI 特别适合用于缓存,CDN 的第一名的老大,Akamai 全力支持协议。对 服务器端内容更新后不能及时生效。常常通过加 js version 来解决 . 于布置和 Cache 都是最友好的。 2、Server Side Includes(SSI) : 缺点 : 出来很久,一直没有多少人使用。会这个技术的程序员不多。 SSI 它就是 HTML 文件中,可以通过注释行调用的命令或指针。实现整 原文 : 个网站的内容更新。SSI 需要特殊的文件后缀 (shtml,inc). http://www.php-oa.com/2010/08/13/cdn-cache-csi-ssi-esi.html 优点 : 技术是通用技术, SSI 不受具体语言限制,只需要 Web 服务器或应 用服务器支持即可,Ngnix、Apache、Tomcat、Jboss 等对此都有较好的支持, 018 51CTO 系统频道 : http://os.51cto.com
  • 19. 专题 杂志订阅 : http://os.51cto.com/art/201011/233915.htm Special 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com squid/varnish/ats简单测试 文/三斗室 简 单 的 试 试 varnish 和 apache traffic server。 跟 squid 进 行 一 下 对 比。 时间与 varnish 相近,响应时间 2.1ms。 介于 varnish 和 ats 都是出现不太久的东西(至少是开源流行不长) 选择其 , 从 trafficserver_shell 的 show:proxy_stats 和 show:cache_stats 命令结果 最新开发版本测试,正巧都是 2.15 版。 来看,缓存命中率 98%,磁盘 IO 几乎没有。可见其实都在内存中返回了。 varnish 配置文件,只修改了 backend 到具体某台 nginx 发布点上。其他 3、最后 squid2.7.9 : -r900 时,fetch/sec 只有 880,响应时间 1.9ms ; 提 都是反向代理缓存的标配。(可参考张宴博客和 varnish 权威指南) 高到 -r1000 时,没有 wrong 报错,fetch/sec 下降到 850,响应时间 2.3ms ; ats 说明更少,从目前的资料看,修改了 records.config 中的监听,cache. 另一个窗口的 netstat 命令直接卡住…… config 遵 循 源 站 未 改,remap.config 添 加 了 map 一 条, 定 域 名 到 同 一 台 绑 squid 按照公司默认做法,缓存目录建在了 tmpfs 上。从 squidclient 来看, nginx 上。 98% 的命中率中只有三分之一是直接通过 cache_mem 返回的,另三分之二 注: varnish 和 ats 都没有修改缓存路径,即分别为 var/varnish/varnish. 是通过 cache_dir 的 tmpfs 返回。 cache 和 var/trafficserver,都是磁盘。 另: 最后 du -sh 查看三者的缓存目录大小,赫然发现 squid 的是 19M, 然后从线上某台 squid2.7 上收集 www.domain.com 下的 html 页面 url ats 是 39M,varnish 是 41M。这个差别也是比较怪异的,值得后续研究…… 一共 164 条,存成 urllist。 从这个简单测试结果看,squid 的稳定性依然没的说 : 对于大多数情况来 使用 http_load 进行测试。第一遍,先用 http_load -r 100 -s 10 完成 说,是乐于见到这种宁愿响应慢点点也要保证响应正确的情况的 ; varnish cache 的加载 ; 第二遍改用 -r 1000 -s 60 进行测试。 在大批量回源时对后端服务器的冲击,显然比较让人担心 ; 和 varnish 具 ats 有同样高效的响应速度(和高压下的错误……) 而且其详细到甚至稍显繁 , 1、 是 varnish : 另 一 个 窗 口 看 netstat, 现 在 第 一 次 加 载 的 时 候, 先 开 发 琐的那堆 config 文件的配置格式,相比 varnish 来说,更加贴近运维人员。 varnish 启动了相当多的链接到后端 nginx 请求数据!第二遍时,-r1000 一 直在刷 wrong,修改成 -r900 就没有问题。最后的报告显示 fetch/sec 还略 原 文: http://chenlinux.com/2011/03/15/simple-test-between- 大于指定的 900 达到 990,建连时间平均 1.3ms,响应时间 1.8ms。 squid-varnish-ats.html 2、然后 ats : -r1000 也报 wrong,于是同样使用 -r900,fetch/sec 和建连 019 51CTO 系统频道 : http://os.51cto.com
  • 20. 专题 杂志订阅 : http://os.51cto.com/art/201011/233915.htm Special 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 使用Nginx代替squid充当代理缓存服务器 文/崔晓辉 我的博客是 CentOS+nginx+php+mysql+eaccelerator 这种架构。只有一 worker_connections 65535; 台服务器,所以想到用在让两个 nginx 分别监听 IP:80 和 127.0.0.1:80。 } http 1. 安装 nginx 和 nginx_cache_Purge. { wget http://labs.frickle.com/files/ngx_cache_purge-1.1.tar.gz include mime.types; tar zxvf ngx_cache_purge-1.1.tar.gz default_type application/octet-stream; wget http://nginx.org/download/nginx-0.8.47.tar.gz charset gbk; tar zxvf nginx-0.8.47.tar.gz #source_charset gbk; cd nginx-0.8.47/ server_names_hash_bucket_size 128; ./configure --prefix=/usr/local/nginx --user=www --group=www --add- client_header_buffer_size 32k; module=ngx_cache_purge-1.1 --with-http_stub_status_module --with-http_ large_client_header_buffers 4 32k; ssl_module client_max_body_size 300m; make -j2 && make install sendfile on; cd ../ tcp_nopush on; 2.nginx 配置 keepalive_timeout 60; cat /usr/local/nginx/conf/nginx.conf tcp_nodelay on; user www www; client_body_buffer_size 512k; worker_processes 1; proxy_connect_timeout 5; error_log /usr/local/nginx/logs/nginx_error.log crit; proxy_read_timeout 60; pid /usr/local/nginx/nginx.pid; proxy_send_timeout 5; #Specifies the value for maximum file descriptors that can be opened by this proxy_buffer_size 16k; process. proxy_buffers 4 64k; worker_rlimit_nofile 65535; proxy_busy_buffers_size 128k; events proxy_temp_file_write_size 128k; { gzip on; use epoll; 020 51CTO 系统频道 : http://os.51cto.com
  • 21. 专题 杂志订阅 : http://os.51cto.com/art/201011/233915.htm Special 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com gzip_min_length 1k; proxy_pass http://backend_server; gzip_buffers 4 16k; add_header X-Cache HIT-FreeBSDSYSTEM.org; gzip_http_version 1.1; expires 1d; gzip_comp_level 2; } gzip_types text/plain application/x-javascript text/css application/xml; location ~ /purge(/.*) gzip_vary on; { proxy_temp_path /home/proxy_temp_dir; allow 127.0.0.1; proxy_cache_path /home/proxy_cache_dir levels=1:2 keys_zone=cache_ allow 219.146.0.0/16; one:200m inactive=1d max_size=30g; deny all; proxy_cache_purge cache_one $host$1$is_args$args; upstream backend_server { } server 127.0.0.1:80 weight=1 max_fails=2 fail_timeout=30s; location ~ .*.(php|jsp|cgi)?$ # 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; proxy_set_header Host $host; } proxy_set_header X-Forwarded-For $remote_addr; server proxy_pass http://backend_server; { } listen 222.134.x.x:80; access_log off; server_name www.freebsdsystem.org blog.freebsdsystem.org freebsdsystem. } org; server index index.html index.htm index.php; { root /usr/local/AUTOLEMP/www/www.freebsdsystem.org; listen 222.134.66.153:80; location / server_name www.huaanjiuyuan.com; { index index.html index.htm index.php; proxy_next_upstream http_502 http_504 error timeout invalid_header; root /usr/local/AUTOLEMP/www/wwwroot; proxy_cache cache_one; location / proxy_cache_valid 200 304 12h; { proxy_cache_key $host$uri$is_args$args; proxy_next_upstream http_502 http_504 error timeout invalid_header; proxy_set_header Host $host; proxy_cache cache_one; proxy_set_header X-Forwarded-For $remote_addr; proxy_cache_valid 200 304 12h; 021 51CTO 系统频道 : http://os.51cto.com
  • 22. 专题 杂志订阅 : http://os.51cto.com/art/201011/233915.htm Special 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 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; 大话IT第20期: add_header X-Cache HIT-FreeBSDSYSTEM.org; expires 1d; } 当Windows8遇上Linux控 location ~ /purge(/.*) 本 期 节 目 不 但 有 微 软 最 新 的 Windows 8 操 作 系 统 登 场, 有 还 { Fedora16、Ubuntu 11.10、OpenSUSE 11.4 出马,更有最近密码泄漏事 allow 127.0.0.1; 件频发而被人关注的 keepass 工具…… allow 219.146.0.0/16; deny all; 三位编辑分别在用 Linux 做什么? proxy_cache_purge cache_one $host$1$is_args$args; Windows8 又有啥特别的? } location ~ .*.(php|jsp|cgi)?$ 敬请收看本期的大话 IT。 { proxy_set_header Host $host; proxy_set_header X-Forwarded-For $remote_addr; 在线观看 : proxy_pass http://backend_server; http://os.51cto.com/art/201112/310499.htm } access_log off; IT 听听看官方微博 : } http://weibo.com/itttkan } 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 022 51CTO 系统频道 : http://os.51cto.com
  • 23. 运维DBA 杂志订阅 : http://os.51cto.com/art/201011/233915.htm Database 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com MySQL性能优化教程之MySQL运维优化 文/caoz 存储引擎类型  如果前端请求重复度较高,无应用层缓存,query cache 是一个很 好的偷懒选择  Myisam 速度快,响应快。表级锁是致命问题。  对于中等以下规模数据库应用,偷懒不是一个坏选择。  Innodb 目前主流存储引擎  如果确认使用 query cache,记得定时清理碎片,flush query  行级锁 cache.  务必注意影响结果集的定义是什么  要考虑到现实的硬件资源和瓶颈分布 行级锁会带来更新的额外开销,但是通常情况下是值得的。  学会理解热点数据,并将热点数据尽可能内存化  事务提交  所谓热点数据,就是最多被访问的数据。  i/o 效率提升的考虑 对  通常数据库访问是不平均的,少数数据被频繁读写,而更多数据  对安全性的考虑 鲜有读写。  HEAP 内存引擎  学会制定不同的热点数据规则,并测算指标。  频繁更新和海量读取情况下仍会存在锁定状况  热点数据规模,理论上,热点数据越少越好,这样可以更好的 内存使用考量 满足业务的增长趋势。  理论上,内存越大,越多数据读取发生在内存,效率越高  响应满足度,对响应的满足率越高越好。  Query cache 的使用  比如依据最后更新时间,总访问量,回访次数等指标定义热 点数据,并测算不同定义模式下的热点数据规模  如果前端请求重复度不高,或者应用层已经充分缓存重复请求, query cache 不必设置很大,甚至可以不设置。 023 51CTO 系统频道 : http://os.51cto.com
  • 24. 运维DBA 杂志订阅 : http://os.51cto.com/art/201011/233915.htm Database 《Linux 运维趋势》投稿信箱 : yangsai@51cto.com 性能与安全性考量 • binlog 文件是顺序写  数据提交方式 • 淘宝数据库存储优化是这样处理的  innodb_flush_log_at_trx_commit = 1 每次自动提交,安全性高,  部分安全要求不高的写入操作可以用 /dev/shm 分区存储,简单变 i/o 压力大 成内存写。  innodb_flush_log_at_trx_commit = 2 每秒自动提交,安全性略  多块物理硬盘做 raid10,可以提升写入能力 有影响, 承载强。 i/o  关键存储设备优化,善于比对不同存储介质的压力测试数据。  日志同步 • 例如 fusion-io 在新浪和淘宝都有较多使用。  Sync-binlog =1 每条自动更新,安全性高, 压力大 i/o  涉及必须存储较为庞大的数据量时  Sync-binlog = 0 根据缓存设置情况自动更新,存在丢失数据 • 压缩存储,可以通过增加 cpu 开销(压缩算法)减少 i/o 压力。前 和同步延迟风险, 承载力强。 i/o 提是你确认 cpu 相对空闲而 i/o 压力很大。 新浪微博就是压缩  个人建议保存 binlog 日志文件,便于追溯 更新操作和系统恢复。 存储的典范。  如对日志文件的 i/o 压力有担心,在内存宽裕的情况下,可考虑 • 通过 md5 去重存储,案例是 QQ 的文件共享,以及 dropbox 这样 将 binlog 写入到诸如 /dev/shm 这样的内存映射分区,并定时 的共享服务,如果你上传的是一个别人已有的文件,计算 md5 后, 将旧有的 binlog 转移到物理硬盘。 直接通过 md5 定位到原有文件,这样可以极大减少存储量。涉 及文件共享,头像共享,相册等应用,通过这种方法可以减少超过  性能与安全本身存在相悖的情况,需要在业务诉求层面决定取舍 70% 的存储规模,对硬件资源的节省是相当巨大的。缺点是,删  学会区分什么场合侧重性能,什么场合侧重安全 除文件需要甄别该 md5 是否有其他人使用。 去重存储,用户量  学会将不同安全等级的数据库用不同策略管理 越多,上传文件越多,效率越高! 存储/写入压力优化 • 文件尽量不要存储到数据库内。尽量使用独立的文件系统存储, 该话题不展开。  顺序读写性能远高于随机读写 运维监控体系  将顺序写数据和随机读写数据分成不同的物理磁盘进行,有助于 i/ o 压力的疏解  系统监控 • 数据库文件涉及索引等内容,写入是随即写  服务器资源监控 024 51CTO 系统频道 : http://os.51cto.com