新闻中心

2135亿!双十一的背后都应用了哪些技术?

  一年一度的光(duo)棍(shou)节终于结束了!成交额高达2135亿!又破了纪录!

  根据公开数据,在2017年双11购物狂欢节上,开场28秒钟成交额破10亿, 3分01秒成交额破百亿,9小时04秒破千亿。交易峰值32.5万/秒,支付峰值25.6万/秒,刷新全球纪录。同时诞生的还有数据库处理峰值,4200万次/秒。

  几乎毫无悬念,今年天猫双11将刷新去年1682亿的销售记录,技术的各种峰值数据也将再次打破全球记录。

  然而在这样的业务场景下,背后是靠什么样的技术来支持如此庞大的秒杀场景?本文千锋武汉小编分析了一下阿里双11背后用到的那些技术!

  利用云计算弹性能力,支撑交易峰值每秒32.5万笔、支付峰值每秒25.6万笔的混合云弹性架构。

  交易核心应用容器化撑起双11交易下单峰值,解放资源的超大规模Docker化技术。

  支撑全球最大规模在线交易的数据实时和离线计算能力,包括承载阿里巴巴集团核心大数据的离线计算平台,以及双十一保证每秒处理亿条日志的计算。

  在搜索、推荐以及客服场景下的创新应用,包括人工智能赋能的数千家品牌商家店铺的个性化运营和粉丝会员的精准营销。

  应对前端极限挑战的淘宝直播首屏秒开,以及应用世界级开源跨平台移动开发工具Weex实现双11会场几近全覆盖,实现全网首屏渲染完美践行“秒开”体验。

  菜鸟通过包裹预测、供应链入库、订单下沉、订单路由调度、电子面单及智能分单,以及末端小件员,涉及十亿级包裹的双11之战。

  总之,双11将涉及:基础设施、存储、中间件、云计算、业务架构、大数据、认知计算与人工智能、交互技术等技术领域。

  由于篇幅有限无法完全详细展开,我就以其中一个大家最关心的双11秒杀场景为例,贯穿这些部分技术的应用和设计思路。

  秒杀系统特点是并发量极大,但实际秒杀成功的请求数量却很少,所以如果不在前端拦截很可能造成数据库读写锁冲突,甚至导致死锁,最终请求超时。

  消息队列可以削峰,将拦截大量并发请求,这也是一个异步处理过程,后台业务根据自己的处理能力,从消息队列中主动的拉取请求消息进行业务处理。

  限制uid(UserID)访问频率:我们上面拦截了浏览器访问的请求,但针对某些恶意攻击或其它插件,在服务端控制层需要针对同一个访问uid,限制访问频率。

  服务层:上面只拦截了一部分访问请求,当秒杀的用户量很大时,即使每个用户只有一个请求,到服务层的请求数量还是很大。比如我们有100W用户同时抢100台手机,服务层并发请求压力至少为100W。

  采用消息队列缓存请求:既然服务层知道库存只有100台手机,那完全没有必要把100W个请求都传递到数据库啊,那么可以先把这些请求都写到消息队列缓存一下,数据库层订阅消息减库存,减库存成功的请求返回秒杀成功,失败的返回秒杀结束。

  利用缓存应对读请求:比如双11秒杀抢购,是典型的读多写少业务,大部分请求是查询请求,所以可以利用缓存分担数据库压力。

  利用缓存应对写请求:缓存也是可以应对写请求的,比如我们就可以把数据库中的库存数据转移到Redis缓存中,所有减库存操作都在Redis中进行,然后再通过后台进程把Redis中的用户秒杀请求同步到数据库中。

  数据库层是最脆弱的一层,一般在应用设计时在上游就需要把请求拦截掉,数据库层只承担“能力范围内”的访问请求。所以,上面通过在服务层引入队列和缓存,让最底层的数据库高枕无忧。

  淘宝在09年的时候就已经提前把数据库按照业务进行垂直拆分,再结合业务需要进行水平拆分。现在对数据库的拆分,都是利用数据库层中间件(淘宝 tddl),来进行无缝对数据库的侵入设计。

  除此以外还会涉及到分布式小文件存储以及搜索引擎,以及服务器集群监控等技术。

  做自己喜欢的,做能改变社会的大事,这种感觉真的很爽,当爸妈向朋友说道:“我儿子/女儿在阿里巴巴上班”,这是怎样一种自豪呢?

  怎样才能去阿里上班呢?前提是要学技术啊!怎么学,你懂的!返回搜狐,查看更多

      申博,申博平台,申博官网




网站地图