秒杀讨论会介绍.docx

58到家CTO沈剑秒杀讨论记录 出自ENode社区,FMN笔记 业务分析 常见业务分析 im系统（例如qq），每个人都读自己的数据（好友列表、群列表、个人信息） 微博系统，每个人读你关注的人的数据，数据源多秒杀系统，库存只有一份，所有人会在集中的时间读和写这些数据。 例如小米手机每周二的秒杀，可能手机只有1万部，但瞬时进入的流量可能是几百几千万。又例如12306抢票，票是有限的，库存一份，瞬时流量非常多，都读相同的库存。读写冲突，锁非常严重，这是秒杀业务难的地方。那我们怎么优化 秒杀 业务的架构呢？ 优化方向 优化方向有两种 请求拦截在系统上游 将请求尽量拦截在系统上游（不要让锁冲突落到数据库上去）传统秒杀系统之所以挂，请求都压倒了后端数据层，数据读写锁冲突严重 并发高响应慢，几乎所有请求都超时 流量虽大，下单成功的有效流量甚小 以12306为例，一趟火车其实只有2000张票，200w个人来买，基本没有人能买成功，请求有效率为0 充分利用缓存 秒杀买票，这是一个典型的读多些少的应用场景 大部分请求是车次查询，票查询，下单和支付才是写请求 一趟火车其实只有2000张票，200w个人来买，最多2000个人下单成功，其他人都是查询库存，写比例只有0.1%，读比例占99.9% 非常适合使用缓存来优化 好，后续讲讲怎么个“将请求尽量拦截在系统上游”法，以及怎么个“缓存”法，讲讲细节 常见秒杀结构 常见的站点架构基本是这样的（特别是流量上亿的站点架构） 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的请求会透到数据层去，又有99.9%的请求被拦住了 当然，还有业务规则上的一些优化 回想12306所做的 分时分段售票 原来统一10点卖票 现在8点，8点半，9点，...，每隔半个小时放出一批 将流量摊匀 数据粒度的优化 你去购票，对于余票查询这个业务，票剩了58张，还是26张，你真的关注么？流量大的时候