秒杀系统架构优化思路

秒杀业务为什么难做

读写冲突，锁非常严重，这是秒杀业务难的地方。

优化方向

1、将请求尽量拦截在系统上游(不要让锁冲突落到数据库上去)
2、充分利用缓存

常见秒杀架构

a浏览器 -> b站点 -> c服务 -> d数据

a浏览器端：最上层，会执行到一些JS代码；
b站点层：这一层会访问后端数据，拼html页面返回给浏览器；
c服务层：向上游屏蔽底层数据细节，提供数据访问；
d数据层：最终的库存是存在这里，mysql是一个典型(当然还有缓存)

各层次优化细节

第一层，客户端怎么优化(浏览器、App)

a)、产品层面。用户点击“查询”或者“购买”按钮之后，按钮禁用，禁止用户重复提交请求；
b)、JS层面。限制用户在x秒之内只能提交一次请求。

第二层，站点层面的请求拦截

怎么防止循环调用？有去重方法么？
ip？cookie-id？

秒杀类业务都需要登录，用uid即可。在站点层，对uid进行请求计数和去重。

第三层，服务层来拦截(反正就是不要让请求落到数据库上去)

一列火车只有2000张车票，10w个请求去数据库有什么意义呢？
没错，请求队列。
对于写请求做请求队列，每次只透有限的谢请求去数据层(下订单，支付这样的写业务)

1w部手机，只透1w个下单请求去db。
如果都成功再放下一批，如果库存不够，则队列中写请求全部返回“已售完”。

对于读请求怎么优化呢？cache抗，不管是memcached还是redis，单机抗个每秒10w都没有什么问题。

还有业务规则上的一些优化。
比如12306做的，分时分段售票。

Q&A

问题1：按你的架构，其实压力最大的反而是站点层，那么这部分压力怎么处理？
答：站点层是可以通过加机器扩容的；如果机器不够，抛弃50%的请求(直接返回稍后再试)，原则是保护系统，不能让所有用户都失败。