如何设计一个秒杀系统

什么是秒杀

秒杀场景一般会在电商网站举行一些活动或者节假日在12306网站上抢票时遇到。对于电商网站中一些稀缺或者特价商品,电商网站一般会在约定时间点对其进行限量销售,因为这些商品的特殊性,会吸引大量用户前来抢购,并且会在约定的时间点同时在秒杀页面进行抢购。

秒杀系统场景特点

  • 秒杀时大量用户会在同一时间同时进行抢购,网站瞬时访问流量激增。
  • 秒杀一般是访问请求数量远远大于库存数量,只有少部分用户能够秒杀成功。
  • 秒杀业务流程比较简单,一般就是下订单减库存。

秒杀架构设计理念

限流: 鉴于只有少部分用户能够秒杀成功,所以要限制大部分流量,只允许少部分流量进入服务后端。

削峰:对于秒杀系统瞬时会有大量用户涌入,所以在抢购一开始会有很高的瞬间峰值。高峰值流量是压垮系统很重要的原因,所以如何把瞬间的高流量变成一段时间平稳的流量也是设计秒杀系统很重要的思路。实现削峰的常用的方法有利用缓存和消息中间件等技术。

异步处理:秒杀系统是一个高并发系统,采用异步处理模式可以极大地提高系统并发量,其实异步处理就是削峰的一种实现方式。

内存缓存:秒杀系统最大的瓶颈一般都是数据库读写,由于数据库读写属于磁盘IO,性能很低,如果能够把部分数据或业务逻辑转移到内存缓存,效率会有极大地提升。

可拓展:当然如果我们想支持更多用户,更大的并发,最好就将系统设计成弹性可拓展的,如果流量来了,拓展机器就好了。像淘宝、京东等双十一活动时会增加大量机器应对交易高峰。

架构方案

一般秒杀系统架构

设计思路

将请求拦截在系统上游,降低下游压力:秒杀系统特点是并发量极大,但实际秒杀成功的请求数量却很少,所以如果不在前端拦截很可能造成数据库读写锁冲突,甚至导致死锁,最终请求超时。
充分利用缓存:利用缓存可极大提高系统读写速度。
消息队列:消息队列可以削峰,将拦截大量并发请求,这也是一个异步处理过程,后台业务根据自己的处理能力,从消息队列中主动的拉取请求消息进行业务处理。

前端方案

浏览器端(js):

页面静态化:将活动页面上的所有可以静态的元素全部静态化,并尽量减少动态元素。通过CDN来抗峰值。
禁止重复提交:用户提交之后按钮置灰,禁止重复提交
用户限流:在某一时间段内只允许用户提交一次请求,比如可以采取IP限流

后端方案

服务端控制器层(网关层)

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

服务层

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

  1. 采用消息队列缓存请求:既然服务层知道库存只有100台手机,那完全没有必要把100W个请求都传递到数据库啊,那么可以先把这些请求都写到消息队列缓存一下,数据库层订阅消息减库存,减库存成功的请求返回秒杀成功,失败的返回秒杀结束。
  2. 利用缓存应对读请求:对类似于12306等购票业务,是典型的读多写少业务,大部分请求是查询请求,所以可以利用缓存分担数据库压力。
  3. 利用缓存应对写请求:缓存也是可以应对写请求的,比如我们就可以把数据库中的库存数据转移到Redis缓存中,所有减库存操作都在Redis中进行,然后再通过后台进程把Redis中的用户秒杀请求同步到数据库中。

数据库层

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

案例:利用消息中间件和缓存实现简单的秒杀系统

Redis是一个分布式缓存系统,支持多种数据结构,我们可以利用Redis轻松实现一个强大的秒杀系统。

我们可以采用Redis 最简单的key-value数据结构,用一个原子类型的变量值(AtomicInteger)作为key,把用户id作为value,库存数量便是原子变量的最大值。对于每个用户的秒杀,我们使用 RPUSH key value插入秒杀请求, 当插入的秒杀请求数达到上限时,停止所有后续插入。

然后我们可以在台启动多个工作线程,使用 LPOP key 读取秒杀成功者的用户id,然后再操作数据库做最终的下订单减库存操作。

当然,上面Redis也可以替换成消息中间件如ActiveMQRabbitMQ等,也可以将缓存和消息中间件 组合起来,缓存系统负责接收记录用户请求,消息中间件负责将缓存中的请求同步到数据库。

参考文档:https://my.oschina.net/xianggao/blog/524943

时间: 2024-12-10 09:53:13

如何设计一个秒杀系统的相关文章

如何设计一个RPC系统

RPC是一种方便的网络通信编程模型,由于和编程语言的高度结合,大大减少了处理网络数据的复杂度,让代码可读性也有可观的提高.但是RPC本身的构成却比较复杂,由于受到编程语言.网络模型.使用习惯的约束,有大量的妥协和取舍之处.本文就是通过分析几种流行的RPC实现案例,提供大家在设计RPC系统时的参考. 由于RPC底层的网络开发一般和具体使用环境有关,而编程实现手段也非常多样化,但不影响使用者,因此本文基本涉及如何实现一个RPC系统. 认识RPC(远程调用) 我们在各种操作系统.编程语言生态圈中,多少

如何使用.Net来设计一个爬虫系统

创业以来尝试过好几个创业项目,在每次 bootstrap的时候,往往都需要借助于一些Internet上的内容,这里不可避免的就需要写一些简单的爬虫来抓取一些数据来完成项目的初期引导.这些小的爬虫对于我学习.Net,Http Protocol, Framework Design, Design Patterns提供了很多的帮助.爬虫版本的一次一次refactoring和upgrade都往往能够加深我对于某些领域的知识的掌握. Open source方面比较有名的爬虫项目有Nutch和Heritri

SSM实现秒杀系统案例

---------------------------------------------------------------------------------------------[版权申明:本文系作者原创,转载请注明出处] 文章出处:http://blog.csdn.net/sdksdk0/article/details/52997034作者:朱培      ID:sdksdk0      -------------------------------------------------

限时抢购秒杀系统架构分析与实战_Android

1 秒杀业务分析 正常电子商务流程 (1)查询商品:(2)创建订单:(3)扣减库存:(4)更新订单:(5)付款:(6)卖家发货 秒杀业务的特性 (1)低廉价格:(2)大幅推广:(3)瞬时售空:(4)一般是定时上架:(5)时间短.瞬时并发量高: 2 秒杀技术挑战 假设某网站秒杀活动只推出一件商品,预计会吸引1万人参加活动,也就说最大并发请求数是10000,秒杀系统需要面对的技术挑战有: 对现有网站业务造成冲击 秒杀活动只是网站营销的一个附加活动,这个活动具有时间短,并发访问量大的特点,如果和网站原

限时抢购秒杀系统架构分析与实战

1 秒杀业务分析 正常电子商务流程 (1)查询商品:(2)创建订单:(3)扣减库存:(4)更新订单:(5)付款:(6)卖家发货 秒杀业务的特性 (1)低廉价格:(2)大幅推广:(3)瞬时售空:(4)一般是定时上架:(5)时间短.瞬时并发量高: 2 秒杀技术挑战 假设某网站秒杀活动只推出一件商品,预计会吸引1万人参加活动,也就说最大并发请求数是10000,秒杀系统需要面对的技术挑战有: 对现有网站业务造成冲击 秒杀活动只是网站营销的一个附加活动,这个活动具有时间短,并发访问量大的特点,如果和网站原

大型网站技术架构之秒杀系统架构设计

秒杀活动的技术挑战 1. 对现有网站业务造成冲击 秒杀活动只是网站营销的一个附加活动,这个活动具有时间短,并发访问量大的特点,如果和网站原有应用部署在一起,必须会对现有业务造成冲击,稍有不慎可能导致整个网站瘫痪. 2. 高并发下的应用.数据库负载 用户在秒杀开始前,通过不停刷新浏览器页面以保证不会错过秒杀,这些请求如果按照一般的网站应用架构,访问应用服务器.连接数据库,会对应用服务器和数据库服务器造成极大的负载压力. 3. 突然增加的网络及服务器带宽 假设商品页面大小200K(主要是商品图片大小

百度研发笔试题解析:设计一个系统处理词语搭配问题

题目: 设计一个系统处理词语搭配问题,比如说 中国 和人民可以搭配,则中国人民 人民中国都有效.要求: *系统每秒的查询数量可能上千次: *词语的数量级为10W: *每个词至多可以与1W个词搭配 当用户输入中国人民的时候,要求返回与这个搭配词组相关的信息. 分析: 性能要求:每秒查询量达到上千次,意思就是QPS要达到1000以上. 搜索端使用多线程处理,现在服务器都是多核的,可以充分利用服务的资源. 数据结构: 所有词语建一张大表,并给每个词语分配一个id. 存储结构如下: id1,word1,

一个购物系统的数据库订单表该如何设计

问题描述 一个购物系统的数据库订单表该如何设计 订单中要显示购买者信息,购买者配送地址,商品名,价格,数量其中商品可能是多个. 解决方案 这个最好是设计2个表,,一个订单,,一个订单详情,,订单中是用户的信息与购买的商品名,,订单详情中是商品的具体价格,数量,介绍等信息 解决方案二: 一张用户信息表,一张订单详情表,用户信息表唯一,主键是订单详情表的外键

如何设计一个高性能的日志系统

问题描述 如何设计一个高性能的日志系统 需求: 1.系统采用B/S架构,要求能够记录客户端的任何事件,比如单击了某个按钮或者链接: 2.要求能够记录用户每次操作时后台代码使用到的SQL和参数,比如添加数据时的SQL语句和具体的Parameter: 3.将1和2串联或者合并起来,意思就是我在分析日志时,能够在查询客户端事件时也能看到后台的SQL语句和参数: 4.2年内数据达到20亿条记录,采用什么样的数据库比较合适,非关系行的MongoDB还是关系型的Oracle: 解决方案 4.什么数据库都没关