关键词：
一、问题的提出
秒杀或抢购活动一般会经过 预约，下单，支付 ，扛不住的地方在于下单，一般会带来2个问题：
1、高并发
比较火热的秒杀在线人数都是10w起的，如此之高的在线人数对于网站架构从前到后都是一种考验。
2、超卖
任何商品都会有数量上限，如何避免成功下订单买到商品的人数不超过商品数量的上限，这是每个抢购活动都要面临的难题。
秒杀系统难做的原因：库存只有一份，瞬间大量用户读和写这些数据。
例如小米手机每周二的秒杀，可能手机只有1万部，但瞬时进入的流量可能是几百几千万
二、架构
常见站点架构如下
1）浏览器端，最上层，会执行到一些JS代码
2）站点层，这一层会访问后端数据，返回数据给浏览器
3）服务层，向上游屏蔽底层数据细节
4）数据层，最终的库存是存在这里的
三、优化思路
1、将请求尽量拦截在上游：传统秒杀系统之所以挂，请求都压倒了后端数据层，数据库读写锁冲突严重，导致响应慢，下单基本不能成功
2、利用缓存：这是一个典型的读多些少的应用场景，非常适合使用缓存
四、优化细节
1 、浏览器层请求拦截
a）产品层面，用户点击“查询”或者“购票”后，按钮置灰，禁止用户重复提交请求
b）js层面，限制用户在x秒之内只能提交一次请求
可以拦截很多无效请求
2、站点层请求拦截与页面缓存
防止像服务器直接发送过多的恶意http请求
a）同一个uid，限制访问频度，做页面缓存，x秒内到达站点层的请求，均返回同一页面
b）同一个item的查询，例如手机车次，做页面缓存，x秒内到达站点层的请求，均返回同一页面
可以拦截很多无效请求
3、服务层请求拦截与数据缓存
a）给过多的请求去数据库有什么意义呢？对于写请求，做请求队列，每次只透过有限的写请求去数据层，如果均成功再放下一批，如果库存不够则队列里的写请求全部返回“已售完
b）对于读请求，cache来抗，用memcached or redis（10wqps）
如此限流，只有非常少的写请求，和非常少的读缓存mis的请求会透到数据层去
4、数据层闲庭信步
到了数据这一层，几乎就没有什么请求了，库存是有限的，透过过多请求来数据库没有意义
五、解决方案
关于超卖，首先设定一个前提，为了防止超卖现象，所有减库存操作都需要进行一次减后检查，保证减完不能等于负数。（由于MySQL事务的特性，这种方法只能降低超卖的数量，但是不可能完全避免超卖）
update number set x=x-1 where (x -1 ) >= 0;
解决方案1：
将存库从MySQL前移到Redis中，所有的写操作放到内存中，由于Redis中不存在锁故不会出现互相等待，并且由于Redis的写性能和读性能都远高于MySQL，这就解决了高并发下的性能问题。然后通过队列等异步手段，将变化的数据异步写入到DB中。
优点：解决性能问题
缺点：没有解决超卖问题，同时由于异步写入DB，存在某一时刻DB和Redis中数据不一致的风险。
解决方案2：
引入队列，然后将所有写DB操作在单队列中排队，完全串行处理。当达到库存阀值的时候就不在消费队列，并关闭购买功能。这就解决了超卖问题。
优点：解决超卖问题，略微提升性能。
缺点：性能受限于队列处理机处理性能和DB的写入性能中最短的那个，另外多商品同时抢购的时候需要准备多条队列。
解决方案3：
将写操作前移到MC中，同时利用MC的轻量级的锁机制CAS来实现减库存操作。
优点：读写在内存中，操作性能快，引入轻量级锁之后可以保证同一时刻只有一个写入成功，解决减库存问题。
缺点：没有实测，基于CAS的特性不知道高并发下是否会出现大量更新失败？不过加锁之后肯定对并发性能会有影响。
解决方案4：
将提交操作变成两段式，先申请后确认。然后利用Redis的原子自增操作（相比较MySQL的自增来说没有空洞），同时利用Redis的事务特性来发号，保证拿到小于等于库存阀值的号的人都可以成功提交订单。然后数据异步更新到DB中。
优点：解决超卖问题，库存读写都在内存中，故同时解决性能问题。
缺点：由于异步写入DB，可能存在数据不一致。另可能存在少买，也就是如果拿到号的人不真正下订单，可能库存减为0，但是订单数并没有达到库存阀值。
总结
扩容+限流+内存缓存+排队
秒杀系统架构优化思路
...总结】上文应该描述的非常清楚了，没什么总结了，对于秒杀系统，再次重复下我个人经验的两个架构优化思路：（1）尽量将请求拦截在系统上游（越上游越好）；（2）读多写少的常用多使用缓存（缓存抗读压力）；浏览器和A... 查看详情
关于秒杀的场景特点分析
关于秒杀的场景特点分析秒杀系统的场景特点-秒杀时大量用户会在同一时间同时进行抢购，网站瞬时访问流量激增；-秒杀一般是访问请求量远远大于库存数量，只有少部分用户能够秒杀成功；-秒杀业务流程比较简单，一般... 查看详情
关于秒杀的场景特点分析
关于秒杀的场景特点分析秒杀系统的场景特点-秒杀时大量用户会在同一时间同时进行抢购，网站瞬时访问流量激增；-秒杀一般是访问请求量远远大于库存数量，只有少部分用户能够秒杀成功；-秒杀业务流程比较简单，一般... 查看详情
秒杀系统架构优化思路
一、为什么难秒杀系统难做的原因：库存只有一份，所有人会在集中的时间读和写这些数据。例如小米手机每周二的秒杀，可能手机只有1万部，但瞬时进入的流量可能是几百几千万。又例如12306抢票，亦与秒杀类似，瞬时流量更... 查看详情
电商网站秒杀与抢购的系统架构
...来的挑战在过去的工作中，我曾经面对过5w每秒的高并发秒杀功能，在这个过程中，整个Web系统遇到了很多的问题和挑战。如果Web系统不做针对性的优化，会轻而易举地陷入到异常状态。我们现在一起来讨论下，优化的思路和方... 查看详情
秒杀系统架构优化思路
一、秒杀业务为什么难做1）im系统，例如qq或者微博，每个人都读自己的数据（好友列表、群列表、个人信息）；2）微博系统，每个人读你关注的人的数据，一个人读多个人的数据；3）秒杀系统，库存只有一份，所有人会在集... 查看详情
转载秒杀系统架构优化思路
...分享了该话题，故对原文进行重新整理与发布。 一、秒杀业务为什么难做1）im系统，例如qq或者微博，每个人都读自己的数据（好友列表、群列表、个人信息）；2）微博系统，每个人读你关注的人的数据，一个人读多个人的... 查看详情
58沈剑架构系列秒杀系统架构优化思路
一、秒杀业务为什么难做1）im系统，例如qq或者微博，每个人都读自己的数据（好友列表、群列表、个人信息）；2）微博系统，每个人读你关注的人的数据，一个人读多个人的数据；3）秒杀系统，库存只有一份，所有人会在集... 查看详情
阿里秒杀系统架构优化思路
秒杀业务为什么难做im系统，例如qq或者微博，每个人都读自己的数据（好友列表、群列表、个人信息）微博系统，每个人读你关注的人的数据，一个人读多个人的数据秒杀系统，库存只有一份，所有人会在集中的时间读和写这... 查看详情
秒杀系统架构优化思路
...分享了该话题，故对原文进行重新整理与发布。一、秒杀业务为什么难做1）im系统，例如qq或者微博，每个人都读自己的数据（好友列表、群列表、个人信息）；2）微博系统，每个人读你关注 查看详情
秒杀的设计思路
电商：如何设计一个秒杀系统 什么是秒杀秒杀场景一般会在电商网站举行一些活动或者节假日在12306网站上抢票时遇到。对于电商网站中一些稀缺或者特价商品，电商网站一般会在约定时间点对其进行限量销售，因为这... 查看详情
看了这个高并发系统架构，才知道我对秒杀的误解有多深
...发系统？今天，我们就一起解密高并发业务场景下典型的秒杀系统的架构，让大 查看详情
秒杀系统设计优化(代码片段)
...相同的库存，读写冲突，锁非常严重；小米手机每周二的秒杀，可能手机只有1万部，但瞬时进入的流量可能是几百几千万；这是秒杀业务难的地方。那我们怎么优化秒杀系统呢？一、难点（1）高并发用户在秒杀开始前，通过不... 查看详情
秒杀系统架构优化思路
...分享了该话题，故对原文进行重新整理与发布。一、秒杀业务为什么难做1）im系统，例如qq或者微博，每个人都读自己的数据（好友列表、群列表、个人信息）；2）微博系统，每个人读你关注的... 查看详情
“秒杀系统优化思路”记录
...，然后流量直接到redis上。后面可以试试加上排队。关于他们说的读写分离，emmm，我采用的是直接将这项业务隔离开，因为主从复制是需要时间的，对于这种秒杀掉的票，怎么分离嘛。 查看详情
秒杀系统优化思路
一、秒杀业务为什么这么难做秒杀系统，库存只有一份，所有人会在集中的时间读和写这些数据。例如：小米手机每周二的秒杀，可能手机只有1万部，但瞬间进入的流量可能是几百几千万。12306抢票，票是有限的，但是抢票的人... 查看详情
亿级流量架构实战之双十一秒杀架构设计(代码片段)
...种处理思路,这儿将这些思路与业务综合起来,情形一就是秒杀,提到秒杀,很多人都会觉得这是一件技术要求很高的事情,因为这涉及到超大访问量(可能瞬间千万倍的用户访问商品)、维护数据一致性(不能超卖),前者对性能有极高的... 查看详情
2017-5-26/描述一个高性能高可靠的网站架构——如何设计一个秒杀系统
一、秒杀的应用场景电商网站的抢购活动、12306网站的抢票、抢红包。 二、秒杀的特点1、秒杀时大量用户会在同一时间同时进行抢购，网站瞬时访问流量激增。2、数据库的并发读写冲突以及资源的锁请求冲突非常严重。3、... 查看详情