秒杀架构设计

前言

最近在部门内部分享了原来在电商业务做秒杀活动的整体思路,大家对这次分享反馈还不错,所以我就简单整理了一下,分享给大家参考参考

业务介绍

什么是秒杀?通俗一点讲就是网络商家为促销等目的组织的网上限时抢购活动

比如说京东秒杀,就是一种定时定量秒杀,在规定的时间内,无论商品是否秒杀完毕,该场次的秒杀活动都会结束。这种秒杀,对时间不是特别严格,只要下手快点,秒中的概率还是比较大的。

淘宝以前就做过一元抢购,一般都是限量 1 件商品,同时价格低到「令人发齿」,这种秒杀一般都在开始时间 1 到 3 秒内就已经抢光了,参与这个秒杀一般都是看运气的,不必太强求

业务特点

瞬时并发量大

秒杀时会有大量用户在同一时间进行抢购,瞬时并发访问量突增 10 倍,甚至 100 倍以上都有。

库存量少

一般秒杀活动商品量很少,这就导致了只有极少量用户能成功购买到。

业务简单

流程比较简单,一般都是下订单、扣库存、支付订单

技术难点

现有业务的冲击

秒杀是营销活动中的一种,如果和其他营销活动应用部署在同一服务器上,肯定会对现有其他活动造成冲击,极端情况下可能导致整个电商系统服务宕机

直接下订单

下单页面是一个正常的 URL 地址,需要控制在秒杀开始前,不能下订单,只能浏览对应活动商品的信息。简单来说,需要 Disable 订单按钮

页面流量突增

秒杀活动开始前后,会有很多用户请求对应商品页面,会造成后台服务器的流量突增,同时对应的网络带宽增加,需要控制商品页面的流量不会对后台服务器、DB、Redis 等组件的造成过大的压力

架构设计思想

限流

由于活动库存量一般都是很少,对应的只有少部分用户才能秒杀成功。所以我们需要限制大部分用户流量,只准少量用户流量进入后端服务器

削峰

秒杀开始的那一瞬间,会有大量用户冲击进来,所以在开始时候会有一个瞬间流量峰值。如何把瞬间的流量峰值变得更平缓,是能否成功设计好秒杀系统的关键因素。实现流量削峰填谷,一般的采用缓存和 MQ 中间件来解决

异步

秒杀其实可以当做高并发系统来处理,在这个时候,可以考虑从业务上做兼容,将同步的业务,设计成异步处理的任务,提高网站的整体可用性

缓存

秒杀系统的瓶颈主要体现在下订单、扣减库存流程中。在这些流程中主要用到 OLTP 的数据库,类似 MySQL、SQLServer、Oracle。由于数据库底层采用 B+ 树的储存结构,对应我们随机写入与读取的效率,相对较低。如果我们把部分业务逻辑迁移到内存的缓存或者 Redis 中,会极大的提高并发效率

整体架构

客户端优化

客户端优化主要有两个问题

秒杀页面

秒杀活动开始前,其实就有很多用户访问该页面了。如果这个页面的一些资源,比如 CSS、JS、图片、商品详情等,都访问后端服务器,甚至 DB 的话,服务肯定会出现不可用的情况。所以一般我们会把这个页面整体进行静态化,并将页面静态化之后的页面分发到 CDN 边缘节点上,起到压力分散的作用

防止提前下单

防止提前下单主要是在静态化页面中加入一个 JS 文件引用,该 JS 文件包含活动是否开始的标记以及开始时的动态下单页面的 URL 参数。同时,这个 JS 文件是不会被 CDN 系统缓存的,会一直请求后端服务的,所以这个 JS 文件一定要很小。当活动快开始的时候(比如提前),通过后台接口修改这个 JS 文件使之生效

API 接入层优化

客户端优化,对于不是搞计算机方面的用户还是可以防止住的。但是稍有一定网络基础的用户就起不到作用了,因此服务端也需要加些对应控制,不能信任客户端的任何操作。一般控制分为 2 大类

限制用户维度访问频率

针对同一个用户( Userid 维度),做页面级别缓存,单元时间内的请求,统一走缓存,返回同一个页面

限制商品维度访问频率

大量请求同时间段查询同一个商品时,可以做页面级别缓存,不管下回是谁来访问,只要是这个页面就直接返回

SOA 服务层优化

上面两层只能限制异常用户访问,如果秒杀活动运营的比较好,很多用户都参加了,就会造成系统压力过大甚至宕机,因此需要后端流量控制

对于后端系统的控制可以通过消息队列、异步处理、提高并发等方式解决。对于超过系统水位线的请求,直接采取 「Fail-Fast」原则,拒绝掉

秒杀整体流程图

秒杀系统核心在于层层过滤,逐渐递减瞬时访问压力,减少最终对数据库的冲击。通过上面流程图就会发现压力最大的地方在哪里?

MQ 排队服务,只要 MQ 排队服务顶住,后面下订单与扣减库存的压力都是自己能控制的,根据数据库的压力,可以定制化创建订单消费者的数量,避免出现消费者数据量过多,导致数据库压力过大或者直接宕机。

库存服务专门为秒杀的商品提供库存管理,实现提前锁定库存,避免超卖的现象。同时,通过超时处理任务发现已抢到商品,但未付款的订单,并在规定付款时间后,处理这些订单,将恢复订单商品对应的库存量

总结

核心思想:层层过滤

  • 尽量将请求拦截在上游,降低下游的压力
  • 充分利用缓存与消息队列,提高请求处理速度以及削峰填谷的作用

参考

  • 秒杀业务架构优化之路 「http://www.infoq.com/cn/articles/flash-deal-architecture-optimization」
  • 互联网秒杀业务设计 「https://baijia.baidu.com/s?old_id=108134」
  • 高并发秒杀系统架构设计 「https://zhuanlan.zhihu.com/p/25368538」

原文发布于微信公众号 - Linyb极客之路(gh_c420b2cf6b47)

原文发表时间:2018-05-01

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏非著名程序员

关于Android中设置闹钟的相对比较完善的解决方案

? 前些时候,有人在我「非著名程序员」公众号的后台问我有没有设置闹钟的demo,我当时说承诺为大家写一个,一直没空,直到最近又有人跟我要,我决定抽时间写一个吧...

448100
来自专栏EAWorld

微服务编排之道

目录: 一、微服务需要编排吗? 二、微服务编排的流程 三、微服务编排的一致性 四、微服务编排的监控工具支撑 一、微服务需要编排吗? 微服务是一种新的软件架构风格...

1.4K70
来自专栏Java技术交流群809340374

主流的消息队列MQ比较,详解MQ的4类应用场景

消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能,成为异步RPC的主要手段之一。

2.9K30
来自专栏Linyb极客之路

分布式系统的弹性设计

在讨论分布式系统的弹性之前,让我们快速回顾一些基本术语: 弹性Resiliency:任何系统从困难中恢复的能力,(banq注:弹性也就是适应能力)。 分布式系统...

22540
来自专栏Android群英传

沪江学习Android端重构实践

9530
来自专栏EAWorld

DevOps之软件配置协作化管理

? 大家好,我是许二虎,现在负责新一代数字化企业云平台 “The Platform” 的各业务领域系统的设计和开发。很荣幸有这次机会和大家分享交流“DevOp...

36380
来自专栏腾讯移动品质中心TMQ的专栏

腾讯TMQ在线沙龙回顾|FAT——专业服务于微信H5/小程序UI自动化测试

活动介绍 TMQ第四十六期在线沙龙分享活动圆满结束啦! ? 本次分享的主题:FAT——专业服务于微信H5/小程序UI自动化测试 共有295位测试小伙伴报名参加...

35530
来自专栏北京马哥教育

性能调优概述,这是一篇最通俗易懂性能调优的总结!

精彩早知道 作者概述 什么是性能调优?(what) 为什么需要性能调优?(why) 什么时候需要性能调优?(when) 什么地方需要性能调优?(where) ...

53350
来自专栏

记录服务上线一年来的点点滴滴

2015年12月,也就是在一年前,开发了半年的云存储服务上线。这对于付出了半年努力的我们来说,是一件鼓舞人心的事件。因为这个服务在我们手上经历了从0到1的过程。...

20950
来自专栏杨建荣的学习笔记

MySQL分布式架构演进小结

最近在整理一个系统的分布式架构扩展方案,经过了多次的迭代,总算让项目走上了正轨。

14300

扫码关注云+社区

领取腾讯云代金券