1.秒杀业务为什么难做
IM 系统，例如 QQ 或者微博，每个人都读自己的数据（好友列表、群列表、个人信息）。
微博系统，每个人读你关注的人的数据，一个人读多个人的数据。 秒杀系统，库存只有一份，所有人会在集中的时间读和写这些数据，多个人读一个数据。 例如小米手机每周二的秒杀，可能手机只有 1 万部，但瞬时进入的流量可能是几百几千万。又例如 12306 抢票， 票是有限的，库存一份，瞬时流量非常多，都读相同的库存。读写冲突，锁非常严重，这是秒杀业务难的地方。 那我们怎么优化秒杀业务的架构呢？
2.优化方向
优化方向有两个：
a.将请求尽量拦截在系统上游（不要让锁冲突落到数据库上去）。传统秒杀系统之所以挂，请求都压倒了后端数据层， 数据读写锁冲突严重，并发高响应慢，几乎所有请求都超时，流量虽大，下单成功的有效流量甚小。以 12306 为例， 一趟火车其实只有 2000 张票，200w 个人来买，基本没有人能买成功，请求有效率为 0。 b.充分利用缓存，秒杀买票，这是一个典型的读多些少的应用场景，大部分请求是车次查询，票查询，下单和支付 才是写请求。一趟火车其实只有 2000 张票，200w 个人来买，最多 2000 个人下单成功，其他人都是查询库存， 写比例只有 0.1%，读比例占 99.9%，非常适合使用缓存来优化。好，后续讲讲怎么个“将请求尽量拦截在系统上游” 法，以及怎么个“缓存”法，讲讲细节。
3.常见的秒杀架构
1.浏览器端，最上层，会执行到一些 JS 代码
2.站点层，这一层会访问后端数据，拼 HTML 页面返回给浏览器 3.服务层，向上游屏蔽底层数据细节，提供数据访问 4.数据层，最终的库存是存在这里的，MySQL 是一个典型（当然还有会缓存）
4.各层次优化细节
4.1 客户端优化-浏览器层，APP 层
秒杀页面
秒杀活动开始前，其实就有很多用户访问该页面了。如果这个页面的一些资源，比如 CSS、JS、图片、商品详情等， 都访问后端服务器，甚至 DB 的话，服务肯定会出现不可用的情况。所以一般我们会把这个页面整体进行静态化，并 将页面静态化之后的页面分发到 CDN 边缘节点上，起到压力分散的作用。 防止提前下单 防止提前下单主要是在静态化页面中加入一个 JS 文件引用，该 JS 文件包含活动是否开始的标记以及开始时的动态 下单页面的 URL 参数。同时，这个 JS 文件是不会被 CDN 系统缓存的，会一直请求后端服务的，所以这个JS文件 一定要很小。当活动快开始的时候（比如提前），通过后台接口修改这个 JS 文件使之生效。
4.2站点层面的请求拦截
API 接入层优化
客户端优化，对于不是搞计算机方面的用户还是可以防止住的。但是稍有一定网络基础的用户就起不到作用了，因此 服务端也需要加些对应控制，不能信任客户端的任何操作。一般控制分为 2 大类： 限制用户维度访问频率 针对同一个用户（ Userid 维度），做页面级别缓存，单元时间内的请求，统一走缓存，返回同一个页面。 限制商品维度访问频率 大量请求同时间段查询同一个商品时，可以做页面级别缓存，不管下回是谁来访问，只要是这个页面就直接返回。 好，这个方式拦住了写 for 循环发 HTTP 请求的程序员，有些高端程序员（黑客）控制了 10w 个肉鸡，手里有 10w 个 uid，同时发请求（先不考虑实名制的问题，小米抢手机不需要实名制），这下怎么办，站点层按照 uid 限流拦不住了。
4.3服务层来拦截
服务层怎么拦截？大哥，我是服务层，我清楚的知道小米只有 1 万部手机，我清楚的知道一列火车只有 2000 张
车票，我透 10w 个请求去数据库有什么意义呢？没错，请求队列！ 对于写请求，做请求队列，每次只透有限的写请求去数据层（下订单，支付这样的写业务）： 1w 部手机，只透 1w 个下单请求去 db： 3k 张火车票，只透 3k 个下单请求去 db。 如果均成功再放下一批，如果库存不够则队列里的写请求全部返回“已售完”。 对于读请求，怎么优化？Cache 抗，不管是 memcached 还是 redis，单机抗个每秒 10w 应该都是没什么问题的。如此限流，只有非常少的写请求，和非常少的读缓存 mis 的请求会透到数据层去，又有 99.9% 的请求被拦住了。 当然，还有业务规则上的一些优化。回想 12306 所做的，分时分段售票，原来统一 10 点卖票，现在 8 点，8点半， 9 点，... 每隔半个小时放出一批：将流量摊匀。 其次，数据粒度的优化：你去购票，对于余票查询这个业务，票剩了 58 张，还是 26 张，你真的关注么，其实我们 只关心有票和无票？流量大的时候，做一个粗粒度的 “有票”“无票”缓存即可。 第三，一些业务逻辑的异步：例如 下单业务与 支付业务的分离。这些优化都是结合 业务 来的，我之前分享过一个 观点“一切脱离业务的架构设计都是耍流氓”架构的优化也要针对业务。
4.4数据库层
服务接口的调用能起到限流的作用，但是是对同一件商品进行限流。大促期间访问到数据库这里的请求依然不容忽略。
如果数据库这层有2000个用户在同时进行秒杀操作，那么这个开销依然非常巨大。这时强烈建议用户开启数据库线程池 功能（注意：不是连接池），比如MySQL企业版的Thread Pool插件、社区版的Percona、InnoSQL数据库都支持 线程池。线程池的机制是每个用户的连接并不是一定会产生一个实际的硬连接，而是通过Pool机制从中进行分配， 也就是实际在数据库内部运行的线程数是固定的，减小上下文切换的时间，从而大幅提升数据库的性能。
5.总结
上文应该描述的非常清楚了，没什么总结了，对于秒杀系统，再次重复下我个人经验的两个架构优化思路：
1.尽量将请求拦截在系统上游（越上游越好）； 2.读多写少的常用多使用缓存（缓存抗读压力）； 浏览器和 APP：做限速。 站点层：按照 uid 做限速，做页面缓存。 服务层：按照业务做写请求队列控制流量， 做数据缓存。 数据层：闲庭信步。 以及结合业务做优化
6.Q&A
问题 1、按你的架构，其实压力最大的反而是站点层，假设真实有效的请求数有 1000 万，不太可能限制请求连接数吧，那么这部分的压力怎么处理？
答：每秒钟的并发可能没有 1kw，假设有 1kw，解决方案 2 个：
- 站点层是可以通过加机器扩容的，最不济 1k 台机器来呗。
- 如果机器不够，抛弃请求，抛弃 50%（50% 直接返回稍后再试），原则是要保护系统，不能让所有用户都失败。
问题 2、“控制了 10w 个肉鸡，手里有 10w 个 uid，同时发请求” 这个问题怎么解决哈？
答：上面说了，服务层写请求队列控制
问题 3： 限制访问频次的缓存，是否也可以用于搜索？例如 A 用户搜索了“手机”，B 用户搜索“手机”，优先使用 A 搜索后生成的缓存页面？
答：这个是可以的，这个方法也经常用在 “动态”运营活动页，例如短时间推送 4kw 用户 app-push 运营活动，做页面缓存。
问题 4：如果队列处理失败，如何处理？肉鸡把队列被撑爆了怎么办？
答：处理失败返回下单失败，让用户再试。队列成本很低，爆了很难吧。最坏的情况下，缓存了若干请求之后，后续请求都直接返回“无票”（队列里已经有 100w 请求了，都等着，再接受请求也没有意义了）。
问题 5：站点层过滤的话，是把 uid 请求数单独保存到各个站点的内存中么？如果是这样的话，怎么处理多台服务器集群经过负载均衡器将相同用户的响应分布到不同服务器的情况呢？还是说将站点层的过滤放到负载均衡前？
答：可以放在内存，这样的话看似一台服务器限制了 5s 一个请求，全局来说（假设有 10 台机器），其实是限制了 5s 10 个请求，解决办法：
- 加大限制（这是建议的方案，最简单）
- 在 nginx 层做 7 层均衡，让一个 uid 的请求尽量落到同一个机器上
问题 6：服务层过滤的话，队列是服务层统一的一个队列？还是每个提供服务的服务器各一个队列？如果是统一的一个队列的话，需不需要在各个服务器提交的请求入队列前进行锁控制？
答：可以不用统一一个队列，这样的话每个服务透过更少量的请求（总票数 / 服务个数），这样简单。统一一个队列又复杂了。
问题 7：秒杀之后的支付完成，以及未支付取消占位，如何对剩余库存做及时的控制更新 ？
答：数据库里一个状态，未支付。如果超过时间，例如 45 分钟，库存会重新会恢复（大家熟知的“回仓”），给我们抢票的启示是，开动秒杀后，45 分钟之后再试试看，说不定又有票哟。
问题 8：不同的用户 浏览同一个商品 落在不同的缓存实例 显示的库存完全不一样 请问老师怎么做缓存数据一致 或者是允许脏读？
答：目前的架构设计，请求落到不同的站点上，数据可能不一致（页面缓存不一样），这个业务场景能接受。但数据库层面真实数据是没问题的。
问题 9：就算处于业务把优化考虑 “3k 张火车票，只透 3k 个下单请求去 db”那这 3k 个订单就不会发生拥堵了吗？
答：（1）数据库抗 3k 个写请求还是 ok 的；（2）可以数据拆分；（3）如果 3k 扛不住，服务层可以控制透过去的并发数量，根据压测情况来吧，3k 只是举例；
问题 10：如果在站点层或者服务层处理后台失败的话，需不需要考虑对这批处理失败的请求做重放？还是就直接丢弃？
答：别重放了，返回用户查询失败或者下单失败吧，架构设计原则之一是“fail fast”。
问题 11：对于大型系统的秒杀，比如 12306，同时进行的秒杀活动很多，如何分流？
答：垂直拆分
问题 12：额外又想到一个问题。这套流程做成同步还是异步的？如果是同步的话，应该还存在会有响应反馈慢的情况。但如果是异步的话，如何控制能够将响应结果返回正确的请求方？
答：用户层面肯定是同步的（用户的 HTTP 请求是夯住的），服务层面可以同步可以异步。
问题 13：秒杀群提问：减库存是在那个阶段减呢？如果是下单锁库存的话，大量恶意用户下单锁库存而不支付如何处理呢？
答：数据库层面写请求量很低，还好，下单不支付，等时间过完再“回仓”，之前提过了。