超时

根统计，排除系统在容错性方面的BUG，典型的互联网应用503错误更多的都是网络环境不稳定，或者并发和系统负载过高导致的。如twitter的案例。

 

 

鲸鱼页面实际上是对HTTP 503错误的前端展示，503错误通常是调用后台请求超时产生，为了避免用户长时间等待，Twitter的前端(Tim: 也可能是HTTP反向代理)给请求加了超时，避免用户无限制的等待。超时通常是由于单位时间内访问的用户数过大，也有可能是后台某个服务突然变慢造成。

 

下面是一个简化了的互联网应用的架构。

 

 

暂且不去考虑各层和各层之间的缓存，LB，容灾切换等等技巧因素，当用户发起一次访问，从客户端->Web服务器->逻辑处理服务器->数据库等数据流请求贯穿了整个架构线。我们模拟一下的使用场景。

 

1. 某Socket Server使用了ThreadPool来处理所有核心业务。
2. 不少业务需要访问内网的一个远程的User Service(RPC)来获取用户信息。
3. User Service需要访问数据库。
4. 数据库有时候会变慢，一些大查询需要10秒以上才能完成。

 

结果4造成3很多调用很久才能执行完，3造成2的RPC调用阻塞，2造成1的ThreadPool堵塞，ThreadPool不断有新任务加入，但是老的任务迟迟不能完成。因此对于最终用户的表现是很多请求没有响应。部分用户认为是网络原因会手工重复提交请求，这样会造成状况并进一步恶化。上面的问题根本是没有意识到远程服务可能会超时或失败，把远程服务RPC调用当成一个本地调用来执行。

 

其中任何一段的服务器，在处理过程中延时过高或者阻塞超时，基于用户体验考虑，于是我们在屏幕上看到了长长的队列或者twitter的鲸鱼。此时用户心态莫过于频繁刷新，于是，所有的请求接踵而来，于是，某个请求成为了压垮骆驼的最后一根稻草。甚至由此导致了雪崩。系统产生连锁反映，全面陷入摊贩。（奥运售票系统的失败就是在于容灾和防止雪崩的处理上的疏忽）

 

无论是大牛James Hamilton的优雅降级，还是互联网提倡的有损服务。在处理这种问题上有以下几个方法。

 

解决思路一：RPC增加Timeout
解决思路二：将RPC改成异步调用。

解决思路三：并发调用，统一返回，有损服务。

 

类似于QQ空间的应用，个人中心里有很多用户的数据，分别都是从不同的业务接口获取，如果是传统的应用，按照串行接口获取数据，当一个数据超时，将影响整个页面的显示。因为本身数据之前不存在依赖关系，则可以考虑并发从接口获取数据，当某个接口数据获取超时，则默认用“获取失败”或者“正在拉取中”代替，这个时候用户在界面看也许并不在意自己的等级分数，或者心情数量等等具体数据，这便是“有损服务”。