新闻动态

“双十一”高并发应对之道

1   “双十一”压力

不知从何时起,“双十一”成为了“购物节”,这种全民狂欢式购物对金融行业是一个巨大挑战,短时间的高并发会给数据接口带来巨大压力。据悉,2015年天猫峰值交易量达到14万次/秒,而2009年仅为400次/秒。

用户每一笔交易背后都包含了多项操作:首先,用户浏览多个商品才触发一次购物行为;再次,实际交易前,需要确保库存、配送、商家优惠政策等信息;生成订单后,执行支付接口,要求高度一致性和可靠性;支付完成后需要回调多个逻辑,包括积分计算、折扣返点、物流配送等。

可见14万/秒的交易峰值,不仅对于金融机构,即便是具备丰富应对高并发经验的互联网公司,都不是一件容易的事。更为紧迫的是,随着IOT设备进一步普及,“双十一”带来的压力将越来越大,据某电商平台预测,2016年“双十一”峰值压力将再翻5倍。在可预见的未来,交易完全有可能达到100万次/秒!

2    应对之道

本人曾参与研发交易量10万/秒级别的系统,这里对如何应对超高并发提出一些建议。其实,无论是“秒杀”还是“双十一”,都没有灵丹妙药,一个真正能抗超高并发的金融系统,必然由系统中每个组件优化而成。让每个组件发挥最大威力,并对系统充分解耦,才能做出可靠的平台。

应对超高并发,最重要两个技术:“缓存-Cache”和”异步化-队列”。

3   缓存- Cache

这里的Cache不是传统意义上的Redis/Memcache等系统Cache组件,而是从用户端到最后数据层所有环节的Cache。

对于高并发场景,第一条准则就是为用户行为所有环节加上合理的Cache。

业务层次图如下:

“双十一”高并发应对之道

如图所示,用户访问/交易行为的起点是浏览器。首先对浏览器端进行合理的Cache设置,即对其中页面设置合理的过期规则,配合CDN端,让部分元素响应直接在浏览器Cache端返回,有效降低业务访问压力;其次,虚线内展示的是业务端,主要由两部分构成,一个是计算资源,运行业务代码;另一个是数据库,负责存储业务数据。

业务层输出的内容分为两部分:动态+静态。对于动态居多的电商金融业务,以静态内容为主的CDN加速没有特别效果,而应该对数据接口进行接口加速(ADN,API Delivery Network)。接口加速需要注意的是,不能因给接口加Cache而影响业务本身。我们建议对所有读类型数据接口加Cache,并将Cache时间设定为毫秒级,针对不同接口指定不同Cache策略,有效提高Cache命中率。

根据实测,通过加ADN Cache,可提高60%访问速度,同时降低2-3倍后端实际负载。

4  异步化-队列

异步化-队列是通过队列将请求/事务放入后台运行,从同步阻塞模式变为异步非阻塞模式。例如,抢购发生时,用户同时调用支付接口,同步阻塞模式下,用户数量即支付接口的并发度,用户过多时,支付数据库压力过大,严重时可能会导致数据库服务宕机。采用异步模式后,抢购时,用户请求进入队列处理,队列并发度与数据库并发能力相匹配,用户请求按序进行,可有效保护数据后端。

队列不只可以保护后端数据库。在秒杀场景,很多用户抢购一个商品,可以先将抢购请求放入队列,再进入后台筛选处理(比如排重、按优先级排序等),最后调用实际下单接口。队列可以根据产品需求选用两种不同模式:一种是全异步模式,即进入队列后立即返回成功,通过回调通知调用者结果;另一种是半异步,即进入队列后,调用者挂起,实际执行结束后,再返回成功或者失败结果。

5  总结

应对“双十一”高并发,主要采用缓存+队列异步化,缓存的重点是每个环节,尤其是对于传统易忽略的数据接口,都要进行合理的Cache。

对于高并发请求,要进行异步化非阻塞处理,防止“洪水”现象,保证业务稳定有序进行。