备战双十一——从架构到细节

淘宝历经多年的发展，尤其近几年双十一出色表现，阿里研发已经在互联网应对高负载、大并发树立技术标杆。

大型网站、尤其是淘宝这样的超大型网站，它在技术上的方方面面都是值得认真研究学习的。

这里说的大型网站，是指PV在千万级别以上的，面向全部互联网用户访问的。

简略说：
贴近用户，分布，分层，权责明确，可靠可追溯。

贴近用户：一是体验风格要贴近用户，面对千万的网民，一定要以大众化的方式呈现，过于另类和奇葩的东西大众很难接受。
二是网络资源要贴近用户，你的服务器资源放在南非的某个小国家，国内的网友访问速度怎么也上不去。要与网友在地里位置上贴近，通过自建机房或租用CDN镜像的方式把服务器资源放置在离用户最近的地方。 

分布：一是地域上的分布，二是应用请求的分布。网友访问你的网站首页，服务器响应请求并发送信息到网友浏览器。
这里面有文字的新闻，新闻里的图片/音频/视频，页面样式的文件（css，按钮背景图片等）可能还有脚本引用（jQuery插件等一堆的js文件），网友发表的评论和他收到的来自其他网友的信息等。

这些里面除了最后一个，前面三类都是通用的，通过缓存/镜像等方式提前准备好推送到网友最近的服务器。
文字的东西不大，重点解决图片和CSS类的，图片我们启用多组图片服务器并使用多个域名轮循使用，一来提高速度（浏览器单域名并发请求有限制），二来提高可靠性。

CSS类的，一些按钮啊、边框啊、背景图片什么的，一个网站下来可能有上百个，一个一个地请求加载这100多个文件，哪怕很小也要很长的时间。
我们采用“图片地图”的方式，把这一百个图片拼成一个大图，用的时候通过css取这个图上的不同区域范围显示，拼接得紧凑一些，不会比原来大很多，但只要一次请求就够了，时间就是这么节省的。

分层：网友访问，首先响应的是缓存服务器（Varnish，Squid，nginx），这类响应速度快，负载能力强，易维护扩展，缓存不能提供的再请求动态应用（php，tomcat，weblogic，ASP等），
动态应用也不直接访问数据库，先访问数据缓存（Java缓存，Memcache，ehcache等），这些都没有了再访问数据库（MySQL，Oracle，DB2等）。

一个典型的：varnish>>apache>>tomcat>>ehcache(Memcache)>>MySQL。按平均命中率90%来计算（做好设计的话，这已经很低了），10000次前端访问才带来一次数据库访问。如果数据库能抗几百并发的话，千八百万PV的网站不是轻而易举的么。
发生了访问缓慢，就具体分析瓶颈卡在了哪一层上了，然后扩展即可。
有的前面的分布部署，权责明确就好弄了。
95%以上的网友操作都是浏览，从缓存里直接取就是了，不需要访问数据库。
网友注册慢，就把注册的服务单独拎出去，并扩展优化增强。
而不会因为注册的人多，让整个网站访问都变得困难。

可靠可追溯：互联网拼的就是用户体验。一个网站文章写得非常好，但打开要30秒钟，可能用户等5秒钟还没结果就把浏览器关了。 
一定要可靠，对上面的分层分组，确保每个组里发生一台或多台崩溃的情况下，系统仍能提供服务（可以速度慢），消除单点。

可追溯，通过多种log日志记录，监控记录（Zabbix等）的手段全程记录网站运行情况。尤其能记录到单个或多个崩溃前后系统都发生了什么，
运维人员能够从中分析原因，做好预防。
==================================================================================
[url]http://loveqinghe.iteye.com/blog/1962711[/url]
[url]http://loveqinghe.iteye.com/blog/1969733[/url]