面对抢购,怎么处理并发

秒杀活动多个方面联合起来实现，才功能完善。需要处理的是请求阻塞在哪里，针对阻塞的点进行优化
在抢购前一段时间内会不断刷新商品详情页
返回的现象：1.返回一个页面 2.不让你刷新
详情页请求并发量高 有可能会造成阻塞

系统时间：抢购时间会有一个倒计时的按钮
添加一个时间戳，调用系统的时间和刷新页面的当前时间相减得到一个倒计时时间，都是调用系统的时间，只要刷新，会一直重复不停的调用系统的时间来显示倒计时

地址暴露接口：抢购的接口暴露，用很多的请求去请求抢购的接口

支付的频率，1数据库的更新操作，2卡在支付的频率
抢购系统也就是秒杀系统，要处理秒杀系统的的并发问题，并不是某一个方面就能实现的，要多方面采取措施来实现。首先我们要清楚，高并发发生在哪些部分，然后正对不同的模块来进行优化。一般会发生在下图红色部分。

如何解决上面问题呢？主要从两个方面入手：
（1）将请求尽量拦截在系统上游（不要让锁冲突落到数据库上去）。传统秒杀系统之所以挂，请求都压倒了后端数据层，数据读写锁冲突严重，并发高响应慢，几乎所有请求都超时，流量虽大，下单成功的有效流量甚小。以12306为例，一趟火车其实只有2000张票，200w个人来买，基本没有人能买成功，请求有效率为0。
（2）充分利用缓存，减少对数据库写的操作。秒杀买票，这是一个典型的读多写少的应用场景，大部分请求是车次查询，票查询，下单和支付才是写请求。一趟火车其实只有2000张票，200w个人来买，最多2000个人下单成功，其他人都是查询库存，写比例只有0.1%，读比例占99.9%，非常适合使用缓存来优化。好，后续讲讲怎么个“将请求尽量拦截在系统上游”法，以及怎么个“缓存”法，讲讲细节.

具体实施可以从几个方面考虑：
前端方面

1. 把详情页部署到CDN节点上
   用户在秒杀开始之前，会对详情页做大量的刷新操作。 所以我们将详情页部署到CDN上，CDN将详情页做静态化处理。 这样其实用户访问的静态页的html已经不在秒杀系统上了，而在CDN节点上。
   
   静态化好的页面都存放在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. 业务逻辑的异步处理
   下单的时候要修改数据库，处了创建订单之外还要修改商品的库存，商品的销量，涉及到三张表同时进行。例如下单业务与支付业务的分离,下单成功后可以将支付业务单独异步处理，与抢购的业务分离，分别放到不同的服务器进行，减少对业务处理的压力。