大型在线应用更快响应时间的实现方法——来自Google架构师 Jeff Dean
《大型在线应用更快响应时间的实现方法》下载链接 fast-reponse-time-large-fanout-online-service
谭砚耘注：这是Google工程师Jeff Dean在2012年3月的演讲稿，英文的，我对要点做了简单的翻译，时间短，不太准确，有问题欢迎指出。
在架构更快的网站系统的方方面面，都有阐述。特别适合多节点输出的在线系统。国外的facebook google 国内的baidu 腾讯等，都在此列。
这类在线系统，往往提供多点服务，如htm文档、博客、新闻、文件、图片、视频，如下图：
牵涉的服务器越多，延迟就可能越长，因为：
1. 服务器越多，某台服务器繁忙造成延迟的几率就大。
2. 同时连接多台服务器，本身就是一件耗时的事。
而为了改善延迟，传统的两种方法都不适用：
1. 压缩所有可能造成延迟的因素——对于大型多点系统来说，无法轻易更新和扩展。
2. 采用共用的系统环境——无法适应网络突变，服务激增等因素。
传统方法行不通，那么正确的方法是什么呢？PPT中提出了几条路：
一、标准的改善延迟的技巧
- 对请求的优先级排序
- 对网络服务优先级排序
- 将在头部发生阻塞的服务拆散
- 将耗时大户放到非繁忙时间运行
二、同步中断
- 不要随机运行后台的各种进程
- 要同步进程，避免在rush hour百上加斤
三、建立系统的容错能力和容可变能力
四、服务的负载均衡
服务繁忙的服务器，将里面的服务转移到比较空闲的服务器中。
五、加速灾难恢复
某个服务器崩溃了，要迅速将崩溃前的服务平衡的分配到其他服务器内。
六、建立动态和静态镜像服务器
对于最常用的文件，放到多个静态镜像中去。
对于突发的某类请求（比如对google来说，农历春节期间，中文请求会增多），使用静态镜像服务器。
七、延缓容易诱发延迟的因素
八、优化请求过程中的可变因素
九、数据独立错误——没看懂，哪位帮忙看看，评论一下
十、金丝雀试错法——没看懂，哪位帮忙看看，评论一下
后补 by 谭砚耘 2012-4-6：根据热心网友的回复，在这里补充一下关于金丝雀试错法 Canary Request 是一种应对危险请求的方法。对于接受海量request的服务，可能会存在某些危险的request，直接导致上千台服务器发生故障，这种Death Request非常危险，Google是怎样防范呢？两个方法：
方法一：重新分析日志，找出危害服务进程的Request，标记为Death Request。但这是亡羊补牢，无法做到即时。
方法二：采用金丝雀试错法（Canary Failure Request），将一些可能危险的request暂时放到一台机子上运行，如果正常，再放到1000台机子上运行。如果出错了，再给多几台机子来运行，这样就不会同时影响1000台服务器。
至于为什么叫金丝雀，笔者怀疑是误称。Canary是大西洋的一个岛屿，虽然在地理位置上说来，加纳利群岛实是非洲大陆的部分，它离西班牙最近的港口加底斯（Cadiz）也有近一千公里的海程，可是岛上的居民始终不承认他们是非洲的一部分，甚至史书上也说，加纳利群岛，是早已消失了的大西洋洲土地的几个露在海上的山尖（来自百度百科）。也就是说，Canary代表了三不管地区，和非洲大陆相隔很远，和欧洲也很远，被引申指那些孤立的、隔绝的事务。采用Canary Request，用某个孤立的服务器来试错。 Canary Request的说明链接
十一、请求处理的backup处理机制（用更多的服务器换取性能）
提交一个请求，同时交给两台服务器处理，性能好的服务器先反馈，然后发送指令给另一台慢的服务器，终止对请求的response。
用了backup机制，除了改善延迟外（PPT的例子，提升50%以上），也更容易达到更高的服务保障率。
十二、容许“被玷污”的数据
有的时候为了达到99.9%的保障率，需要1000ms
而如果我们达到99%的保障率，只需要200ms
为了改善延迟，我们可能会选择后者
十三、硬件上面做文章
结合视频看的话，PPT的效果可能更好。
感谢tiantian1234在英语和专业技术上的不吝赐教，浪费了你接近一个小时晚上宝贵的时间啊……
作者: 谭砚耘@用户体验与可用性设计-科研笔记
版权属于: 谭砚耘 （TOTHETOP至尚国际 ）
版权所有。转载时必须以链接形式注明作者和原始出处
http://www.webusability.cn/from-google-jeff-dean-rapid-response-time-on-large-fanout-service-1521/
如果你希望与作者交流，请发送邮件到 tanyanyun/at/163.com 别忘了修改小老鼠