秒杀项目

1、秒杀流程

 1、首先前端商品界面显示秒杀倒计时，秒杀开始，显示秒杀按钮。输入验证码。

2、用户在商品详情面点击按钮后

• 验证码和用户id校验。
• 验证商品id和秒杀唯一标志是否合法（避免暴露秒杀地址）
• 判断秒杀时间（判断秒杀开始和结束时间）
• 判断商品是否抢光。redis中的库存>0 ? 
• 判断用户是否已经秒杀过该商品
  • （判断redis中的key是否存在，用户秒杀后会在redis中设置一个展位的key来标志用户已经秒杀过）

3、判断当前系统流量是否超过阈值。

• 通过redis的list数据结构实现
• 每有一个用户请求，就将用户请求放入list
• 当list长度超过库存的100倍之后
• 拒绝后续用户的访问，减轻系统的压力
• 用户秒杀流程结束后，不管成功还是失败，都需要限流的list弹出，以便于让后面的人可以再进来一个。

4、进行秒杀

• 减库存
  • 在redis中减库存，采用redis减库存decrBy方法（单线程，不会产生数据冲突）
  • 数据库没有直接减库存，因为数据库的瓶颈问题（数据库的行锁问题）。有rocketMq 发送事务性消息到mysql，异步下单，让数据库的库存和redis的库存同步
• 下订单
  • 异步下订单。避免直接操作数据库
  • 采用rocketmq下订单
  • 减库存成功后，给MQ发一个消息
  • 消息监听器收到消息后在数据库创建订单
  • 如果消息消费不过来，可以设置concurrency="8" 8个消费者，那么消费消息的速度就会加快，不会产生消息的堆积
• 告知前台秒杀结果

  • 创建订单成功或者失败后，都把秒杀结果放入到redis中；

  • 前台页面采用ajax轮询方式查询redis获取最终秒杀结果，给用户提示。

---

我的项目的流程

 2、库存预减用的是哪个redis方法

用redis 的 采用redis减库存decrBy方法，单线程不产生数据冲突

3.如果项目中的redis服务挂掉，如何减轻数据库的压力

使用多台redis, redis集群

1. slave从redis宕机
   配置主从复制的时候才配置从的redis，从的会从主的redis中读取主的redis的操作日志，求达到主从复制。
   1）在Redis中从库重新启动后会自动加入到主从架构中，自动完成同步数据；
   2）如果从数据库实现了持久化，可以直接连接到主的上面，只要实现增量备份（宕机到重新连接过程中，主的数据库发生数据操作，复制到从数据库），重新连接到主从架构中会实现增量同步。
2. Master 宕机
   假如主从都没数据持久化，此时千万不要立马重启服务，否则可能会造成数据丢失，正确的操作如下：
   1. 在slave数据上执行SLAVEOF ON ONE,来断开主从关系并把slave升级为主库
   2. 此时重新启动主数据库，执行SLAVEOF,把它设置为从库，连接到主的redis上面做主从复制，自动备份数据。
      以上过程很容易配置错误，可以使用redis提供的哨兵机制来简化上面的操作。简单的方法：redis的哨兵（sentinel）的功能。

4.如何避免消息队列的消费方重复消费消息

因为 Message ID 有可能出现冲突（重复）的情况，所以真正安全的幂等处理，不建议以 Message ID 作为处理依据。 最好的方式是以业务唯一标识作为幂等处理的关键依据，而业务的唯一标识可以通过消息 Key 进行设置。然后你这里消费到了之后，先根据这个 id 去比如 Redis 里查一下，之前消费过吗？如果没有消费过，你就处理，然后这个 id 写 Redis。如果消费过了，那你就别处理了，保证别重复处理相同的消息即可。

数据库的唯一键等等方式

5.消息的消费结果如何返回给消息发送方

1.每个消费者处理完成请求，再发送消息到消息队列中，你的生产者那方再实现消费者来消费这些处理结果信息；
然后处理你的逻辑！
2.将处理结果存于缓存等高性能组件中，通过轮询的方式获取任务处理结果

不管什么方式，你的请求方都应该是在你将请求消息发到队列后立即返回的！消息结果可以用推送的方式告知(移动端的话),也可以让请求方每个几秒轮询一次

 6.说一下你的秒杀系统设计，怎么解决超卖的

使用redis进行预减库存，当Redis中的库存不足时，直接返回秒杀失败

7.你说你用到了redis，redis有哪些数据结构，你为什么要用redis，哪里用到了，为什么说redis快，多路io复用详细原理可以说说嘛？

string hash set list zset

记录用户的登录状态；记录热点数据；预减库存；存放售罄标志位；

为什么使用redis？

• 速度快，基于内存的操作，类似于map，查找和操作的时间复杂度O(1)
• 数据结构简单，数据结构都是专门设计的
• 采用单线程，避免线程间的切换而消耗CPU，不用考虑各种所得问题，没有加锁和释放所得操作，没有看呢出现死锁情况。
• 多路复用I/O，非阻塞I/O
• redis有自己的VM机制，一般系统调用会消耗时间。

为什么不用多线程？

• 不涉及锁和加锁
• 没有线程之间的切换而消耗CPU

单线程的缺点？

• 耗时命令的并发降低
• 无法发挥多核CPU的性能，但是可以是多多个redis来解决。

那么redis没有线程安全问题吗？

  但是多个redis的复合操作，依然需要锁，而且可能是分布式锁。