<< Fix certificate problem in HTTPS - Real's Java How-to | 首页

陈爱云:打造坚如磐石的搜索架构 - 中生代技术 | 十条

对于一个在线系统而言,性能和稳定性是永远要追求的两个方向,如果是分布式系统,性能不够可以用机器来凑(当然这不是最好的方法,性能的提升不是本文的关注点,所以这里不对提升性能的方法赘述),但是稳定性不能靠机器来堆,并且机器越来越多可能会带来更多的稳定性的问题。做在线系统的同学应该会对墨菲定理感触特别深,如果系统中的某个模块可能会出错,那么它一定会出错。或许可以尝试把奶酪面包和猫绑一起,制作一个永动机:)

 

下面介绍爱奇艺搜索架构高可用之路的演进。爱奇艺搜索始于2011年,距今已有六个年头,在这六年间爱奇艺搜索的用户量和qps都呈指数增长,这也对稳定性提出了很高的挑战。前面我们说,任何一个系统都不可能做的完美,一定会出错,我们需要做的是出错后,把对用户的影响降到最低,让用户感知不到系统的故障。把系统做稳定,多活、降级、限流、扩容都必不可少,下面分别说说我们是怎么做的。

 

异地多活

曾有人开玩笑说挖掘机是互联网行业最恐怖的武器,挖掘机一铲子下去,可能就把机房的光缆电缆挖断,此时如果没有备份机房,那再完美的系统都无法对外服务了。

 

备份可以分为两种,一种是备用的机房平时是不接线上流量,主机房出问题后再把流量切到备用机房上。这样做需要注意几点,一是备用机房的数据和程序版本要保持与主机房一致,二是备用机房平时没有接线上流量,在线上真出问题时,是否敢把线上流量切到备用机房上去,备用机房此时是否可以正常服务,三是备用机房的机器平时不在线上服务,也在一定程度上带来资源的浪费。另外一种备份方式是备用机房平时也在线上服务,一个机房出问题后可以把流量打向其余的机房。假设说有三个机房,那每个机房冗余1/3的机器即可,这样可以接受任意一个机房挂掉。爱奇艺采用的是后一种方式,采取离线数据多写的方式,在线读本机房的数据。

 

异地多活主要还是在数据一致性上比较难处理,搜索在线系统对数据一致性要求不是非常非常高,所以在线方面在实现异地多活困难并不多。

 

降级

降级可以通过各种手段降低系统的负载,去掉一些锦上添花的功能,保证基本的服务质量。基本的降级可以让用户几乎无感知的情况下降低系统的负载。

 

1. 延长缓存过期时间

众所周知,增加缓存可以大大降低后端模块的负载,增加缓存过期时间可以提高缓存命中率,同样可以降低打向后端模块的流量。但是如果缓存时间固定不变且比较长的话,后端数据更新后就不能及时体现在前端,如果缓存时间固定不变且比较短的话,缓存命中率比较低,对后端模块起不到太大的降低流量的作用。所以缓存过期时间要随着后端模块的压力而动态变化,那么,如何实现动态控制缓存过期时间的目的呢?

 

首先在写缓存时,把写缓存的时间戳也加进去,假设这个时间戳为t1,从缓存系统中取出缓存后,同时取得t1,假设当前时间为t2, t = t2 - t1,同时系统中维护一个过期时间的阈值,让t与这个阈值比较,如果t小于阈值,则认为缓存足够新,反之则认为缓存过期。这个阈值不是固定不变的,随着后端压力和后端的成功率而变化。

 

如果取到的缓存已过期,那么去请求后端模块,如果请求后端模块失败了,可以返回过期的缓存的内容。因为对于视频搜索来说,返回一个稍微旧点的结果,要远远好于不返回结果。

 

2. 降低计算复杂度

先举一个上学考试的例子,大部分同学考到80分相对比较容易,但是如果想要考到100分,需要为提高的20分花费大量的精力。可能花20%的精力可以达到80分,但是要再花80%的精力才能再提高20分。搜索质量的提高也如此。

 

可以通过缩小索引的数据范围来降低计算的复杂度。在100亿个doc中进行检索与在100万个doc中进行检索,所消耗的时间都不是一个量级的,所以可以通过缩小索引的数据范围来减少搜索消耗的CPU和时间。这里的范围也不是随便缩小的,需要保证重点数据依旧在索引范围内,可以通过文档的点击数、上线时间等来确定是否属于重点数据。

 

还可以通过省略部分大量消耗CPU的步骤来达到降低计算复杂度的目的,这些步骤就相当于我们前边所说的为了最后的20分而额外消耗了80%的精力,对于爱奇艺搜索来说,这部分是重排序,由于之前已经有粗排序了,去掉重排序依旧可以达到一个基本满意的搜索结果,同时消耗的CPU也很低。

 

这里所说的缩小数据集的范围与去掉重排序的步骤,可以是人为操作的,也可以是自动触发的。比如根据该进程所消耗的CPU,一旦达到某一阈值,则自动进行降级。

 

3. LIFO

很多系统都有一个任务队列,有一个IO线程负责往任务队列里push任务,工作线程从队列里pull任务,默认情况下,这个队列是FIFO的,但是设想这种情况,当工作线程处理不及时时,队列里的任务会越积越多,导致每一个任务都需要在队列里等待很长时间才会被得到处理,但是由于任务在队列里等待了过长的时间,当任务处理完后,可能client已经认为本次请求超时了,server做了无用功,极端情况下可能会导致server一直在做无用功。

 

所以在需要降级时,可以改变任务队列取任务的方式,改为LIFO,起码可以保证新任务得以处理,旧任务如果过期则丢弃掉,有舍才有得嘛。因为任务队列中的任务是按照时间顺序放进去的,所以在LIFO时,一旦取出来一个任务已经过期,则意味着接下来取出的任务也是过期的,此时可以直接把队列清空,不需要挨个取出来再丢弃。

 

4. 缩短任务队列过期时间

为什么要给队列中的任务设置过期时间?因为防止任务已经在队列中等待了很长时间,防止取出执行完后任务已经超时。比如说从队列中取出任务后,得知任务已经在队列中等待了90ms,而此时处理一个任务平均需要消耗20msclient设置的超时时间是100ms,那么就可以大概率的得知这个任务处理完后,client已经认为该任务超时了,那么就没必要再消耗CPU继续处理。所以设置一个任务队列的过期时间是必要的。

 

为什么要动态调整队列中任务的过期时间呢?正如我们前边所说,任务的过期时间是跟当前处理任务的平均耗时相关的,而当前处理任务的平均时间不是一成不变的,会随着当前机器的各种资源的情况发生变化。当任务平均处理时间比较短时,可以容忍任务在队列中多等一会儿,而当任务平均处理时间比较长时,只能允许任务在队列中停留较短的时间。

 

限流

相比降级,限流会直接让部分用户的请求不会被处理,会在一定程度上影响用户体验,是有损的。但是如果经过降级,还不能保证系统的负载处于一个安全的范围内,就需要限流了。限流属于舍小为大,拒绝一部分用户的请求,保证整个系统可用,而不是不顾自身实力蛮力处理所有请求,导致系统挂掉,最终一个请求都处理不了。

 

限流又可以分为两种,分为server根据自身处理能力主动丢弃部分请求,和client根据server的平均响应时间和server的成功率减少给server发的请求的数量。

 

限流的维度可以有多个,根据程序本身的指标:连接数、总的qps、分类的qpsserver一般要对接不同的端,不能因为某一个端的流量上涨而影响到其他端的流量。也可以根据机器的总体指标来进行限流,比如说网络流量、CPU、内存等。

 

扩容

如果经过降级、限流后,系统的负载依旧不能维持在一个相对安全的范围内,此时说明我们现有的资源已经不足以满足用户热情的需求了,此时就需要扩容了。

 

扩容可以使用docker自动完成,根据请求的平均响应时间、请求的成功率、机器的负载等自动判断和扩容,也可以根据过去一天、一周、一个月、一年的流量,来提前预估接下来的流量趋势,提前做出扩容和缩容。

 

经过上述异地多活、降级、限流、扩容等措施,可以保证系统不出大问题,但是优化的道路任重道远,要持续不断地优化才能保证系统越来越稳定。也希望我们的经验教训能帮到大家,让大家再也不用担心各种异常各种突然状况。(全文完)

阅读全文……

标签 : ,



发表评论 发送引用通报