qinyushuang的专栏

原文地址：http://www.cnblogs.com/leefreeman/p/3993449.html

原文地址：http://www.cnblogs.com/leefreeman/p/3998757.html#3112162 一、前言     在前一篇随笔《大型网站系统架构的演化》中，介绍了大型网站的演化过程，期间穿插了一些技术和手段，我们可以从中看出一个大型网站的轮廓，但想要掌握设计开发维护大型网站的技术，需要我们一步一步去研究实践。所以我打算写一个系列，从理论到实践讲述大型网站的点

这里的大型网站架构只包括高互动性高交互性的数据型大型网站，基于大家众所周知的原因，我们就不谈新闻类和一些依靠HTML静态化就可以实现的架 构了，我们以高负载高数据交换高数据流动性的网站为例，比如海内，开心网等类似的web2.0系列架构。我们这里不讨论是PHP还是JSP或者.NET环 境，我们从架构的方面去看问题，实现语言方面并不是问题，语言的优势在于实现而不是好坏，不论你选择任何语言，架构都是

微博作为国内最大的社交媒体网站之一，每天承载着亿万用户的服务请求，这些请求的背后，需要消耗着巨大的计算、内存、网络、I/O等资源。而且因为微博的产品特性，节假日、热门事件等可能带来突发数倍甚至十几倍的访问峰值，这些都对于支撑微博的底层基础架构提出了比较严苛的要求，需要满足： 每秒数十万的用户请求数据更新的实时性服务请求的低响应时间99. 99%以上的服务可用性 　　为了满足业务的发展需

一、nginx的11个phases 一个请求经过nginx处理的过程中，会经过一系列的阶段（phases），下面这个表格列出了nginx的所有phases，每个阶段可选的退出方式，包含的模块和对应的指令 phase optional exits modules / directives description NGX_HTTP_POST_READ_PHASE

一.配置的那些事儿 1.业务背景 作为大型复杂分布式系统，微博平台中存在大量的配置信息，这些配置信息定义了平台中的RPC服务和资源（memcached、redis、mysql等）的地址，以及这些服务和资源的元数据信息。 在微博早期，配置信息散落在工程的代码中，这种方式简单方便，但是微博平台系统规模扩大和业务部署复杂度的提升带来了一些问题： 服务按照业务和重要程度部署在多