Redis项目实战——优惠券秒杀

Redis自增功能解决全局唯一ID

• 如果用MySQL的自增长ID，ID的规律性太明显，会暴漏一些信息（比如销量等）
• 数据量太大时一张表存不下，需要多张表，MySQL多张表的自增长都是独立的，会出现重复ID
• 需要一种在分布式系统下可以生成全局唯一ID的工具，必须唯一且递增
• 在某项目里，不管数据库的表有多少个，Redis只有一个，因此Redis递增功能生成的ID一定是全局唯一的
• 为了保证递增的同时且没有规律，保证安全性，可以在Redis自增数值的基础上拼接一些其它信息
  

Redis实现优惠券秒杀的主要思路

实现过程中出现的问题及解决方法

超卖问题

• 在高并发场景下，多个线程同时操作共享的资源（库存），导致实际卖出的数量超出了库存数量

方案1 悲观锁

• 态度比较悲观，认为线程安全问题肯定会发生，在操作数据之前提前获取锁
• 例子：Synchronized、Lock
• 优点：安全性高
• 缺点：性能低，实现简单

方案2 乐观锁

• 态度比较乐观，认为线程安全问题不一定会发生，因此不加锁，只在数据更新时去判断在它之前有没有其它线程修改数据。如果没有修改认为是安全的，直接更新数据，如果已经被修改说明不安全，重试或报异常
• 版本号法：给库存增加一个版本字段，线程1查询并记录下库存和版本号，然后将库存-1，版本号+1，来表示线程1修改了一次数据，然后在更新数据之前再判断一下版本号，是否是自己当时记录的版本号+1，若是，说明没有并发线程在期间修改过数据，安全，可以放心更新，若不是，说明正好有并发线程在期间修改过了数据，不安全，重试或者报异常
• CAS法：版本号法的简化版本，去掉版本号这个多余的字段，直接用库存本身代替版本号，根据库存本身有没有发生变化来确定是否更新
• 优点：性能高
• 缺点：实现复杂

一人一单问题

• 常见的业务问题，要求同一个优惠券，一个用户只能下一单
• 在库存充足判断成功后再增加一个判断，用用户ID和优惠券ID联合查询，来判断该用户是否已经买过一优惠券
• 在单机模式下，可以加Synchronized锁来保证线程安全
• 在集群模式下，Synchronized锁无效，需要用分布式锁来确保线程安全。Synchronized锁无效的原因是因为每台服务器有自己的常量池，锁监视器便保存在常量池中，用户尝试获取锁便是访问锁监视器，因此，主要问题是因为多个服务器的锁监视器是独立的，所以多个服务器上的用户能在同一时刻同时获取锁，进而导致线程安全问题

分布式锁

• 在单机情况下，只有一个JVM，JVM中只有一个锁监视器，只有一个程序可以获取到锁。但在集群情况下，有多个JVM，多个JVM中有多个锁监视器，程序可以获取到多个锁，甚至同一个程序也可以获得多个锁，就会出现线程安全问题
• 需要在多个JVM之外做一个共享的 多进程可见的 互斥的 锁监视器——分布式锁
• 实现分布式锁的三大方式：MySQL、Redis、Zookeeper，MySQL和Zookeeper比Redis安全性更好，Redis性能比二者更好
  

如何用Redis实现分布式锁？

• 获取互斥锁：SET lock thread1 NX EX 10，NX是互斥，确保只有一个线程可以获取到锁，EX是设置超时时间。
• 释放锁：直接手动删除。
• 死锁问题：若获取到锁后线程宕机，容易出现死锁，应该增加过期时间，超时自动释放锁。
• 误删问题：若线程１获取到锁，但业务执行时间过长，超过了TTL，会自动释放锁，此时线程２尝试获取锁成功，并正常执行业务，但期间线程１业务执行完毕，正常执行释放锁操作，此时就会把线程２的锁误删。为了避免这种情况，应该在获取锁时增加一个标识，来表示谁占有了这个锁，且只有它才有资格释放锁，因此在释放锁之前需要增加判断步骤
• 基于setnx实现的分布式锁存在的问题：不可重入（同一个线程无法多次获取同一把锁），不可重试（获取锁只尝试一次，失败不会重试），超时释放（业务执行耗时较长会导致锁释放，存在安全隐患）
• Redission组件：Redis基础上实现的分布式工具集合

Redis优化秒杀

• 优化主要思路：将涉及到数据库的减库存创建订单等耗时操作用异步独立线程慢慢做，Redis只需要判断用户有没有抢成功并返回结果
• 原来的秒杀流程：主要是Tomcat里面的一系列操作，有四个会直接操作数据库，耗时非常久。相当于一个饭店，来了一位顾客，派了一个服务员为这位顾客一条龙服务，从点菜（查询秒杀资格）到做饭（减库存和创建订单）都是这一个服务员做，效率非常低下。
• 优化后的秒杀流程：在NGINX和Tomcat之家增加Redis，用于判断该用户能不能抢上优惠券，并将判断结果和优惠券id、用户id、订单id一起保存到阻塞队列，然后Tomcat从队列中读取消息，进行比较耗时的减库存和创建订单操作
  
• 其中Redis判断秒杀库存的操作可以封装到Lua脚本中执行，以确保该操作的原子性
  
• 基于阻塞队列的异步秒杀存在的问题？
• 阻塞队列用的时JDK的，会占用JVM内存，大量消息会造成内存溢出

消息队列实现异步秒杀

• 消息队列：存储管理消息
• 生产者：发送消息到消息队列
• 消费者：从消息队列获取消息并处理消息
• Redis实现消息队列的三种方式：List、发布订阅模式、Stream

List

• 链式的双端队列，LPUSH存，RPOP取，但并没有阻塞效果（队列空时不会阻塞等待），BRPOP有阻塞效果。
• 优点：独立于JVM存在，不占JVM内存，不担心上限，且可以持久化，还能保证消息有序性
• 缺点：无法避免消息丢失，只支持一对一

发布订阅模式

• 消费者订阅一个或多个channel，生产者向对应channel发送消息
• 优点：支持一对多，一个生产者可以把消息发给多个消费者。天生支持阻塞
• 缺点：不支持数据持久化，无法避免消息丢失，消息堆积有上限

Stream

• 优点：消息可回溯，支持一对多，支持阻塞读取
• 缺点：可能会漏读消息
• 消费者组：将多个消费者划分到一个组中，监听同一个消息队列，那么多个消费者就会竞争这些消息，可以加快处理消息的速度，避免消息堆积。消费者组还会维护一个标识，记录最后一个被处理的消息，可以很快恢复突发情况，避免漏读消息。此外，消费者拿到消息后，Redis并不会直接不管这条消息，而是将消息置为pending状态，表示这条消息取上了但还没处理完，处理完后通过XACK确认消息，标记为已处理，此时Redis才会放心地把消息从队列中移除，可以防止消息丢失。
• 消费者组优点：消息可回溯，可以多消费者争抢消息，加快消费速度，可以阻塞读取，不会漏读消息，有消息确认机制，保证消息至少被消费一次

三种消息队列对比总结