Berkeley latency 读后感

前几天看了Jeff dean大牛关于google提高响应速度的PPT，感受颇多。能感受到的在很多公司里，往往把业务层面和较高的架构看的很重要，而缺少很多细节层面的精益求精。

 大系统的问题：

首先是对于大系统的理解，往往在一个产品的初期，系统是比较简单的。这个时候对整个系统的把握比较容易，而且可以通过优化关键的瓶颈点达到系统的高效。在系统发展的过程中，会不断的有模块增加进来，这个时候系统可能是数十个或上百个程序员在维护的状态，在这个时候，没有人能够清楚的了解系统的瓶颈。主要原因有两个：

1. 模块过多，而且模块之间会有依赖关系，在一个模块升级的时候，很难清楚的预见会对其他相关模块造成什么影响；

2. 系统一直在变化中，按照2周的迭代周期，几乎每天系统都有模块在修改；

另外，在模块众多的情况下，如果每个模块平均响应时间1ms，但是有1%的时间，模块的响应时间超过1s的话，当一次请求涉及100个模块的时候，就会有63%的情况本次请求超过1s。

解决思路：

按照作者的思路，优化主要有几个原则：

1. 优先级请求队列，与防止雪崩的方法相似，在Server的设计中需要有一个队列，处理请求的分发并控制流量。

2. 通过把大的请求打散为小的请求来减少请求的耗时。

　　这里的打散有一些更多的含义，把大的请求拆分为数个小请求之后，引进了一个Backup Request的思路。对一个请求会发送给多个Server。当有一个结果返回的时候取消另外的请求，这样会消耗更多的资源，但是确保了系统响应时间。这里会有一个问题，如果系统99%的请求都是在1ms内返回，但是每次要发多个请求会白白消耗过多的资源，解决方法是在发送一个请求之后等待一个足够长的时间，比如10ms，然后再发送其他请求。这样可以把整体响应时间控制在足够小。

　　当有一个Server返回请求的时候，为了避免其他服务仍然消耗资源计算，引入了Cross Server Cancellation，即通知其他server放弃处理。

3. 管理昂贵的后台活动。

感悟：

在提起系统架构的时候，经常会想到的是其中的一个个组件，使用了什么样的网络模型，算法等等。当系统规模足够大的时候，更多的考虑就不再是某个组件的设置，更多的应该是想如何在不可靠的组件上建立一个可靠的系统，对系统的响应时间，也应该是如何在不可预见的组件之上建立一个可预见响应时间的系统。

在系统建立以后，后台的服务统计、监控、自动部署、调度。这些才是一个大系统更加重要的。