Unicorn给Twitter带来的效果

3月30日Twitter在其engineering blog上写了一篇Unicorn Power的blog:http://engineering.twitter.com/2010/03/unicorn-power.html,写的挺经典的,按我的理解来讲下这篇blog吧,如有错误,请帮忙纠正,:)。

3月30日Twitter在其engineering blog上写了一篇Unicorn Power的blog:http://engineering.twitter.com/2010/03/unicorn-power.html,写的挺经典的,按我的理解来讲下这篇blog吧,如有错误,请帮忙纠正,:)。
@sandofsky和@netik在blog中首先举了个经典的超市收银的问题,通常超市会有多个收银台,在高峰期通常每个收银台前都会排队,而这个时候如果某个顾客买的东西特别多,或者某个顾客买东西时遇到麻烦的话,就会导致队伍后面的人要排很久的队,而其实此时其他的队有可能处理的更快很多,这种情况会造成的问题是有些人先排的队,但却等了更长很多的时间,于是有家叫Fry的超市,采取了另外一种方法来进行收银,就是让所有的顾客在同一个地方排队,然后三十个收银员进行收银,每完成一个时就按下信号灯,表示可以去该收银台进行付款了,这样之后的好处是减少了由于个别顾客造成一堆人等待很长时间的现象。
从超市的例子脱离出来,来看看twitter的状况,之前twitter运行在apache和mongrel上,通过mod_proxy_balancer来做负载均衡,每台业务处理器能处理一定的请求,处理不过来的就排队,于是就有可能出现有些用户不幸的在处理比较慢的机器中排队,在排了长时间后可能会出现的是超时,而另外一个问题就是队列排不下了,就只能丢弃请求了,但其实也许这个时候如果请求都合理的分配的话,可能能够让超时或丢弃请求的现象降低,于是twitter的工程师开始寻求改变。
在去年11月,twitter开始尝试Unicorn,unicorn增加了一个类似Fry超市的拉的方式,twitter首先在mobile.twitter.com上进行了尝试,到了今年1月,已经在twitter.com上也采用了unicorn,在采用Unicorn了后,twitter惊喜的发现,它们明显的降低了30%的请求延时,并且还很明显的降低了CPU使用率。
其他的是一些监测方面的介绍,就不在此分析了,感兴趣的同学可以看看原作。

这篇blog给了我挺大的感触的,在标准的通过硬件负载设备访问real server时,尤其典型的通过硬件负载设备访问后端tomcat的情况中,会出现的现象就和twitter的现象基本一样了,假设一个tomcat只能处理100个请求,为了避免用户太高的失败率,必然会给一个较大的等待队列,这个时候就会出现如果请求处理慢,就导致了排在队中的用户要等待很久,从而造成超时或请求丢弃,如果能采取类似Fry的方法,那么就能够做到按照用户发起请求的顺序来进行处理了,而不会因为个别用户请求处理慢就造成排队的用户超时和请求被拒绝的现象,这确实是一个合理发挥server请求处理能力的负载均衡不同角度的策略,但这里其实有个要求,就是负载设备或软件负载方案要能支持排队功能,这对传统的方案还是有一定挑战的(例如最少连接数),但无论如何,其能带来的效果还是明显的。

ps: 不过如果一家超市只有一个队的话,那得多长呀…有些时候可能会给顾客造成心理压力,搞不好就不买了,呵呵,当然,应用到软件领域倒是没这个问题,反正用户也不知道现在排的队有多长,:)

《Unicorn给Twitter带来的效果》有10个想法

  1. 感觉这个问题,从根本上讲,是一个”公平性”的范围问题:原有方案的公平性的范围只是当前队列,一旦进来了,在队列中先来后到是公平的。但是两个队列之间,就没有公平可言了,一旦进入某个比较慢的队列,就相当于上了贼船。船越大,陷进去的就越多,上面的例子中,队列越长,影响越大。

    解决的方案,似乎是将原有队列合并为一个超大队列,因此大家一起公平了。

  2. 这个是apache的负载均衡功能不足造成的。其实像lighttpd的proxy策略,就支持SQF,那么就不存在这个问题了

  3. 北京的知春路的沃尔玛超市的收银台就是这样的,高峰时期每个队伍大概有5个收银人员伺候

发表评论

电子邮件地址不会被公开。 必填项已用*标注


*