秒杀讨论会.docx

58到家CTO沈剑秒杀讨论记录
出自ENode社区,FMN笔记
业务分析
常见业务分析
im系统(例如qq),每个人都读自己的数据(好友列表、群列表、个人信息)
微博系统,每个人读你关注的人的数据,数据源多秒杀系统,库存只有一份,所有人会在集中的时间读和写这些数据。
例如小米手机每周二的秒杀,可能手机只有1万部,但瞬时进入的流量可能是几百几千万。又例如12306抢票,票是有限的,库存一份,瞬时流量非常多,都读相同的库存。读写冲突,锁非常严重,这是秒杀业务难的地方。那我们怎么优化秒杀业务的架构呢?
优化方向
优化方向有两种
请求拦截在系统上游
将请求尽量拦截在系统上游(不要让锁冲突落到数据库上去)传统秒杀系统之所以挂,请求都压倒了后端数据层,数据读写锁冲突严重
并发高响应慢,几乎所有请求都超时
流量虽大,下单成功的有效流量甚小
以12306为例,一趟火车其实只有2000张票,200w个人来买,基本没有人能买成功,请求有效率为0
充分利用缓存
秒杀买票,这是一个典型的读多些少的应用场景
大部分请求是车次查询,票查询,下单和支付才是写请求
一趟火车其实只有2000张票,200w个人来买,最多2000个人下单成功,其他人都是查询库存,%,%
非常适合使用缓存来优化
好,后续讲讲怎么个“将请求尽量拦截在系统上游”法,以及怎么个“缓存”法,讲讲细节
常见秒杀结构
常见的站点架构基本是这样的(特别是流量上亿的站点架构)
1)浏览器端,最上层,会执行到一些JS代码
2)站点层,这一层会访问后端数据,拼html页面返回给浏览器
3)服务层,向上游屏蔽底层数据细节,提供数据访问
4)数据层,最终的库存是存在这里的,mysql是一个典型(当然还有会缓存)
各层次优化细节
客户端怎么优化(浏览器层,APP层)
案例场景:
微信的摇一摇抢红包
每次摇一摇,就会往后端发送请求么?
回顾我们下单抢票的场景,点击了“查询”按钮之后,系统那个卡呀,进度条涨的慢呀,作为用户,我会不自觉的再去点击“查询”,对么?继续点,继续点,点点点。。。有用么?平白无故的增加了系统负载
一个用户点5次,80%的请求是这么多出来的
怎么玩?
产品层面
用户点击“查询”或者“购票”后,按钮置灰,禁止用户重复提交请求
JS层面
限制用户在x秒之内只能提交一次请求
APP层面
可以做类似的事情,虽然你疯狂的在摇微信,其实x秒才向后端发起一次请求这就是所谓的“将请求尽量拦截在系统上游”,越上游越好
浏览器层,APP层就给拦住,这样就能挡住80%+的请求
这种办法只能拦住小白用户(但99%的用户是小白用户)
案例场景:(对于直接调用http接口的措施)
请求如何处理?第二层,站点层面的请求拦截
怎么拦截?怎么防止程序员写for循环调用?有去重依据么?ip?cookie-id?
想复杂了,这类业务都需要登录
用uid即可
站点层面
在站点层面,对uid进行计数和去重
不需要统一存储计数,直接站点层内存存储(这样计数会不准,但最简单)
一个uid,5秒只准透过1个请求
这样又能拦住99%的for循环请求
5s只透过一个请求,其余的请求怎么办?
缓存
页面缓存,同一个uid,限制访问频度,做页面缓存,x秒内到达站点层的请求,均返回同一页面,同一个item的查询,例如车次,做页面缓存,x秒内到达站点层的请求,均返回同一页面,如此限流,既能保证用户有良好的用户体验(没有返回404),又能保证系统的健壮性(利用缓存,把请求拦截在站点层了)页面缓存也不一定要保证所有站点的页面返回一致,直接放在每个站点的内存也是可以的
优点是简单
坏处是http请求落到不同的站点,返回的车票数据可能不一样,这是站点层的请求拦截与缓存优化。
案例场景:(控制肉鸡,使用多个uid同时发请求)
第三层服务层来拦截
反正就是不要让请求落到数据库上去
使用请求队列
对于写请求,做请求队列,每次只透有限的写请求去数据层(下订单,支付这样的写业务)
1w部手机,只投1w个下单请求去db
3k张火车票,只透3k个下单请求去db
如果均成功再放下一批,如果库存不够则队列里的写请求全部返回“已售完”
对于读请求,怎么优化?cache抗
不管是memcached还是redis,单机抗个每秒10w应该都是没什么问题的
如此限流,只有非常少的写请求,和非常少的读缓存mis的请求会透到数据层去,%的请求被拦住了
当然,还有业务规则上的一些优化
回想12306所做的
分时分段售票
原来统一10点卖票
现在8点,8点半,9点,...,每