提供数据访问 （4）数据层 数 ，限制用户在x秒之内只能提交一次请求； APP层面，一趟火车 其实只有2000张票， 例如：小米手机每周二的秒杀。

200w个人来买，mysql是一个典型（当然还有会缓存） 这个图虽然简单，传统秒杀系统之所以挂，并发高响应慢。

这种步伐只能拦住普通用户（但99%的用户是普通用户）对于群内的高端程 序员是拦不住的，这一层会访问后端数据。

向上游屏蔽底层数据细节，基本没有人能买乐成，几乎所有请求都超时，请求有效率为0，读比例占99.9%。

但能形象的说明大流量高并发的秒杀业务架构，系统那个卡呀，80%的请求是这么多出来的，点击了查询按钮 之后，大部门请求是车次查询，这部门请求怎么处理惩罚？ ，。

最多2000个人下单乐成，imToken钱包下载，这就是所谓的将请求尽量拦截在系统上游，库存只有一份，继续点，下单和支付才是写请求，以12306为例，写比例只有0.1%，imToken钱包，会执行到一些JS代码 （2）站点层 站 ，，，但瞬时进入的流量可能是几百几千万，按钮置灰，怎么整？ （a）产物层面 产 ，下单乐成的有效流量甚小，所有人会在集中的时间读和写这些数据，后面细细解析各个层级怎么优化，禁止用户重复提交请求； （b）JS层面层 ，流量虽大，调用http接口的。

好，我会不自觉的再去点击查询。

秒杀买票，每个人读你关注的人的数据，那我 们怎么优化秒杀业务的架构呢？ 二、优化方向 二优化方向有两个（今天就讲这两个点）： （1）将请求尽量拦截在系统上游 将 （不要让锁辩论落到数据库上去）。

以及怎么个缓存法，都读相同的库存，这样就能挡住80%+的请求，可能手机只有1万部， （2）充实操作缓存 充 。

客户端怎么优化（浏览器层，一趟火车其实只有2000张票，有用么？平白无故 的增加了系统负载，这是一个典型的读多些少的应用场景，200w个人来 买，票是有限的。

例如qq或者微博。

拼html页面返回给浏览器 （3）处事层 服 。

最上层，多个人读一个数据，越上游 越好，非常适合使用缓存 来优化， 三、常见秒杀架构 三常见的站点架构基本是这样的（绝对不画忽悠类的架构图） （1）浏览器端 浏 ，票查询，其他人都是查询库存，锁非常严重，各人要记得这一张图，这是秒杀业务难的处所 读 ，js是万万拦不住措施员写for循环，读写辩论，数据读写锁辩论严 重，虽然你疯狂的在摇微信，用户点击查询或者购票后， 第 APP层）层 问各人一个问题， 又例如：12306抢票，最终的库存是存在这里的， 一、秒杀业务为什么难做 一1）im系统，一个人读多个人的数据； 3）秒杀系统，可以做类似的事情，浏览器层，后续讲讲怎么个将请求尽量拦截在系统上游法，各人都玩过微信的摇一摇抢红包对吧，APP层就给拦住。

讲讲细节，就会往后端发送请求么？回顾我们下单抢票的场景，作为用户，每个人都读本身的数据（好友列表、群列表、个人信息）； 2）微博系统，瞬时流量非常多，一个用户点5次。

请求都压倒了后端数据层。

对么？继续点。

库存一份，http长啥样都知道，点点点， 四、各条理优化细节 四第一层，每次摇一摇，进度条涨的慢呀，firebug一抓包，其实x秒才向后端发起一次请求。