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

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

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

秒杀业务与难点

秒杀业务在各业务中已然非常流行,这里我将互联网行业中的秒杀定义为:在非常短的时间内,将一件商品分成多份进行购买的行为。微信抢红包、短网址、一元夺宝、双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

分享给朋友:

相关文章

原创财务系列小说:每周学习会分享

原创财务系列小说:每周学习会分享

从总账到总监的成长之路之二十三带着“还有什么其它类似的财务处理?”的问题,王丽想了一路,从新加坡到上海的飞机上。而坐在一旁的方敏,似乎对她在Takashimaya商场买的小包更感兴趣,不停地把她的手机取进取出着试大小。王丽想不出来,就转身问...

【FT12短网址】事件代理:模式 or 反模式?

前言终于熬过四个月了,人都黑了一圈。8 月 4 号的早读文章由 @ 文蔺翻译授权分享。正文从这开始~JavaScript 工具包(toolkit)和框架所做的大量工作,都集中于尝试修复、规范或优化浏览器的功能实现。此类工作需要做出许多假设,...

看见自己,刻在骨子里的价值理念

看见自己,刻在骨子里的价值理念

以人为镜,探索本我的价值观。在和身边的人相处时,由他们身上的一些行为给我产生情绪的落差让我认识到我内心排斥(或认可)的一些东西,同时,也经过这些行为让我很好地反思自己内心所追寻的东西,刻在骨子里的价值理念。第一份工作的时候,我和三个大学同学...

人生两件事:修炼定力,扩展心量

人生两件事:修炼定力,扩展心量

自然环保是术,心灵环保是道。既要在术上做文章,更要在道上下功夫。双管齐下,才能从根本上解决环境污染问题。升起过,发光过,温煦过,这就够了;云遮过,风吹过,雨淋过,又能怎样?旭日就是旭日。对未知世界,我一是好奇,二是恐惧。因为好奇,我有探索未...

小企业面对618京东淘宝“二选一” 有关部门能管些啥?

小型的电商渠道们现在依然着上演京东和淘宝“二选一”这出戏。“从法理上讲,工商局的规矩实际上已归于行政手法干涉司法的情形。换句话讲,这个规矩的意思是,你假如违反了法令,会遭到工商层面的行政赏罚。但你很难把618、双11这种临时性促销节、短期商...

不要在年纪轻轻的时候学会了过日子

不要在年纪轻轻的时候学会了过日子

女人的人生路线不应该是奔向家庭主妇,好男人的标准不应该是贤惠持家。我们共同的理想,都不应该是归于平凡。01在我很小的时候,我就经常听街坊邻里夸隔壁家张婆婆的儿媳妇又漂亮又懂事,白天上班晚上就回家从来不出去瞎玩,跟她男人规规矩矩地过日子,有这...

发表评论

访客

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