面对抢购,怎么处理并发

面对抢购,怎么处理并发

抢购系统也就是秒杀系统，要处理秒杀系统的的并发问题，并不是某一个方面就能实现的，要多方面采取措施来实现。首先我们要清楚，高并发发生在哪些部分，然后正对不同的模块来进行优化。一般会发生在下图红色部分。 如何解决上面问题呢？主要从两个方面入手： （1）将请求尽量拦截在系统上游（不要让锁冲突落到数据库上去）。传统秒杀系统之所以挂，请求都压倒了后端数据层，数据读写锁冲突严重，并发高响应慢，几乎所有请求都超时，流量虽大，下单成功的有效流量甚小。以12306为例，一趟火车其实只有2000张票，200w个人来买，基本没有人能买成功，请求有效率为0。 （2）充分利用缓存，秒杀买票，这是一个典型的读多写少的应用场景，大部分请求是车次查询，票查询，下单和支付才是写请求。一趟火车其实只有2000张票，200w个人来买，最多2000个人下单成功，其他人都是查询库存，写比例只有0.1%，读比例占99.9%，非常适合使用缓存来优化。好，后续讲讲怎么个“将请求尽量拦截在系统上游”法，以及怎么个“缓存”法，讲讲细节. 具体实施可以从几个方面考虑：

前端方面 1. 把详情页部署到CDN节点上 用户在秒杀开始之前，会对详情页做大量的刷新操作。 所以我们将详情页部署到CDN上，CDN将详情页做静态化处理。 这样其实用户访问的静态页的html已经不在秒杀系统上了，而在CDN节点上。 2. 禁止重复提交请求、对用户请求限流 （a）禁止重复提交 用户点击“查询”或者“购票”后，按钮置灰，禁止用户重复提交请求； （b）用户限流 限制用户在x秒之内只能提交一次请求； 后端方面 1.根据用户id限制访问频率，对同样请求返回同一个页面 秒杀活动都会要求用户进行登录， 对于同一个UID在X秒内发来的多次请求进行计数或者去重，限制在X秒内只有一个请求到达后端接口，其余的请求怎么办呢？使用页面缓存，X秒内到达后端接口的请求，均返回同一页面。如此限流，既能保证用户有良好的用户体验（没有返回404）又能保证系统的健壮性（利用页面缓存，把请求拦截在站点层了）。 2. 服务层进行优化 （a）采用消息队列缓存请求：既然服务层知道库存只有100台手机，那完全没有必要把100W个请求都传递到数据库，那么可以先把这些请求都写到消息队列缓存一下，数据库层订阅消息减库存，减库存成功的请求返回秒杀成功，失败的返回秒杀结束。 (b) 利用缓存应对读请求：对类似于12306等购票业务，是典型的读多写少业务，大部分请求是查询请求，所以可以利用缓存(Redis/Memcached)分担数据库压力。 © 利用缓存应对写请求： 缓存也是可以应对写请求的，比如我们就可以把数据库中的库存数据转移到Redis缓存中，所有减库存操作都在Redis中进行，然后再通过后台进程把Redis中的用户秒杀请求同步到数据库中。

业务方面 1. 分时分段销售，将流量均摊 例如，原来统一10点，现在8点， 9点，…每隔半个小时放出一批 2. 请求多时，对数据粒度进行缓存 以12306购票为例子，你去购票，对于余票查询这个业务，票剩了58张，还是26张，你真的关注么，其实我们只关心有票和无票？流量大的时候，做一个粗粒度的“有票”“无票”缓存即可 3. 业务逻辑的异步处理 例如下单业务与支付业务的分离,下单成功后可以将支付业务单独异步处理，与抢购的业务分离，减少对业务处理的压力。