当前位置:首页 > 短网址资讯 > 正文内容

高并发秒杀系统架构设计 · 抢购、微信红包、短网址、一元夺宝

www.ft12.com5年前 (2017-05-03)短网址资讯2017

秒杀业务与难点

秒杀业务在各业务中已然非常流行,这里我将互联网行业中的秒杀定义为:在非常短的时间内,将一件商品分成多份进行购买的行为。微信抢红包、短网址、一元夺宝、双11大促抢购等业务本质上都可视作秒杀业务。而最近大热的抢红包的难度在于这是和钱打交道的秒杀场景,对于事务的要求性更高。秒杀业务优化的难点或者说痛点在于:同一件商品在同一时间段内有非常多的用户去进行抢夺,从而造成服务器资源的紧张。

非秒杀情况下,比如非大促的时候,用户购买的体验都是非常不错的。但是在秒杀场景下,这时意味着多个用户在同时抢一件商品,也就是并发很高,但集中在同一商品上,造成实质为串行操作。因为在数据库这层本质执行的是对同一件商品扣库存:

更糟糕的是,无论是MySQL、Oracle、还是其他关系型数据库,这会造成大量无意义的上下文切换,从而导致资源浪费。假设在网易考拉上有10000个用户对skuId=1的这件商品进行抢购,那么每个时间点仅有一个用户可以获得进入数据库操作的权限,剩下的9999个用户需要等待,待前面的用户完成操作后,会唤醒9999个用户,告诉他们现在可以进入了,9999个用户重新争夺一次,最终又仅有一个用户进入,这就是所谓的上下文切换。在秒杀场景下,这个代价将会非常大,一个显著的表现是CPU负载非常高,但数据库请求的负载却又非常低。

秒杀常见的三种业务类型为:大促抢购、抢微信/易信红包、一元夺宝。从并发量来看,大促抢购 >短网址 >微信红包 > 一元夺宝。从可靠性要求来看:微信红包 > 一元夺宝 > 大促抢购。但是无论是哪一种,原则上都不能超售,一旦超售后果非常严重,特别是微信红包业务。因此,个人非常不建议将秒杀业务放在缓存中设计的架构,这是在赌RP,后果却可能非常严重。

秒杀业务的架构设计其实并不难,简单来说,就是不要让数据库处理请求这么请求,减少无谓的上下文切换,业界一个比较学术的称谓叫做:限流。

秒杀优化——限流

秒杀架构设计

我个人将秒杀的系统架构设计分为以下几层:

  • 客户端层:用户发起秒杀的浏览器、app或其他客户端;

  • 前端Web服务层,负责接收用户请求,通常是Nginx或Apache等Web服务器;

  • 服务接口调用层,接收到请求,调用相关服务进行秒杀操作;

  • 数据存储层,对于秒杀操作进行持久化。要对秒杀进行优化,则对架构设计上需要对这三层进行限流。

客户端层优化

客户端层的优化比较简单明了,原则上来说依然是限制用户发秒秒杀的次数,从而做到限流的效果。比如在秒杀发起后,按钮变灰。这类做法和短信验证码一样,短信发送后一般需要等待120秒才能再次接收验证码,120秒内的发送短信验证码是灰色的。然而这种做法对于高阶有些的程序员来说,就没啥用了。因为Chrome、Firefox firebug按F12进入开发者模式就能知道具体的请求。只要有心,模拟类似请求,抢几个月饼的难度真不大。

前端展示层优化

在大并的秒杀发量访问场景下,前端展示也要做好相应的页面级缓存,比如10秒内同一用户的页面缓存,同一商品的页面缓存。更重要的是,这样能大大提升用户的体验。当然,现在浏览器本身也会缓存一部分数据,从而提升用户的访问的体验。当然,这也是有利有弊。

服务接口调用优化

对于618、双11这样的全民抢购应用场景,做好前两块优化是远不够的。上述这些优化其实都可以作为例行的开发规范。但是在大促时间段,就是会有超大规模的访问请求,比如几万个人同时抢小米手机,而在开始前是可以知道库存的。因此,开发人员可以通过消息队列或者缓存CAS机制来限制访问到数据库层实际的数量。而对于超出库存的,则前端可以返回等待中,定期再进行重试,直到库存为0为止。

在这里还有个小问题,那就是有些用户可能已经抢到秒杀资格,但是最后没有完成付款。这在红包业务中不存在,但是在电商行业中却是有可能的。淘宝在高峰时间的处理方法是订单30分钟未完成支付即将关闭订单,库存重新可见。而对于像一元夺宝这样的业务,30分钟时间显得有些太长了。故一元夺宝支付失败并没有重试订单的机制。

数据库层的优化

服务接口的调用能起到限流的作用,但是是对同一件商品进行限流。大促期间访问到数据库这里的请求依然不容忽略。如果数据库这层有2000个用户在同时进行秒杀操作,那么这个开销依然非常巨大。这时强烈建议用户开启数据库线程池功能(注意:不是连接池),比如MySQL企业版的Thread Pool插件、社区版的Percona、InnoSQL数据库都支持线程池。线程池的机制是每个用户的连接并不是一定会产生一个实际的硬连接,而是通过Pool机制从中进行分配,也就是实际在数据库内部运行的线程数是固定的,减小上下文切换的时间,从而大幅提升数据库的性能。

数据库架构设计

数据库表结构设计与应用

表结构设计其实大同小异,这里以微信红包业务作为案例分析:

分布式数据库架构

即使做了上述这么多秒杀优化,相信对于高峰期的微信抢红包业务来说也是无法承载的。记得有同学在IMG微信群中有说过(1年多前的数据),微信红包是由70台服务器组成的分布式数据库集群。对于这样的分布式集群,开发人员可以选择红包Id作为均衡字段进行分库分表,通过分布式数据库的可扩展性提升整个集群的性能。需要特别注意的是,由于是分布式架构,建议将上述红包Id的数据类型更改为全局唯一的字符串类型,用户可以自己生成一个规则,或直接使用UUID这样的函数。


扫描二维码推送至手机访问。

版权声明:本文由短链接发布,如需转载请注明出处。

本文链接:https://www.ft12.com/article_31.html

分享给朋友:

相关文章

原来国内外互联网企业开的实体店都长这样

原来国内外互联网企业开的实体店都长这样

【FT12短网址】曾经,咱们都在说要从线下走到线上,现在却反过来了,不断添加互联网公司开端着手规划实体店。除了有国际电商巨子亚马逊、阿里、京东们的尝试之外,国内外还有一大波开线下店的“传统互联网公司”。能够想象一下,这将会给线下零售市场带来...

有哪些可靠的短网址服务?

因为谷歌的打不开,,所以想起其它的服务哪些呢?另外看到个www.ft12.com支持访问统计哪些短网址也支持访问统计呢?知乎用户的回答:一直在收集      u6.ggc7.ggrrd.me985.souee....

从100万个搜索中结果,得出16个SEO优化的核心影响因素

从100万个搜索中结果,得出16个SEO优化的核心影响因素

尽管这篇文章剖析的是google,可是很多关于其他查找引擎也同样受用,不得不说的是在查找技术上baidu与google的距离还是很远,可能方向都放到赚钱去了吧,OK,让咱们开端吧!咱们剖析了100万个查找成果(SERP)来回的一下这个问题:...

2017年哥大毕业典礼演讲之李开复:内心比大脑重要

2017年哥大毕业典礼演讲之李开复:内心比大脑重要

5月15日,创新工场创始人兼CEO、人工智能工程院院长李开复博士作为特邀嘉宾,在纽约哥伦比亚大学工程学院向2017届结业生们宣告了题为《工程师的人工智能银河系周游指南》结业讲演。作为哥大83届结业生,他获益于这所大学年青、活泼、新锐、自在的...

宜家要去第三方电商平台 大家猜猜它会选谁?

宜家要去第三方电商平台 大家猜猜它会选谁?

【FT12短网址】日前,英特宜家(Inter IKEA Holding BV,IKEA品牌的持有者)CEO托尔比约恩·洛夫(Torbjorn Loof)对外宣布,宜家(IKEA)计划从2018年开始测验在第三方电商网站售卖自个的商品。不过,...

谈谈互联网后端基础设施

谈谈互联网后端基础设施

对于一个互联网企业,后端服务是必不可少的一个组成部分。抛开业务应用来说,往下的基础服务设施做到哪些才能够保证业务的稳定可靠、易维护、高可用呢?纵观整个互联网技术体系再结合公司的目前状况,个人认为必不可少或者非常关键的后端基础技术/设施如下图...

发表评论

访客

◎欢迎参与讨论,请在这里发表您的看法和观点。