秒杀讨论会剖析.docxVIP

58到家CTO沈剑秒杀讨论记录 出自ENode社区,FMN笔记 1 业务分析 1.1 常见业务分析 a) im系统（例如qq），每个人都读自己的数据（好友列表、群列表、个人信息） b) 微博系统，每个人读你关注的人的数据，数据源多秒杀系统，库存只有一份，所有人会在集中的时间读和写这些数据。 例如小米手机每周二的秒杀，可能手机只有1万部，但瞬时进入的流量可能是几百几千万。又例如12306抢票，票是有限的，库存一份，瞬时流量非常多，都读相同的库存。读写冲突，锁非常严重，这是秒杀业务难的地方。那我们怎么优化 秒杀 业务的架构呢？ 2 优化方向 2.1 优化方向有两种 2.1.1 请求拦截在系统上游 将请求尽量拦截在系统上游（不要让锁冲突落到数据库上去）传统秒杀系统之所以挂，请求都压倒了后端数据层，数据读写锁冲突严重 并发高响应慢，几乎所有请求都超时 流量虽大，下单成功的有效流量甚小 以12306为例，一趟火车其实只有2000张票，200w个人来买，基本没有人能买成功，请求有效率为0 2.1.2 充分利用缓存 秒杀买票，这是一个典型的读多些少的应用场景 大部分请求是车次查询，票查询，下单和支付才是写请求 一趟火车其实只有2000张票，200w个人来买，最多2000个人下单成功，其他人都是查询库存，写比例只有0.1%，读比例占99.9% 非常适合使用缓存来优化 好，后续讲讲怎么个“将请求尽