秒杀业务架构的优化

优化方向:

  将请求尽量拦截在系统上游

  充分利用缓存

站点架构

1.客户端

  JS层面,限制用户在x秒之内只能提交一次请求;

2.站点层

  用uid即可。在站点层面,对uid进行请求计数和去重,甚至不需要统一存储计数,直接站点层内存存储。一个uid,5秒只准透过1个请求,这样又能拦住99%的for循环请求。

  页面缓存,同一个uid,限制访问频度,做页面缓存,x秒内到达站点层的请求,均返回同一页面

3.服务层

  写请求,做请求队列

  读请求,做缓存,memcached或redis

  业务规则上的优化,如分时分段售票...每隔半个小时放出一批:将流量摊匀

  数据粒度的优化,如流量大的时候,做一个粗粒度的 “有票”“无票”缓存即可

  业务逻辑的异步,如下单业务与 支付业务的分离

4.数据层

  浏览器拦截了80%,站点层拦截了99.9%并做了页面缓存,服务层又做了写请求队列与数据缓存,每次透到数据库层的请求都是可控的

优化思路

  尽量将请求拦截在系统上游

  读多写少的常用多使用缓存(缓存抗读压力)
时间: 2024-11-09 03:21:31

秒杀业务架构的优化的相关文章

【转】秒杀业务架构优化之路

原文地址:http://www.infoq.com/cn/articles/flash-deal-architecture-optimization/ 一.秒杀业务为什么难做 IM系统,例如QQ或者微博,每个人都读自己的数据(好友列表.群列表.个人信息). 微博系统,每个人读你关注的人的数据,一个人读多个人的数据. 秒杀系统,库存只有一份,所有人会在集中的时间读和写这些数据,多个人读一个数据. 例如小米手机每周二的秒杀,可能手机只有1万部,但瞬时进入的流量可能是几百几千万.又例如12306抢票,

SSM框架学习之高并发秒杀业务--笔记5-- 并发优化

前几节终于实现了这个高并发秒杀业务,现在问题是如何优化这个业务使其能扛住一定程度的并发量. 一. 优化分析 对于整个业务来说,首先是分析哪些地方会出现高并发,以及哪些地方会影响到了业务的性能.可能会出现高并发的地方:详情页,获取系统时间,地址暴露接口,执行秒杀操作. 这个业务为什么要单独获取时间呢?用户会在详情页大量刷新,为了优化这里,将detal.jsp详情页和一些静态资源(css,js等)部署在CDN的节点上(至于这个CDN是什么,下面会说),也就是说用户访问详情页是不需要访问我们的系统的,

【58沈剑架构系列】秒杀系统架构优化思路

一.秒杀业务为什么难做 1)im系统,例如qq或者微博,每个人都读自己的数据(好友列表.群列表.个人信息): 2)微博系统,每个人读你关注的人的数据,一个人读多个人的数据: 3)秒杀系统,库存只有一份,所有人会在集中的时间读和写这些数据,多个人读一个数据. 例如:小米手机每周二的秒杀,可能手机只有1万部,但瞬时进入的流量可能是几百几千万. 又例如:12306抢票,票是有限的,库存一份,瞬时流量非常多,都读相同的库存.读写冲突,锁非常严重,这是秒杀业务难的地方.那我们怎么优化秒杀业务的架构呢? 二

秒杀系统架构优化思路

[总结] 上文应该描述的非常清楚了,没什么总结了,对于秒杀系统,再次重复下我个人经验的两个架构优化思路: (1)尽量将请求拦截在系统上游(越上游越好): (2)读多写少的常用多使用缓存(缓存抗读压力): 浏览器和APP:做限速 站点层:按照uid做限速,做页面缓存 服务层:按照业务做写请求队列控制流量,做数据缓存 数据层:闲庭信步 并且:结合业务做优化 一.秒杀业务为什么难做 1)im系统,例如qq或者微博,每个人都读自己的数据(好友列表.群列表.个人信息): 2)微博系统,每个人读你关注的人的

阿里秒杀系统架构优化思路

秒杀业务为什么难做 im系统,例如qq或者微博,每个人都读自己的数据(好友列表.群列表.个人信息) 微博系统,每个人读你关注的人的数据,一个人读多个人的数据 秒杀系统,库存只有一份,所有人会在集中的时间读和写这些数据,多个人读一个数据例如:小米手机每周二的秒杀,可能手机只有1万部,但瞬时进入的流量可能是几百几千万. 又例如:12306抢票,票是有限的,库存一份,瞬时流量非常多,都读相同的库存.读写冲突,锁非常严重,这是秒杀业务难的地方.那我们怎么优化秒杀业务的架构呢? 优化方向 优化方向有两个(

秒杀系统架构分析与实战

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

秒杀系统架构分析与实战(参考、转载)

目录[-] 0 系列目录 1 秒杀业务分析 2 秒杀技术挑战 3 秒杀架构原则 4 秒杀架构设计 4.1 前端层设计 4.2 站点层设计 4.3 服务层设计 4.4 数据库设计 4.4.1 基本概念 4.4.2 设计思路 5 大并发带来的挑战 5.1 请求接口的合理设计 5.2 高并发的挑战:一定要“快” 5.3 重启与过载保护 6 作弊的手段:进攻与防守 6.1 同一个账号,一次性发出多个请求 6.2 多个账号,一次性发送多个请求 6.3 多个账号,不同IP发送不同请求 7 高并发下的数据安全

秒杀系统架构分析与实战(转)

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

秒杀系统架构设计

秒杀活动的用户量可能是网站平时正常访问量的数百甚至上千倍,网站如果为了秒杀时的最高并发量而设计部署,就需要比正常运营多的多的服务器,而这些服务器在绝大部分时候都是用不着的,浪费惊人.所以秒杀业务不能使用正常网站的业务流程,也不能与正常网站业务共用服务器,必须设计部署专门的秒杀系统. 秒杀系统所面对的技术挑战: 1.对现有业务造成冲击 2.高并发下的应用.数据库负载 3.突然增加的网络及服务器带宽 4.直接下单 秒杀规则是到点了才能下单,而下单页面也只是一个普通的url,如果得到这个url则不用等