今天听了下百度的朋友讲了百度现有的运维体系，感觉还是很不错的，比较适合大的方向把握。 第一个是运维的日常工作： 1. 突发流量，这个需要及时的进行流量调度，以及排查为什么会有突发流量，是某个新的上线导致还是由于配置错误还是运营推广。 2. 复杂环境关联。这个其实是最重要的，在一个复杂的系统环境中会有很多层次，我们要了解每个层次之间的关联，以及每个层次的性能。所以一个完整的系统逻辑框架图和物理框架图是很有必要的。 3. 快速开发并上线。这个是由于互联网的特性造成的，我们什么都是讲究一个快字，快速开发，快速部署，快速增长，快速下线。 第二个是整体运维的框架： 1. 容量管理 2. 关联关系 3. 任务管理 4. 自动部署 5. 分布式集群和传统集群 6. 机器管理 要在一开始为这6项做好流程化和监控管理，同时最后要贯穿安全检测和灾难管理。 具体到运维框架里的自动化监控 数据采集： 1. 数据采集（主动提交到中心服务器上）： 在client端部署公共插件和自定义脚本的一些监控 2. 服务器状态检测（由中心服务器隔时间去检测）： 这个主要是中心服务器去检测服务器上的服务状态和程序状态，以及用户访问的质量 3. 第三方信息：这个主要是跟公司内部系统相关联 数据处理： 1. 复杂计算：因为有些监控阈值不是单独一个值就能判定这个是否有问题，而是通过多个监控值进行计算后才能确定是否有故障 2. 阈值判别 3. 智能分析：这个是分析到底是什么导致了这个故障，为后面做故障自动恢复打下基础。 报警和联动： 1. 报警策略：这个主要是报警的阈值和去重报警。当一台服务器挂掉的时候，那一般情况这个服务器上所有报警都会发出来，但是这个时候其实就报一个服务器down就可以了。 2. 联动处理：由于一个服务的问题可能导致其它问题的产生，这个时候需要了解系统的逻辑架构和关联关系才能知道。 3. 报警跟踪：跟踪问题的处理过程和结果，时间等信息 4. 问题管理：每个问题都有各种各样的原因产生的，这个可以汇总整理 完整的监控内容： 1. 域名监控：看看dns解析是否正确，这个百度吃过大亏的 2. 流量监控：主要是某个区域和全网流量是否有异常。 3. 访问质量监控：通过对于前端服务器的流量镜像分析来判定网络质量值否正常。也有是从本地通往远程是否网络路由是否正常。也可以使用networkbench和gomez这种第三方监测来发现。 4. 语义监控：就是对于页面中的关键字进行监控 5. 基础监控：系统的状态，cpu, load等等 6. 端口监控：telnet到机器的服务端口看看是否正确返回 7. 结构体监控： 这个是当某个进程还在系统中存在，端口也存活，但是无法正常服务的情况下进行监控。可以模拟程序请求这个进程，看是否能正常工作并返回正确的值。 8. 模块监控 9. 日志监控：对于机器的错误日志，访问日志等信息进行监控 10. 自定义监控： 其实以上所有的监控的最终目的就是要发现对于用户的影响是什么？ 具体到具体的语义监控内容： 1. 语义监控（页面监控）：其实就是通过get页面然后判断页面是否有预定义的关键字。 2. 高级语义监控（面向功能）：这个是为了监控页面中多个模块是否正常。这个需要在html对于不同的功能定义标签开始符和结束符，这样通过get这个面后看看标签之间是否数据存在就知道页面功能是否正常。 监测各地用户访问质量： 1. 各地访问速度：这个基本需要在当地部署机房后才能测定，也有用networkbench和gomez来测量的。 2. 各地流量 3. 机房带宽使用 4. 各地DNS速度 对于模块的监控： 1. 程序自身占用的资源是否合理 2. 程序的性能表现是否正常 3. 该程序的分支是否正常 基础监控： 1. CPU资源占用： 这个就看CPU到底是多少核了，不能一定说多少 2. 内存使用：这个要看实际使用的，不能算上buffer和cache，因为Linux系统默认是利用完所有的内存的 3. 文件句柄的使用 4. 网络句柄 5. 各种状态的进程数 服务监控标准： 1. 数据加载情况 2. 模块处理能力 2.1 平均耗时 2.2 队列长度 2.3 线程池使用率 3. 模块间通讯状态 3.1 平均连接时间 3.2 读写错误数 异常根源分析： 1. 关联关系查询 2. 模块关联探测 3. 服务器关联状态探测 4. 网络关联探测 5. 波动性预警 联动处理： 1. 流量切换预案 2. 服务器重启 3. 磁盘数据清理 4. 执行用户自定义命令 报警去重： 1. 服务器维度 2. 策略维度 3. 多维度 4. 计算同策略两次连续报警的时间间隔 5. 最大等待时间

mysql 5.5 以后的tar包居然是用cmake来进行安装的，而不是之前的Autotools方式即（configure方式）

所以还是记录一下安装过程，以备后记。

首先是下载tar包，大概22M的样子，我自己下载的是5.5.10的版本。

然后是安装一些必备的工具

1

sudo apt-get install cmake libncurses5-dev g++

然后是通过cmake来进行编译

最近一周主要是对mysql的mmm进行的相关测试。

它的官方网站是mysql-mmm.org
mmm其实是一个针对mysql双master的一个套件，是完全使用perl来写的。主要作用是监控2个mysql的状态和在出现问题的情况下进行IP漂移切换。不能算是完全意义上的mysql高可用。只是在传统的双master基础上加个监控和漂移，这个完全可以自己写程序来实现。因为mmm在切换过程中也会导致当前连接的丢失，而且这种模式在innodb的情况下出现故障后恢复是一个非常麻烦的问题。
mmm的主要架构是这样的，一个是mmm
monitor服务器，它来负责监控和切换，所以它的配置文件主要是进行设置如何进行监控。2个mysql服务器是客户端。但是需要配置上虚IP，所以每个mysql服务器最少有3个IP，一个真实的IP，2个虚IP。mmm monitor就是进行切换虚IP的，而不是实际的IP
安装过程就不详细说了，主要是要安装一堆perl包，如果可以cpan的话完全可以用cpan来安装，不然就自己下tar包安装，最后做个rpm包来进行安装。
下面就是整个配置流程：
首先对2个mysql配置好了双master，就是互为主备的那种模式。
首先我们定义一下各个机器的IP，mmm monitor的IP是10.10.36.111， mysql

1. 的真实IP为10.10.36.112, 虚拟IP为10.10.36.201和10.10.36.202，mysql
2. 的真实IP为10.10.36.113，虚拟IP同样是10.10.36.201和10.10.36.202。
   安装完mmm后首先要对mmm monitor进行配置

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

   cat /etc/mysql-mmm/mmm_monitor.conf include mmm_common.conf check_period 1 trap_period 2 timeout 2 check_period 1 trap_period 2 timeout 2 ip 127.0.0.1 pid_path /var/run/mmm_mond.pid bin_path /usr/lib/mysql-mmm/ status_path /var/lib/misc/mmm_mond.status ping_ips 10.10.36.113,10.10.36.112 monitor_user mmm_monitor monitor_password mmm_monitor_password debug 0

   接着是配置mmm_common.conf，这个文件在monitor和agent上都是一样的。

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

   cat /etc/mysql-mmm/mmm_common.conf active_master_role writer cluster_interface eth0 pid_path /var/run/mmm_agentd.pid bin_path /usr/lib/mysql-mmm/ replication_user mmm_repl replication_password mmm_repl_password agent_user mmm_agent agent_password mmm_agent_password ip 10.10.36.112 mode master peer mysql_db2 ip 10.10.36.113 mode master peer mysql_db1 hosts mysql_db1,mysql_db2 ips 10.10.36.201 mode exclusive hosts mysql_db1,mysql_db2 ips 10.10.36.202 mode balanced

   下面这个是10.10.36.112上的agent上的mmm_agent.conf的配置

   1 2 3

   cat /etc/mysql-mmm/mmm_agent.conf include mmm_common.conf this mysql_db1

   下面是10.10.36.113上的agent的mmm_agent.conf的配置

   1 2 3

   cat /etc/mysql-mmm/mmm_agent.conf include mmm_common.conf this mysql_db2

   这些都配置完成了，首先是启动2个mysql服务，同时都启动slave。然后各自启动mmm_agent服务。最后是启动mmm_monitor服务。
   启动完成后mmm_monitor进行相关事务：
   首先是启动监控2个agent服务，启动方式为mmm_contorl set_online mysql_db1以及mmm_control set_online mysql_db2
   启动结果我们可以通过mmm_control show来进行展示，也可以检查监控的状态，mmm_contorl checks来检测现在监控的状态。

澳门香港5日游记 要澳门和香港都玩遍，那最好是澳进港出或者港进澳出。不过推荐大家是澳进港出，毕竟我们在澳门没有可买的东西，所以分量轻。 澳门给我的感觉这里到处都是赌场班车，想去哪里都可以坐免费的赌场班车，无论是到澳门岛还是凼仔岛都有免费的车。另外一个深切感受就是赌场都好豪华啊，给你的感觉就是会把你身家都输给人家都不够。跟我想象当中的赌场完全不一样，看来我是古装片看多了，在大陆地区可只有解放前才有赌场啊，对于现代赌场实在是没有感觉。 澳门岛还是非常小的，除了大三巴以及附近的议事厅和大炮台，其它还真没啥可玩的地方，除非你喜欢赌。而所谓官也街那么多小吃，其实也就这样，价格还都超贵，当然是对于大陆人民而言。而澳门当地人的生活还是很恬静的。基本看不到高楼，全部都是小矮楼和石头楼。而市民一般就是助动车和小排量汽车，去了一天时间没看到一辆大众还是奥迪啥的，全部都是丰田本田的小车。 而当地市民估计也没啥可做的，基本老头老太都是在抗议，这挺好，我们这里抗议还得申请。 过了一天就直接坐喷射飞船去香港了。要说这海浪还是有点大，坐的我们家球子都吐了，看来北方人还是没南方人抗晕船啊。对于我这种小时候就坐快艇的人来说实在是没啥事情。 香港果然是国际大都市啊，到处都是高楼大厦。路上也都是豪车啊。但是突然一条小巷就能让你感受到香港市井气息。而通过这几天去超市和路边小摊购物发现这边物价也是够便宜的。只要是涉及到进口的商品都比大陆便宜的多。 而这里的工资应该也挺高，招个超市理货员月薪都9500呢，这估计是大陆的4倍了吧。哎！这就是传说中的资本主义社会啊，就这样电视新闻里民众还一直说最近物价飞涨，民不聊生，而CCTV只有说人民纷纷反映对生活影响不大。香蕉都从1块8涨到了5块8，还影响不大，我只能说2个字“妈的”。 香港是购物的天堂啊，到处都是卖化妆品的，到处都是sasa和卓悦。价格比免税店再便宜点吧。而服装的价格跟大陆基本一样，就是结算货币成了港币，所以大概也能省个16%的样子。 香港对于普通旅游者可看的一个是维多利亚港的夜景，这个每天晚上7点都会有灯光展示。这个最好的观看地点是在尖沙咀的钟楼附近，附近还有个香港星光大道，不过我们那天是英语解说，不过基本介绍你听个大概，主要是看对面香港岛上灯光展示，特别是中银大厦的灯光十分不错。这里拍了大量的照片，而忽略了旁边的星光大道。 另外一个可看的迪士尼，不过这地方离港岛比较远，还好现在有了地铁还是挺快的。迪士尼给我最大的感受是他们太注重细节了，无论是假的模型还是人物服装都是非常精细。模型的大象和其它动物都跟真的一样，而各种扮演米老鼠和唐老鸭的服装也特别好。最好的就是星梦影院，那种3D感受，以及真实的水泼你脸上，出现的各种香味真是非常不错。另外一个是他们很好的继承了香港商业化的特性，任何一个游玩的地方出口都会有卖各种纪念品的，而买的人中不光是小孩，更有很多像我这样小时候看这些长大的人。看看人家当初动画片都可以不要版权费就卖给国内，但是等10几年后他们就成了消费的主要群体。去的那天刚好是香港迪士尼5周年，各种花车游行和晚上的烟火表演也十分不错。 香港给我的感觉主要是2个，一个是这里商业化特别彻底，基本到处都有卖东西的。只要是底楼它们必定是商店。另外一个这里国语只能算是第三语言，而粤语是第一，而英语是第二。基本碰到所有的售货员都会这3种。估计在这种氛围下生活半年，大家的英文水平应该会提高很快，因为这里电视频道基本也都是英语和粤语。看来作为地方语言粤语估计是死不了了，而吴侬软语现在还是看不到啥有效的办法，现在的上海的小孩基本都说普通话了，而电视台也基本是普通话。 来个最后总结吧。如果说旅游的话我个人觉得香港和澳门真不是合适的旅游目的地，澳门除了大三巴就没什么了，而香港也就维多利亚夜景，太平山顶，浅水湾和迪士尼，其它就没什么了，要是购物的话那还是不错的。在尖沙咀到旺角一地会有很多店可以值得逛逛。而旅游我觉得主要是浏览异域风光和自然美景。而且最好一个地方可以深度旅游。比如大堡礁呆个10天半个月的。旅游嘛，主要是放松心态，可不是购物啥来着，也不想到处跟赶场子一样。 回家了又看了下《旅行的艺术》，我们对于旅游的感觉几乎就是美好过程的感觉，而对于那些琐碎的细节并不关注。这就跟照片跟摄影的区别了。照片可以是那个过程中最灿烂的一瞬间而已。

grep是一个常用的命令。 以前只知道^$.+?*这些用法。以及-E的正则表达式。

今天偶然发现还有一些更高级的匹配模式。具体如下： [:alnum:]    字母与数字字符 [:alpha:]    字母 [:ascii:]    ASCII字符 [:blank:]    空格或制表符 [:cntrl:]    ASCII控制字符 [:digit:]    数字 [:graph:]    非控制，非空格字符 [:lower:]    小写字母 [:print:]    可打印字符 [:punct:]    标点符号字符 [:space:]    空白字符，包括垂直制表符 [:upper:]    大写字母 [:xdigit:]    十六进制数字 还有一些常用的就是 {n}            必须匹配n次 {n,}        必须匹配n次或n次以上 {n,m}        必须匹配n到m次，包含n和m 下面我们进行简单的测试下就知道了 文本内容如下test.txt ```c

A novel is a book of long narrative in literary prose The genre has historical roots both in the fields of the medieval and early modern romance and in the tradition of the novella The latter supplied the present generic term in the late 18th century. Further definition of the genre is historically difficult. The construction of the narrative, the plot, the way reality is created in the works of fiction. Most of these requirements were introduced in the 16th and 17th centuries in order to give fiction a justification outside the field of factual history. The individualism of the presentation makes the personal memoir and the autobiography the two closest relatives among the genres of modern histories.
c

grep a[[:blank:]] test.txt
![5561066808_a504984507_z.jpg](https://images.timoq.com/2011/03/5561066808_a504984507_z1.jpg "5561066808_a504984507_z.jpg")c

grep -E [a-z]{10} test.txt
![5561066804_ae4c0ebe60_z.jpg](https://images.timoq.com/2011/03/5561066804_ae4c0ebe60_z1.jpg "5561066804_ae4c0ebe60_z.jpg")c

grep Th.[[:space:]] test.txt

厉建宇是美籍华人，好多观念上跟我们有很大的不同。

下文就是他之前要离开阿里巴巴留下的离职信。回顾了他在蓝讯和阿里巴巴的路程。本文也展现了他的一些工作理念，应该说跟着这样的领导还是跟对人的。也许这就是google之所以伟大的原因中的一点：简单。
中文不佳，全用英文写又无法让更多的同学了解我的心路旅程，所以请各位原谅我蹩脚的中文。

*一个简单的道理：一块2TB桌面级硬盘今天的价格约为700元，相同大小的企业级硬盘一块今天的要价仍然超过1,500元，这两个硬盘最大的差别是RVI震动率的设置（因此，桌面级硬盘在震动率稍大的时候，依然能够正常工作，企业级硬盘为了提升可靠性，所以当震动略大的时候，会停止工作，保护磁盘），两者连螺丝的位置都相同（不是用于固定硬盘的螺丝，是用于固定磁盘内部机构的螺丝），我们假设硬盘仍然坚守摩尔定律（每18个月容量增加一倍），一年半后就算我们需要更换所有的桌面级硬盘（注），我们还可以做到用相同的成本，获取两倍的存储容量！四年半后，我们将以同样的价格拥有四倍的存储！加上半导体制程的进步，当固态硬盘开始取代机械硬盘（约计在2015年前后发生），我们服务器的性能和效率能将再上一个台阶（每块SSD可以提供250MB/s吞吐量，而且只有2.5英寸（SFF），一台2RU的服务器可以配置24个SFF的服务器，也就是6GB的吞吐量，这也就不难解释为什么2012年开始销售的服务器会配置两个万兆以太网端口了）！

*成本！成本！成本！：我为什么放弃在ChinaCache的股权，回到美国求职呢？那是因为作为CTO，我没有阻挡我的CEO快速扩张视频分享下载（FLV）这条业务线，结果，到2008年中，当土豆在投资者（VC）的降低成本的要求下，自建CDN设施的时候，Chinacache的业务一下子下降了60%，几个月前刚刚购买的交换机和服务器都必须折价出售，最糟糕的是还找不到买家，IT设备的价格是天天掉价的！倘若当初CEO拒绝10%股权赎回的诱惑（VC要求业绩必须连续两年出现100%增长），将发展FLV业务的经费投资在集群效率的优化，那么ChinaCache就可能可以用更低的成本提供FLV下载的业务，加上时段复卖及规模效应，就可以将FLV下载业务的销售价格低于土豆（自建CDN）的成本价，土豆，优酷等视频分享业者也就不会在VC的压力下建设自己的FLV下载基础设施。两个月发不出薪水给普通员工啊！你们一定能够体会那种痛苦，我堂堂一个中国互联网骨干设施的先期建设者，居然要靠砸锅卖铁来等待VC的bridge loan来渡过那艰难的三个月，所以我把股权给了留下来的同事（不知道CEO有没有执行这个意愿），自己回到美国求职。相同的道理，阿里巴巴在过去十年，凭借优秀的商务模式，占据80%的电子商务市场，但是，业务模式创新的速度已不如前十年，同质竞争的压力又不断地增加………一种似曾相识的感觉涌上心头：2000年之后，思科分别在两个阶段受到来自Juniper和华为的追赶，ChinaCache只不过将类似的问题集中在一年之内爆发，所以，当这样的问题来临是，无论你请什么人来，都救不了这样的企业。

*新商业文明 – 谈厂商和用户之间的关系 （扭曲化的结果就是贿赂，无意义的折扣），电子商务在解决供需的问题，我们也应该用相同的概念来解决我们基础设施的问题。讲实在话，阿里巴巴和国有电信运营商采购的腐败就只有一步之远！如果厂商在我们团建时提供一桌四千元的晚餐，我们这些月薪一万元的SA工程师，怎么能够不嘴软呢？如果团建经费再多一点，如果厂商招待费放开一点，我们的工程师需要厂商那一点点小恩小惠吗？

*思科让我回去做主管EC3（企业级云计算），华为让我进入CTO办公室主管云计算业务，我都没同意，它们的薪水可都是高出阿里巴巴三倍的薪水！我想留下来，就是马总的一句“国有”企业 — 一个真正意义的公用事业！另外，是谁鼓励土豆，优酷建设自己的FLV基础设施呢？我怎么可能跟这些砸了我的事业的人再继续合作呢？这些设备厂商唯一想的事情就是让你多买一些，至于你能不能高效应用这些设备，它们才不关心呢！地球明天会不会因为Global warming而变得风雨无常，你的公司会不会因为低效而面临经营的困难都不是它们考虑的问题，因为他们只关系自己的荷包是不是够满，是不是够钱能够买一部Audi R8 Spyder，明天会不会因为业绩不佳而被裁员…………

今天一天跟房子干上了。 http://www.soufun.com/house/zt/201102/312kft.html这个是当初是报名的网址。

地址，当初这上面可是写好有午餐和礼品，可一天下来什么都没有，还好之前出门的时候带了点吃的，不然今天可是饿着肚子了。搜房网你去死吧。整的什么团阿，看来开发商给你的钱是少了，不然你怎么会这样抠门呢。还是你自己都私吞了。本来我参加这种活动就是奔着这些小礼品去的，就跟上次去参加MSN车友会一样，吃吃饭，开开卡丁车，中中奖。而这次搜房网看房团居然什么都没有，要啥都没有我参加看房团干嘛？ 给你做活广告？ 你们也就这点小心思。北苑又不是不认识，也不是太远。祝愿你们股票早日跌到1美元以下直接退市。 早上参加了搜房网北一路线的看房团，主要是北苑那边3个楼盘。第一个什么天润福熙大道只有TMD尾房，在北苑这种地方还建高端住宅，旁边一排高压线，真正有钱人会买房住在高压线旁边？ 不知道是不是开发商拿地价格太高。宣传单上写着2W6一平，怎么到你们嘴里就是3W1一平了呢。后面的世华泊郡价格也一般，2W5单价，就开2栋楼，看来大的开发商都喜欢搞饥饿销售。周边环境实在是太差了。而最后一个筑花年连价格和开盘时间都没定呢，样板间也没有。户型就一种，看来开发商都把买房的当傻子来看了。大家都在观望着。我同样也观望着。 今天路上还碰到好多摆摊的中介，号称请听政策分析。看来中介们好想找人聊聊天啊。 后来又坐地铁是拿退房的钱去了，汗，手续都走完了还要经过20个工作日才能打到卡里，这些开发商都真够黑的。看到财务那边一堆退房的单子。接着去看了红木林。红木林户型倒是挺多，但是同样也是没有样板间，不过好户型我看下来就一种。要到5月份才有样板间，所以还是到时候再说吧。今天就先排个VIP号。之前还让这边的亲戚关注下说开盘了告诉我一声，结果也没有通知，还好问了下销售。 从现在来看也就远洋一方从户型和位置上还不错，只是价格稍贵，我看上的那个户型均价22000呢。比其它的户型都贵，要是再打个8折啥的就好了。那边都快靠近通州了，也就值这个价格吧。当然当初2W5均价买的那些人闹事算不算是开发商的策略呢？ 现在谁不知道一方降价打折呢。 而且这当中发现好多违规的东西，住建委不是要客户首付款在房屋封顶前都存在住建委专用账户上，可看了半天好像就远洋一方是这样干的，而其它楼盘都是存到开发商自己的账户。这不是很明显的违规吗，可销售说了这个都是很正常的。看来大多开发商都是缺钱的。同志们再摒摒吧，等开发商更缺钱的时候房价才会腰斩呢。

昨天说了nginx的几个问题，

由于我现在支持的主要是通用CDN，也就是小图片和CSS以及JS这些东西，并没有做大文件的cache。而问了我们视频部门他们也根本不用nginx作为cache使用，所以有些问题还是没考虑周到。 一个问题是之前发现的，在做tmpfs的时候，当你设置的cache大小为tmpfs的90%的时候，一旦要缓存的内容大于这个90%的时候，nginx会自己崩溃掉。这个我明天做个测试再重现一下，现在有点忘记原因了，好像是tmpfs会占用到实际的磁盘才导致的。 另外一个其实是upstream的问题，这个是一个新浪的老兄提的，基本现在是无解。问题是：比如平均一个文件10M，你在磁盘上存3000个文件，然后模拟多个客户端去访问，因为shm一开始是空的，所以都会去后端拽文件，我们放慢这个拽的过程，比如说网络不好吧 呵呵，那么第一个请求发现不在lookup失败，就会去upstream取数据，边取边向downsteam发，并且存在一个临时文件中，这时第二个请求来了也请求这个文件，因为第一个请求没有处理完，所以第二个请求找不到目标文件只好继续去后端拽，又生成临时文件，并发量大的时候，一个大文件会对应N多的临时文件，最终这些文件rename到一个目标文件，大大浪费了磁盘IO。这个rename是内核做的，nginx调完之后就返回了。这种问题往往会导致内部网络流量非常大，而实际却没有根本没有大。 当有多个连接来获取同一个文件的时候，squid中却没有跟nginx cache一样的问题。我们看看squid是怎么解决的吧。我们在squid有这样一个参数collapsed_forwarding on（http://wiki.squid-cache.org/Features/CollapsedForwarding），一旦设置了参数了，当发现有连接请求同一个文件的时候，squid会合并多个连接，但是它会以最慢速的那个连接去取，然后同步地传送给客户端。这样就不会重复请求后端了。但是squid也有问题，因为首先它是同步的。当用户请求的是动态的内容的话会导致客户端错误。而且当一个用户连接速度很快，一个用户连接速度很慢，那就会以最慢的速度进行获取和传输。所以在squid3.0以后取消了这个参数。 这个问题的解决办法暂时看起来只能在nginx cache前充一下热点的大文件。还好一般内网都是千兆连接，这个速度往往大于用户的连接速度。只有当文件特别大，并且热点文件特别多的情况下才会发生。而且nginx这种处理方式也有一定的好处。 nginx upstream流程我们可以参考http://bollaxu.javaeye.com/blog/900424和http://bollaxu.javaeye.com/blog/900357这2篇文章。基本是由于nginx upstream为了防止锁所以进程间是不共享的。

在我这边现实环境中主要是有三个问题。 第一个问题是当cache过期的时候，nginx会把cache状态设置为updating，但是这个updating却没有设置一个超时，所以导致的情况当一个cache过期的时候好多nginx会连接到源站取数据，而如果源站并发量有限的话，会导致源站突发负载过高，而这个时候导致nginx一直处于updating过程中，如果导致源站挂掉的话，那完蛋了。当然我们也可以设置proxy_cache_use_stale updating;但是这样会导致cache的内容不准确。

解决的方法有2种，一个是我们现在更改nginx源码，使之可以updating设置有超时时间，这样不会导致长时间连接源站造成拥塞。另外一种就是nginx cache分层，分为父节点和子节点，只有父节点才会去源站更新，子节点只从父节点上更新。 第二个问题是upstream中server的状态，我们知道upstream中可以设置proxy_next_upstream当一个服务器挂掉后自动转到其它的服务器上，但是这里有个问题就是让用户访问的时候proxy会每次都会先访问下这个坏的服务器，连接不通了再转到其它服务器上，这每次都要测试会浪费大量的时间。我们需要得到的是proxy会独立一个线程去检查后端服务器，一旦发现后端服务器挂掉的话，那直接从upstream中剔除掉这个服务器就可。而等检测后端服务器又存活了再加进来。 这个现在有ngx_http_healthcheck_module这个第三方模块。具体可以参考http://wiki.nginx.org/HttpHealthcheckModule 第三个问题是nginx proxy连接nginx cache的时候居然使用的是http1.0的，而不是http1.1，就没法使用keepalive连接后端，导致我们小文件的cache服务器连接数过高，而没法进行复用链接。 这个暂时还没有解决，不过看到http://wiki.nginx.org/HttpUpstreamKeepaliveModule这个第三方模块，但是实际还没有测试过，没法做什么结论。 其实大家可以完全查看http://wiki.nginx.org/3rdPartyModules 来看看是否针对自己的应用，有些还是我们国人自己开发的，但是针对第三方模块还是要谨慎使用，上面的healthcheck模块还是经过我们自己的开发重新修改后并进行压力测试后再上线的。开源就是这点好啊。看来我要得学习学习C语言编程来，以后自己也改改增加增加功能啥的。

Mysql读写分离

首先我们必须知道为什么要分离。这个一般是由于以下原因导致的。

1. 性能，单台数据库实在是撑不住了
2. HA，防止单台数据库挂掉造成应用不可用
3. 扩展，由于业务新增了新的需求

以上几种是我们常见的要进行分离的原因。其中做多的可能是第一和第二种。这个主要还是涉及到钱和服务器的数量上。一般业务都会在前端部署更多的服务器，而在最后端的数据库服务器往往比较少。但是对于好多web2.0 UGC这样的业务的网站还是有必要重视后端的速度和稳定性。   分离的多种方案

1. query proxy，这个一般是由单独的服务器来进行的，由它负责这个sql语句路由到哪个服务器上。这种proxy的话最好还是要建立HA方式，不然这个proxy就是一个单点故障。这个在之前人人的系统中就是如此，虽然只是负责发起查询的时候建立真实mysql服务器和应用服务器连接，但是还是比较危险的。
2. Load balance, 后面一堆服务器，通过轮寻的方式来访问mysql服务器。这个很多时候是通过内部DNS来实现。

  分离的多个原则