架构 秒杀系统优化思路.pdfVIP

架构 秒杀系统优化思路 本⽂曾在“架构师之路”上发布过，近期⽀援Qcon-AS⼤会，在微信群⾥分享了该话 题，故 原⽂进⾏重新整理与发布。 ⼀、秒杀业务为什么难做 1）im系统，例如qq或者微博，每个⼈都读⾃⼰的数据 （好友列表、群列表、个⼈信 息）； 2 ）微博系统，每个⼈读你关注的⼈的数据，⼀个⼈读多个⼈的数据； 3 ）秒杀系统，库存只有⼀份，所有⼈会在集中的时间读和写这些数据，多个⼈读⼀ 个数据。 例如：⼩⽶⼿机每周⼆的秒杀，可能⼿机只有1万部，但瞬时进⼊的流量可能是⼏百 ⼏千万。 又例如：12306抢票，票是有限的，库存⼀份，瞬时流量⾮常多，都读相同的库存。 读写冲突，锁⾮常严重，这是秒杀业务难 地⽅。那我们怎么优化秒杀业务的架构 呢？ ⼆、优化⽅向 优化⽅向有两个 （今天就讲这两个点）： （1）将请求尽量拦截在系统上游 （不要让锁冲突落到数据库上去）。传统秒杀系统 之所以挂，请求都压倒了后端数据层，数据读写锁冲突严重，并发⾼响应慢，⼏乎所 有请求都超时，流量虽⼤，下单成功的有效流量甚⼩。以12306为例，⼀趟⽕车其实 只有2000张票，200w个⼈来买，基本没有⼈能买成功，请求有效率为0 。 （2 ）充分利⽤缓存，秒杀买票，这是⼀个典型的读多些少的应⽤场景，⼤部分请求 是车次查询，票查询，下单和⽀付才是写请求。⼀趟⽕车其实只有2000张票，200w个 ⼈来买，最多2000个⼈下单成功，其他⼈都是查询库存，写⽐例只有0 .1% ，读⽐例占 99.9% ，⾮常适合使⽤缓存来优化。好，后续讲讲怎么个“将请求尽量拦截在系统上 游”法，以及怎么个“缓存”法，讲讲细节。 三、常见秒杀架构 常见的站点架构基本是这样的 （绝 不画忽悠类的架构图） （1）浏览器端，最上层，会执⾏到⼀些JS代码 （2 ）站点层，这⼀层会访问后端数据，拼html页⾯返回给浏览器 （3 ）服务层，向上游屏蔽底层数据细节，提供数据访问 （4 ）数据层，最终的库存是存在这⾥的，mysql是⼀个典型 （当然还有会缓存） 这个图虽然简单，但能形象的说明⼤流量⾼并发的秒杀业务架构，⼤家要记得这⼀张 图。后⾯细细解析各个层级怎么优化。 四、各层次优化细节 第⼀层，客户端怎么优化 （浏览器层，APP层） 问⼤家⼀个问题，⼤家都玩过微信的摇⼀摇抢红包 吧，每次摇⼀摇，就会往后端发 送请求么？回顾我们下单抢票的场景，点击了“查询”按钮之后，系统那个卡呀，进度 条涨的慢呀，作为⽤户，我会不⾃觉的再去点击“查询” ， 么？继续点，继续点，点 点点。。。有⽤么？平⽩⽆故的增加了系统负载，⼀个⽤户点5次，80%的请求是这么 多出来的，怎么整？ （a ）产品层⾯，⽤户点击“查询”或者“购票”后，按钮置灰，禁⽌⽤户重复提交请求； （）JS层⾯，限制⽤户在x秒之内只能提交⼀次请求； APP层⾯，可以做类似的事情，虽然你疯狂的在摇微信，其实x秒才向后端发起⼀次请 求。这就是所谓的“将请求尽量拦截在系统上游” ，越上游越好，浏览器层，APP层就 给拦住，这样就能挡住80%+的请求，这种办法只能拦住普通⽤户 （但99%的⽤户是普 通⽤户） 于群内的⾼端程序员是拦不住的。fire ug⼀抓包，http长啥样都知道，j s是 万万拦不住程序员写for循环，调⽤http接⼜的，这部分请求怎么处理？ 第⼆层，站点层⾯ 请求拦截 怎么拦截？怎么防⽌程序员写for循环调⽤，有去重依据么？ip ？cookie-id ？…想复杂 了，这类业务都需要登录，⽤uid 即可。在站点层⾯， uid进⾏请求计数和去重，甚 ⾄不需要统⼀存储计数，直接站点层内存存储 （这样计数会不准，但最简单）。⼀个 uid ，5秒只准透过1个请求，这样又能拦住99%的for循环请求。 5s只透过⼀个请求，其余的请求怎么办？缓存，页⾯缓存，同⼀个uid ，限制访问频 度，做页⾯缓存，x秒内到达站点层的请求，均返回同⼀页⾯。同⼀个item的查询，例 如车次，做页⾯缓存，x秒内到达站点层的请求，均返回同⼀页⾯。如此限流，既能 保证⽤户有良好的⽤户体验 （没有返回404 ）又能保证系统的健壮性 （利⽤页⾯缓 存，把请求拦截在站点层了）。 页⾯缓存不⼀定要保证所有站点返回⼀致的页⾯，直接放在每个站点的内存也是可以 的。优点是简单，坏处是http请求落到不同的站点，返回的车票数据可能不⼀样，这 是站点层的请求拦截与缓存优化。 好，这个⽅式拦住了写for循环发http请求的程序员，有些⾼端程序员 （⿊客）控制了 10w个⾁鸡，⼿⾥有10w个uid ，同时发请求