将从11 个点来进行秒杀系统得设计与实现分析。
1、哪些地方存在瞬时高并发？
- 1. 预抢购业务：活动未正式开始前，先进行活动预约。在真正秒杀的时间点，很多数据都是预处理好的了，可以很大程度削减系统压力。比如：活动预约、订金预约、火车票预约等
- 2. 分批抢购业务：分时段多场次抢购，比如我们熟悉的京东满减优惠券就是分场次开放的，整点抢购。
- 3. 实时秒杀：这是最有难度的秒杀场景，比如双11晚上0点秒杀，在这个时间点前后会涌入高并发流量：频繁刷新页面、疯狂点击抢购按钮、甚至利用机器模拟请求。
2、活动页面得设计
因为用户浏览商品等常规操作，并不会请求到服务端。只有到了秒杀时间点，并且用户主动点了秒杀按钮才允许访问服务端。所以为了减少不必要的服务端请求，通常情况下，会对活动页面做静态化处理。
CDN，它的全称是Content Delivery Network，即内容分发网络。用于用户分布在全国各地，有些人在北京，有些人在上海，有些人在深圳，地域相差很远，网速各不相同得情况。
3、秒杀按钮
使用js文件控制秒杀活动在活动开始前得秒杀按钮，可以通过在js中设置标记的方式来设置按钮的状态，比如isBegin=true代表活动开始，isBegin=false代表活动未开始。秒杀开始之前，js标志为false，秒杀活动开始时设置为true。为了达到这个效果，我们另外还需要一个随机参数用来主动刷新CDN。
当秒杀开始的时候系统会生成一个新的js文件，此时标志为true，并且随机参数生成一个新值，然后同步给CDN。由于有了这个随机参数，CDN不会缓存数据，每次都能从CDN中获取最新的js代码。
4、多读写少
这种情况下就要考虑做缓存，使用 redis对访问读得数据进行缓存。
5、缓存怎么做？
缓存雪崩：大量缓存数据同时过期、redis宕机故障。解决方法：给key添加随机过期时间。
缓存击穿：热点数据缓存过期，一个或几个高并发使用得Key失效。 解决方法：分布式锁，redis里面没有的时候，查数据库得时候要先获取分布式锁。 预热，事先把参与秒杀的所有商品，同步到缓存中，这样商品基本都能直接从缓存中获取到，就不会出现缓存击穿的问题了。双保险
缓存穿透：数据不存在，既不在redis里面，也不在数据库里面。解决方法：布隆过滤器，布隆过滤器（BloomFilter）是一种数据结构。特点是存在性检测，如果布隆过滤器中不存在，那么实际数据一定不存在；如果布隆过滤器中存在，实际数据不一定存在。相比于传统数据结构（如：List、Set、Map等）来说，它更高效，占用空间更少。缺点是它对于存在的判断是具有概率性。但是有一个数据一致性问题，所以布隆过滤器建议使用在缓存数据更新很少的场景中。
可以巧妙设计一下，把不存在的商品id也缓存起来。
6、库存问题
为了防止超卖或负数得情况，就要考虑 预扣库存。
数据库扣减库存：基于数据库的乐观锁，这样会少一次数据库查询，而且能够天然的保证数据操作的原子性。
redis扣减库存：redis的incr方法是原子性的，可用于扣减库存 。
- 先判断该用户有没有秒杀过该商品，如果已经秒杀过，则直接返回-1。
- 扣减库存，判断返回值是否小于0，如果小于0，则直接返回0，表示库存不足。
- 如果扣减库存后，返回值大于或等于0，则将本次秒杀记录保存起来。然后返回1，表示成功。
Lua脚本扣减库存：使用Lua脚本的好处如下:
- 减少网络开销：可以将多个请求通过脚本的形式一次发送，减少网络时延
- 原子操作：redis会将整个脚本作为一个整体执行，中间不会被其他请求插入。因此在脚本执行过程中无需担心会出现竞态条件，无需使用事务
- 复用：客户端发送的脚本会永久存在redis中，这样其他客户端可以复用这一脚本，而不需要使用代码完成相同的逻辑
7、分布式锁
使用redis的set命令：result,err := redis.set(lockKey, requestId, "NX", "PX", expireTime);
- lockKey：锁的标识
- requestId：请求id。在释放锁得时候，使用记录得requestId。
- NX：只在键不存在时，才对键进行设置操作。
- PX：设置键的过期时间为 millisecond 毫秒。
- expireTime：过期时间
自旋锁：思路如下：
- 在规定的时间，比如500毫秒内，自旋不断尝试加锁
- 如果成功则直接返回
- 如果失败，则休眠50毫秒，再发起新一轮的尝试。
- 如果到了超时时间，还未加锁成功，则直接返回失败。
8、mq异步处理
如果使用mq，需要关注以下几个问题：
- 消息丢失问题
- 消息重复消费问题
- 垃圾消息问题
- 延迟消费问题
8.1、消息丢失问题：加一张消息发送表、进行消息重发。
其流程如下：
- 在生产者发送mq消息之前，先把该条消息写入消息发送表，初始状态是待处理
- 然后再发送mq消息。
- 消费者消费消息时，回调生产者的一个接口，处理完业务逻辑之后，修改消息状态为已处理。
使用job，增加重试机制。用job每隔一段时间去查询消息发送表中状态为待处理的数据，然后重新发送mq消息。
8.2、重复消费问题：加一张消息处理表
8.3、 垃圾消息问题：限制重试次数
8.4、 延迟消费问题：使用延迟队列，比如：RocketMQ，自带了延迟队列的功能。
- 下单时消息生产者首先生成订单，此时为待支付状态。
- 然后向延迟队列中发一条消息。
- 当达到了延迟时间，消息消费者读取消息之后，会查询该订单的状态是否为待支付。
- 如果是待支付状态，则会更新订单状态为取消状态。
- 如果不是待支付状态，说明该订单已经支付过了，则直接返回。
9、限流
对同一用户限流、对同一ip限流、 对接口限流、 加验证码、提高业务门槛。
提高业务门槛流程是仿12306进行业务设计：
- 我们可以通过提高业务门槛，比如只有会员才能参与秒杀活动，普通注册用户没有权限。
- 或者只有等级到达3级以上的用户，才有资格参加该活动。
- 或者分时间段获得秒杀资格，比如9点、10、11点、参加活动获得秒杀资格，获得资格的朋友12点集中参与秒杀。
10、数据库层隔离
分库分表：先从代码、SQL语句、索引这几个方面着手优化，不行了在进行分库分表。
数据隔离：用专门的表来存放数据，不建议使用业务系统正在使用的表来存放秒杀相关的数据。
数据合并：如果秒杀系统是用的专用表存储，在秒杀活动结束后，需要将其和现有数据进行合并。
11、压力测试
正压力测试：在保证服务器资源不变的情况下，网络请求不断做加法。
负压力测试：在系统正常运行的情况下，逐渐减少支撑系统的服务器资源，观察什么时候系统无法在支撑正常的业务请求。
压力测试步骤：
1.确定测试目标
压力测试和性能测试不同，压力测试的目标是什么时候系统会接近崩溃，比如需要支持100万的访问量，测试出性能阈值。
2. 确定关键问题
二八原则大家一定要知道，压力测试也是有重点的，系统中只有20%的功能是最常用的，比如秒杀接口、下单、扣减库存。要集中火力测试常用的功能，高度还原真实场景。
3. 确定负载
和上面观点一样，不是每个服务都有高负载，测试时要重点关注高负载的服务，真实场景中服务的负载一定是波动的，并且不是均匀分布的。
4. 搭建环境
搭建环境要和生产环境保持一致。
5. 确定监测指标
提前确定好要重点监测的参数指标，比如：CPU负载、内存使用率、系统吞吐量、带宽阈值等
6. 产生负载
- 建议优先使用往期的秒杀数据，或者从生产环境中同步数据进行测试
- 根据目标系统的承受要求由脚本驱动测试
- 模拟不同网络环境，对硬件条件有规律的进行测试
7. 执行测试
根据目标系统、关键组件、用负载进行测试、返回监测点的数据。
8. 分析数据
针对测试的目的，对关键服务的压力测试数据进行分析，得出这些服务的承受上限在哪里？
对有波动的负载或者大负载的的服务进行数据分析，明确优化的方向。
