利用Redis一步步实现优惠券的最终秒杀方案

时间:2021-09-15 00:39:57

订单ID不能采用自增长的原因:

1、规律变化太明显。两天下单的ID的差值,能够计算出商城的订单量;

2、如果采用自增长,订单数据是会不断产生的,到时候要分表,但是每个表的ID都是从0开始增长的,这样ID就重复了。

全局ID生成器:

分布式系统环境下,用来生成全局唯一ID的工具。

1、唯一性;有个increment的特性;

2、高可用;能搭建集群

3、高性能;基于内存,效率高

4、递增型;【有利于数据库创建索引,提高数据库的查询速度】

5、安全性;

符号位:1bit,永远是0,代表正数;

时间戳:31bit,以秒为单位,可以使用69年;

序列号:32bit(Redis的递增值) 支持每秒产生2^32个ID【42亿】

Redis实现全局唯一生成器

package com.hmdp.utils;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Component;

import java.time.LocalDateTime;
import java.time.ZoneOffset;
import java.time.format.DateTimeFormatter;

@Component
public class RedisIdWorker {
    /**
     * 开始时间戳
     */
    private static final long BEGIN_TIMESTAMP = 1676037454L;
    /**
     * 序列号的位数【32个比特位】 2^32=40亿
     */
    private static final int COUNT_BITS = 32;

    @Autowired
    private StringRedisTemplate stringRedisTemplate;

    public long nextId(String keyPrefix) {
        // 1.生成时间戳【秒时间戳】
        LocalDateTime now = LocalDateTime.now();
        long nowSecond = now.toEpochSecond(ZoneOffset.UTC);
        long timestamp = nowSecond - BEGIN_TIMESTAMP;

        // 2.生成序列号
        // 2.1.获取当前日期,精确到天
        String date = now.format(DateTimeFormatter.ofPattern("yyyy:MM:dd"));
        // 2.2.自增长 【大概是每天40亿的上限】
        long count = stringRedisTemplate.opsForValue().increment("icr:" + keyPrefix + ":" + date);

        // 3.拼接并返回 【0 永远是第一位 31位的时间戳 32位的订单ID自增长】
        return timestamp << COUNT_BITS | count;
    }
}

有些优惠券需要买,比如说美团红包。8元人民币买10元的红包。

​ tb_voucher:优惠券的基本信息,优惠金额、使用规则等。

有些优惠券需要抢【秒杀】,比如说*为刺激消费,发放的汽车消费券,是有限的。

​ tb_seckill_voucher:优惠券的库存开始抢购时间,结束抢购时间。特价优惠券才需要填写这些信息。

抢购秒杀券时,需要判断

1、秒杀是否开始和结束

2、库存是否充足

【1、根据前端提交的优惠券id,获取优惠券信息】

【2、如果秒杀场景正确,可以考虑减库存。这里应该要使用到事务】

【3、创建订单信息给前端,让其支付】

基本下单和秒杀下单

**【超卖】**使用JMeter压测后,库存本来是100的,结果成了负数。新建的订单量竟然大于库存量,这就是在高并发环境的出现的情况。

需要加锁来解决。

1、悲观锁

认为线程安全问题一定会发生,因此在操作数据之前,先获取锁,确保线程串行执行。

例如:Synchronized、Lock都属于悲观锁。性能差了点,高并发环境下并不是很适合。

2、乐观锁【更新数据】

认为线程安全问题不一定会发生。只有在数据更新时,才会判断有没有其他线程对数据进行了修改。如果没有修改,则认为是安全的,自己才更新数据;如果数据已经被其他线程修改,则说明发生了安全性问题,此时可以重试或者是抛出异常。【对于要修改的数据,有一个版本号,如果查询出来的版本和where 筛选的版本号码一致,则可以进行修改,实际上是不加锁的。】

用数据本身有没有变化,来作为是否修改的条件。版本号,用数据本身来代替,简化了操作。CAS方案

弊端:虽然没有发生了超卖,但是优惠券抢购,只发生了21次,但是一共是100的库存量呀。

原因:多线程条件下,库存量快速变化,导致的其它线程,发生了扣减失败的情况,但是不出错。【成功率太低,没有业务上的安全问题】

where id = ? and stock = ? ==========》 where id = ? and stock > 0

防止请求对数据库的压力

一人一单,规避黄牛【新增数据】

做一个查询,如果表中存在,就不允许下单了。

出现的问题:并发环境下,库存竟然少了10,订单量一个人竟然有10单。虽然做了一人一单的判断,但是多线程环境下不管用。

还是那个并发安全问题,只能使用悲观锁方案。

从查询订单,到判断,到新增,做一个封装。

应该是先提交事务之后,再进行锁的释放。

如果先进行锁的释放,事务如果没有提交的话,下一个线程来查询时,还是出问题。

this.createVouther();this拿到的是service的对象,而spring的事务要想生效,是对当前service类对象做了代理,用代理对象做了事务处理。

所以使用类对象,可能会使得事务不生效。

1、添加依赖aspectjweaver

2、@EnableAspectJAutoProxy(exposeProxy = true);

通过加锁,可以解决在单体项目下的问题,那么如何解决多实例下的并发安全问题呢?

多体项目并发安全性问题

利用Redis一步步实现优惠券的最终秒杀方案
利用Redis一步步实现优惠券的最终秒杀方案
选择好左下角的服务,ctrl+D之后,修改端口-Dserver.port=8082

Redis的分布式锁实现多实例并发安全

分布式锁:满足分布式系统或集群模式下多线程可见,并且互斥的锁。

多进程可见:【独立于JVM】

互斥:【只有一个人能获取到】

高可用:【不能获取锁的动作经常出问题】

高性能:【加锁本身呢,会影响业务的性能,串行执行会变慢】

安全性:【锁获取了,异常挂了怎么办,产生死锁怎么处理呢】
利用Redis一步步实现优惠券的最终秒杀方案

Redis实现最简单的分布式锁

利用redis作为第三方中间件,给分布式项目的服务加锁。

public interface ILock {

    /**
     * 尝试获取锁
     * @param timeoutSec 锁持有的超时时间,过期后自动释放
     * @return true代表获取锁成功; false代表获取锁失败
     */
    boolean tryLock(long timeoutSec);

    /**
     * 释放锁
     */
    void unlock();
}
package com.pshdhx.utils;

import cn.hutool.core.lang.UUID;
import org.springframework.core.io.ClassPathResource;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.data.redis.core.script.DefaultRedisScript;

import java.util.Collections;
import java.util.concurrent.TimeUnit;

public class SimpleRedisLock implements ILock {

    private String name;
    private StringRedisTemplate stringRedisTemplate;
    private static final String KEY_PREFIX = "lock:";
    private static final String ID_PREFIX = UUID.randomUUID().toString(true) + "-";
    public SimpleRedisLock(String name, StringRedisTemplate stringRedisTemplate) {
        this.name = name;
        this.stringRedisTemplate = stringRedisTemplate;
    }

    @Override
    public boolean tryLock(long timeoutSec) {
        // 获取线程标示
        String threadId = ID_PREFIX + Thread.currentThread().getId();
        // 获取锁
        Boolean success = stringRedisTemplate.opsForValue()
                .setIfAbsent(KEY_PREFIX + name, threadId, timeoutSec, TimeUnit.SECONDS);
        return Boolean.TRUE.equals(success);
    }

    //删除自己线程的锁,不能因为本线程阻塞处理完成后(自己的锁过期了),删除别的线程的锁。
    @Override
    public void unlock() {
        // 获取线程标示
        String threadId = ID_PREFIX + Thread.currentThread().getId();
        // 获取锁中的标示
        String id = stringRedisTemplate.opsForValue().get(KEY_PREFIX + name);
        // 判断标示是否一致
        if(threadId.equals(id)) {
            // 释放锁
            stringRedisTemplate.delete(KEY_PREFIX + name);
        }
    }
}

直接使用线程的ID作为锁的值,是不合适的,线程ID值是递增的,因为多个JVM的线程号可能会相同。

Redis的分布式锁的原子性问题

如果在释放锁的过程中,发生了FullGC,然后释放锁的过程被阻塞,该锁超时自动释放了。则其余线程能够正常获取锁,此时阻塞的线程恢复了,把其余线程获取的锁给释放了,所以要保证释放锁的原子性。

Redis的事务可以保证其原子性,但是无法保证其一致性。而且事务里边的多个操作,是个批处理,是最终一次性执行。

所以使用Lua脚本来执行。

Redis提供了Lua脚本功能,在一个脚本中编写多条Redis命令,确保多条命令执行时的原子性。Lua是一种编程语言,它的基本语法可以参考

www.runoob.com/lua/lua-tutorial.html

在Shell中执行:

EVAL “return redis.call(‘set’,‘name’,‘jack’)” 0个参数

EVAL “return redis.call(‘set’,KEYS[1],ARGV[1])” 1 name Rose

unlock.lua 放入到resources里边

-- 比较线程标示与锁中的标示是否一致
if(redis.call('get', KEYS[1]) ==  ARGV[1]) then
    -- 释放锁 del key
    return redis.call('del', KEYS[1])
end
return 0

改进Redis的分布式锁

需求:基于Lua脚本实现分布式锁的释放锁逻辑

提示:RedisTemplate调用Lua脚本的api如下:

public <T> T execute(RedisScript<T> script, List<K> keys, Object... args) {
    return this.scriptExecutor.execute(script, keys, args);
}
package com.pshdhx.utils;

import cn.hutool.core.lang.UUID;
import org.springframework.core.io.ClassPathResource;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.data.redis.core.script.DefaultRedisScript;

import java.util.Collections;
import java.util.concurrent.TimeUnit;

public class SimpleRedisLock implements ILock {

    private String name;
    private StringRedisTemplate stringRedisTemplate;

    public SimpleRedisLock(String name, StringRedisTemplate stringRedisTemplate) {
        this.name = name;
        this.stringRedisTemplate = stringRedisTemplate;
    }

    private static final String KEY_PREFIX = "lock:";
    private static final String ID_PREFIX = UUID.randomUUID().toString(true) + "-";
    private static final DefaultRedisScript<Long> UNLOCK_SCRIPT;
    static {
        UNLOCK_SCRIPT = new DefaultRedisScript<>();
        UNLOCK_SCRIPT.setLocation(new ClassPathResource("unlock.lua"));
        UNLOCK_SCRIPT.setResultType(Long.class);
    }

    @Override
    public boolean tryLock(long timeoutSec) {
        // 获取线程标示
        String threadId = ID_PREFIX + Thread.currentThread().getId();
        // 获取锁
        Boolean success = stringRedisTemplate.opsForValue()
                .setIfAbsent(KEY_PREFIX + name, threadId, timeoutSec, TimeUnit.SECONDS);
        return Boolean.TRUE.equals(success);
    }

    @Override
    public void unlock() {
        // 调用lua脚本
        stringRedisTemplate.execute(
                UNLOCK_SCRIPT,
                Collections.singletonList(KEY_PREFIX + name),
                ID_PREFIX + Thread.currentThread().getId());
    }
    /*@Override
    public void unlock() {
        // 获取线程标示
        String threadId = ID_PREFIX + Thread.currentThread().getId();
        // 获取锁中的标示
        String id = stringRedisTemplate.opsForValue().get(KEY_PREFIX + name);
        // 判断标示是否一致
        if(threadId.equals(id)) {
            // 释放锁
            stringRedisTemplate.delete(KEY_PREFIX + name);
        }
    }*/
}

核心代码

private static final DefaultRedisScript<Long> UNLOCK_SCRIPT;
static {
    UNLOCK_SCRIPT = new DefaultRedisScript<>();
    UNLOCK_SCRIPT.setLocation(new ClassPathResource("unlock.lua"));
    UNLOCK_SCRIPT.setResultType(Long.class);
}
 @Override
    public void unlock() {
        // 调用lua脚本
        stringRedisTemplate.execute(
                UNLOCK_SCRIPT,
                Collections.singletonList(KEY_PREFIX + name),
                ID_PREFIX + Thread.currentThread().getId());
    }

不可重入锁

方法A获取了锁,然后去调用方法B,此时,方法B也想要获取锁,但是无法获取了。

不可重入:同一个线程无法多次获取同一把锁。

不可重试:尝试锁只尝试获取一次就返回false,没有重试机制。

超时释放:锁超时释放虽然可以避免死锁,但是如果业务执行耗时长,也会导致锁的释放,存在一定的安全隐患。

主从一致性【读写分离】:如果Redis提供了主从集群,主从同步存在延迟。在主节点set操作获取了锁,尚未同步到从节点,突然主节点宕机,选择新的从节点作为主,但是从节点没有锁,所以新的线程会重新set锁。

Redisson

提供了一系列分布式的常用对象,还提供了许多分布式服务,其中就包括了各种分布式锁的实现。

1、可重入锁

2、公平锁

3、联锁

4、红锁

5、读写锁

6、信号量

7、可过期性信号量

8、闭锁

可重入锁原理:

使用了哈希值的方式,进行可重入锁的是设计。但凡是在一个线程之中,无论是里边有多少个业务方法要获取锁,只管将对应的value值加一即可;如果需要释放锁,则将value值减一即可。如果减到了0,则进行锁的删除操作。
利用Redis一步步实现优惠券的最终秒杀方案
value值不断的增加,只要是同一个线程想要获取锁,value值就+1,【记得重置下有效期】

释放锁操作,就减1,如果减为0,则可以删除这把锁了。

local key = KEYS[1]; --锁的key
local threadId = ARGV[1]; -- 线程唯一标识
local releaseTime = ARGV[2]; --锁的自动释放时间
--判断当前锁是否还是被自己持有
if(redis.call('HEXISTS',key,threadId) == 0) then
	return nil; --如果不是自己,则直接返回
end;
-- 是自己的锁,则重入次数-1
local count = redis.call('HINCRBY',key,threadId,-1);
if(count > 0) then 
    	redis.call('Expire',key,releaseTime);
    	return nil;
else
    	redis.call('del',key);
    	return nil;
end;

1、重试机制

2、超时释放,此时业务未完成;

3、主从一致性问题;
利用Redis一步步实现优惠券的最终秒杀方案
waitTime:获取锁的最大等待时长。第一次获取锁失败后,不会立即返回,而是在最大等待时间内不断的尝试获取锁。如果在最大等待时间内,还没有获取锁,则返回false。

leaseTime:存活时间

TimeUnit:时间单位

分布式锁默认的超时释放时间-看门狗

private <T> RFuture<Long> tryAcquireAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId) {
    if (leaseTime != -1L) {
        return this.tryLockInnerAsync(waitTime, leaseTime, unit, threadId, RedisCommands.EVAL_LONG);
    } else {
        RFuture<Long> ttlRemainingFuture = this.tryLockInnerAsync(waitTime, this.commandExecutor.getConnectionManager().getCfg().getLockWatchdogTimeout(), TimeUnit.MILLISECONDS, threadId, RedisCommands.EVAL_LONG);
        ttlRemainingFuture.onComplete((ttlRemaining, e) -> {
            if (e == null) {
                if (ttlRemaining == null) {
                    this.scheduleExpirationRenewal(threadId);
                }

            }
        });
        return ttlRemainingFuture;
    }
}

this.commandExecutor.getConnectionManager().getCfg().getLockWatchdogTimeout(),

有个看门狗的超时时间,30 000L ====30秒

RFuture<RedissonLockEntry> subscribeFuture = this.subscribe(threadId);

他这个获取锁失败以后,会尝试再次获取。但是,也不是马上尝试获取的,因为别的业务应该还在执行,这样只能加大cpu的负担。此时会进行订阅操作,订阅的是释放锁的信号。

protected RFuture<Boolean> unlockInnerAsync(long threadId) {
    return this.evalWriteAsync(this.getName(), LongCodec.INSTANCE, RedisCommands.EVAL_BOOLEAN, "if (redis.call('hexists', KEYS[1], ARGV[3]) == 0) then return nil;end; local counter = redis.call('hincrby', KEYS[1], ARGV[3], -1); if (counter > 0) then redis.call('pexpire', KEYS[1], ARGV[2]); return 0; else redis.call('del', KEYS[1]); redis.call('publish', KEYS[2], ARGV[1]); return 1; end; return nil;", Arrays.asList(this.getName(), this.getChannelName()), LockPubSub.UNLOCK_MESSAGE, this.internalLockLeaseTime, this.getLockName(threadId));
}

这是释放锁的代码,此时释放锁,会进行一个发布的命令。

尝试获取锁的线程,此时进行了订阅。

if (!subscribeFuture.await(time, TimeUnit.MILLISECONDS)) {
    if (!subscribeFuture.cancel(false)) {
        subscribeFuture.onComplete((res, e) -> {
            if (e == null) {
                this.unsubscribe(subscribeFuture, threadId);
            }

        });
    }

    this.acquireFailed(waitTime, unit, threadId);
    return false;
} 

在等待订阅的过程中,它也不是无限制等待的,最大等待时间就是这个time【最大剩余等待时间】,如果此时间内还未返回释放锁的通知,超时了,就取消订阅,则返回false。

if (ttl >= 0L && ttl < time) {
    ((RedissonLockEntry)subscribeFuture.getNow()).getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
} else {
    ((RedissonLockEntry)subscribeFuture.getNow()).getLatch().tryAcquire(time, TimeUnit.MILLISECONDS);
}

通过信号量机制,不断尝试获取锁。

保证锁是业务执行完成了释放,而不是锁超时了释放

ttlRemainingFuture.onComplete((ttlRemaining, e) -> {
    if (e == null) {
        if (ttlRemaining == null) {
            this.scheduleExpirationRenewal(threadId);
        }

    }
});

会进行过期时间续约;

redis分布式锁的原理

利用Redis一步步实现优惠券的最终秒杀方案利用Redis一步步实现优惠券的最终秒杀方案
可重入:利用Hash结构,记录线程ID和重入的次数。

可重试:利用信号量和PubSub功能,实现等待、唤醒、获取锁失败的重试机制。

超时续约:利用WatchDog,每隔一段时间(ReleaseTime/3),重置超时时间。

redisson解决主从一致性

redis的各个节点,连锁。但凡有一个获取到锁,则整体失败。

@Configuration
public class RedissonConfig {

    @Bean
    public RedissonClient redissonClient(){
        // 配置
        Config config = new Config();
        config.useSingleServer().setAddress("redis://192.168.150.101:6379").setPassword("123321");
        // 创建RedissonClient对象
        return Redisson.create(config);
    }
    @Bean
    public RedissonClient redissonClient2(){
        // 配置
        Config config = new Config();
        config.useSingleServer().setAddress("redis://192.168.150.101:6380").setPassword("123321");
        // 创建RedissonClient对象
        return Redisson.create(config);
    }
    @Bean
    public RedissonClient redissonClient3(){
        // 配置
        Config config = new Config();
        config.useSingleServer().setAddress("redis://192.168.150.101:6381").setPassword("123321");
        // 创建RedissonClient对象
        return Redisson.create(config);
    }
}
class RedissonTest {

    @Resource
    private RedissonClient redissonClient;
    @Resource
    private RedissonClient redissonClient2;
    @Resource
    private RedissonClient redissonClient3;

    private RLock lock;

    @BeforeEach
    void setUp() {
        RLock lock1 = redissonClient.getLock("order");
        RLock lock2 = redissonClient2.getLock("order");
        RLock lock3 = redissonClient3.getLock("order");
        lock = redissonClient.getMultiLock(lock1,lock2,lock3);
    }

    @Test
    void method1() throws InterruptedException {
        // 尝试获取锁
        boolean isLock = lock.tryLock(1L, TimeUnit.SECONDS);
    }
}    

异步秒杀思路:

1、查询优惠券库存是否充足

2、查询优惠券是否过期

3、每个人只能抢一张优惠券【分布式锁】

4、抢完优惠券之后,扣减库存,关联用户,创建优惠券的订单【事务】

我们是否可以用主线程进行判断,如果用户有资格抢优惠券,那么我们就新开一个线程,进行扣库存和创建订单的操作。

此时,我们好像可以使用消息队列了。
利用Redis一步步实现优惠券的最终秒杀方案

Redis异步秒杀的判断逻辑:

1、判断库存是否冲突。【模拟扣减库存】

2、判断用户是否下过该订单【将userID存入到set集合中】
利用Redis一步步实现优惠券的最终秒杀方案

阻塞队列:

如果从队列中获取不到值,就一直阻塞。直到队列中获取值。

private BlockingQueue orderTasks = new ArrayBlockingQueue<>(1024*1024);

private static final ExecutorService SECKILL_ORDRE_EXECUTOR = Executors.newSingleThreadExecutor();
private class VoucherOrderHandler implements Runnable{
	@Override
	public void run(){
		
	}
}
@PostConstruct
private void init(){
    SECKILL_ORDER_EXECUTOR.submit(new VoucherOrderHandler());
}

@PostConstruct 是当前类加载完毕后,就执行这个方法的。

总结:

秒杀业务的优化思路是什么?

1、先利用Redis完成库存余量、一人一单判断,完成抢单业务。【Redis快】

2、再将下单业务放入阻塞队列,利用独立线程异步下单。【异步快】

基于阻塞队列的异步秒杀存在什么问题?

1、内存限制问题【订单的阻塞队列是有长度限制的,满了如何处理?】

2、数据安全问题【订单的阻塞队列是存在内存里边的,如果丢失了怎么处理?新开的线程处理订单失败了怎么处理?相当于任务丢失了!!!!】

认识消息队列

1、在高并发的情况下,JVM的内存不可能任意使用。

2、服务重启或者宕机,内存的数据无法持久化,会丢失数据。

生产者->Message Queue ->消费者

基于List结构的消息队列:

list是一个双向链表结构,用来模拟队列的效果。

LPush LPop RPush RPop命令来存取消息。

不过要注意的是,当队列中没有消息时,RPOP和LPOP操作会返回nil,并不像JVM的阻塞队列那种会阻塞并等待消息。

因此这里应该使用BRPOP或者是BLPOP来实现阻塞的效果。

消费者:

BRPOP l1 20

生产者:

LPush l1 e1 e2 //往l1中添加两个元素。

此时,BRPop 回返回l1和 e1;再次调用会返回l2和e2,再次调用就会阻塞。

优点:

1、利用redis存储,不受限于JVM内存的上限。

2、基于Redis的持久化机制,数据安全性有保障

3、满足了消息的有序性。

缺点:

1、无法避免消息丢失,一旦消息被pop,消费者处理消息时,挂掉了,消息丢失。

2、只支持单消费者。有时候,我们一条消息会被多个消费者消费,此种场景不能够被满足。

基于Pub/Sub的消息队列

利用Redis一步步实现优惠券的最终秒杀方案

优点:

采用发布/订阅模型、支持多生产、多消费

缺点:

不支持数据持久化。

无法避免消息丢失。如果消费者发布消息,此时没有消费者监听,那么消息就没了呀。

消息堆积【消费者处理慢,容易堆积】有上限、超出时数据丢失。

基于Streams消息队列模型*

Streams是Redis5.0以后,引入的全新数据类型,可以实现一个功能非常完善的消息队列。

XADD 发送

key --队列名称

[nomkstream] --没有队列自动创建

[maxlen | minId [=|~ threshold [limit count]] --消息队列最大长度

  • |ID --消息的唯一ID,时间戳+数字,由Redis自动生成。
  • field value [field value…] --消息内容为键值对

举例:

1、XADD users * name jack age 21

2、xadd s1 * k1 v1

返回的都是消息的ID

xlen s1 返回消息队列的数量。

XREAD 读取消息

xread

[Count count] --每次读取消息的最大数量

[Block milliseconds] --当没有消息时,是否阻塞,阻塞时长

streams key [key …] – 从那个队列开始读取,key是队列名

ID [id…] – 启示ID,只返回大于该ID的消息。0代表从第一个消息开始,$代表最先的消息开始。

实例:

客户端1:xread count 1 streams s1 0 返回了xadd s1 * k1 v1添加的值。

客户端2:xread count 1 streams s1 0 返回了xadd s1 * k1 v1添加的值。

所以,Streams方式,是可以重复消费消息的,永久存在的。

读取最新消息:

xread count 1 streams s1 $ 返回了nil,因为没有最新的消息,已有的消息已经被消费过了。

等待最新的消息:

xread count 1 block 0 streams s1 $ --0是代表永久阻塞,并进行等待消息。

此时,Xadd s1 * k2 v2 执行完成后,阻塞读取成功。

阻塞的伪代码

while(true){
	//尝试读取队列中的消息,最多阻塞两秒
	Object msg = redis.execute("XRead count 1 block 2000 streams users $");
	if(msg == null){
		continue;
	}
	//处理消息
	handleMessage(msg);
}

Xread $符号的bug

当我们指定起始ID为$符号时,代表读取最新的消息,如果我们处理消息的过程中,又有超过1条以上的消息到达消息队列,则下次读取时,也只能获取最新的一条消息,会出现漏读消息的问题。

总结

1、消息可以回溯:消息读取完成后,不会消失,永久存在。

2、一个消息可以被多个消费者读取:因为消息不丢失。

3、可以阻塞读取;

4、有消息漏读的风险。

stream的消费者组模式

消费者组:将多个消费者划分到一个组中,监听同一个队列,其具有以下特点。

1、消息分流:

​ 队列中的消息,会分流给组内的不通消费者,而不是重复消费,从而处理消息的处理速度。如果多个消费者都要获取到消息,可以设立多个消费者组。

2、消息标识:

​ 消费者组会维护一个标识,记录最后一个被处理的消息,哪怕消费者宕机重启,还会从标识之后继续读取消息,确保每一个消息都被消费。【避免xread $的漏读问题。】

3、消息确认:

​ 消费者获取消息后,消息处于一个pending的状态,并存入一个pending-list。当处理完成后,需要通过xack来确认消息,标记消息处理完成,才会从pending-list中移除。

创建消费者组

xgroup create key groupName ID [mkstream]

key:队列名称

mkstream:队列不存在时,自动创建。

实例:

xgroup create s1 g1 0 返回ok

删除指定的消费者组

xgroup destory key groupName

给指定的消费者组添加消费者

xgroup createconsumer key groupname consumername

删除消费者组中的指定消费者

xgroup delconsumer key groupname consumername

从消费者组读取消息

xreadgroup Group groupName consumerName [Count count] [Block mill] [noAck] streams key[key …] ID [ID…]

ID:“>” 从下一个未消费的消息开始。

​ 其他:根据指定ID从pending-list中获取已消费,但是未确认的消息。例如0,是从pending-list中第一个消息开始。

XACK

xack s1 g1 id1 id2

查询pending-list

xpending key group

实例:

xpending s1 g1 - + 10 取出所有范围内的10条。

xreadgroup Group g1 c1 count 1 block 2000 streams s1 0

取出pending-list中的一条。返回ID值。

确认pending-list

xack s1 g1 ID1

此时,再次执行,xreadgroup Group g1 c1 count 1 block 2000 streams s1 0 ,返回empty array.

消费者组伪代码

while(true){
	Object msg = redis.call("xreadgroup group g1 c1 count 1 block 2000 streams s1 >");
	if(msg == null){
		continue;
	}
	try{
		handleMessage(msg);
	}catch(Exception e){
		while(true){
			Object msg = redis.call("xreadgroup group g1 c1 count 1 streams s1 0");
			if(msg == null){ //说明没有异常消息,都被确认过了,所以pending-list中为空
				break;
			}
			try{
				//说明有异常,再次被处理
				handleMessage(msg);
			}catch(Exception e){
				//再次出现异常,记录日志,继续循环
				continue ;
			}
		}
	}
}

消费者组总结:

1、消息可以回溯

2、可以多消费者争抢消息,可以加快消费速度

3、可以阻塞读取

4、没有漏读的风险

5、有消息确认机制,保证消息至少被消费一次

redis三种队列的区别

利用Redis一步步实现优惠券的最终秒杀方案

异步秒杀最终版本:

需求:

1、创建一个stream类型的消息对垒,名称为stream.orders

2、修改之前的lua脚本,在确认有抢购资格后,直接想stream.orders中添加消息,内容包含voucherId,userId,orderId。

3、项目启动时,开启一个线程任务,尝试获取stream.orders中的消息,完成下单。

(1)xgroup create stream.orders g1 0 mkstream

队列和消费者组都创建好了。

(2)

-- 1.参数列表
-- 1.1.优惠券id
local voucherId = ARGV[1]
-- 1.2.用户id
local userId = ARGV[2]
-- 1.3.订单id
local orderId = ARGV[3]

-- 2.数据key
-- 2.1.库存key
local stockKey = 'seckill:stock:' .. voucherId
-- 2.2.订单key
local orderKey = 'seckill:order:' .. voucherId

-- 3.脚本业务
-- 3.1.判断库存是否充足 get stockKey
if(tonumber(redis.call('get', stockKey)) <= 0) then
    -- 3.2.库存不足,返回1
    return 1
end
-- 3.2.判断用户是否下单 SISMEMBER orderKey userId
if(redis.call('sismember', orderKey, userId) == 1) then
    -- 3.3.存在,说明是重复下单,返回2
    return 2
end
-- 3.4.扣库存 incrby stockKey -1
redis.call('incrby', stockKey, -1)
-- 3.5.下单(保存用户)sadd orderKey userId
redis.call('sadd', orderKey, userId)
-- 3.6.发送消息到队列中, XADD stream.orders * k1 v1 k2 v2 ...
redis.call('xadd', 'stream.orders', '*', 'userId', userId, 'voucherId', voucherId, 'id', orderId)
return 0

(3)

@Override
public Result seckillVoucher(Long voucherId) {
    Long userId = UserHolder.getUser().getId();
    long orderId = redisIdWorker.nextId("order");
    // 1.执行lua脚本
    Long result = stringRedisTemplate.execute(
            SECKILL_SCRIPT,
            Collections.emptyList(),
            voucherId.toString(), userId.toString(), String.valueOf(orderId)
    );
    int r = result.intValue();
    // 2.判断结果是否为0
    if (r != 0) {
        // 2.1.不为0 ,代表没有购买资格
        return Result.fail(r == 1 ? "库存不足" : "不能重复下单");
    }
    // 3.返回订单id
    return Result.ok(orderId);
}
    private static final DefaultRedisScript<Long> SECKILL_SCRIPT;

    static {
        SECKILL_SCRIPT = new DefaultRedisScript<>();
        SECKILL_SCRIPT.setLocation(new ClassPathResource("seckill.lua"));
        SECKILL_SCRIPT.setResultType(Long.class);
    }


    private static final ExecutorService SECKILL_ORDER_EXECUTOR = Executors.newSingleThreadExecutor();

    @PostConstruct
    private void init() {
        SECKILL_ORDER_EXECUTOR.submit(new VoucherOrderHandler());
    }

    private class VoucherOrderHandler implements Runnable {

        @Override
        public void run() {
            while (true) {
                try {
                    // 1.获取消息队列中的订单信息 XREADGROUP GROUP g1 c1 COUNT 1 BLOCK 2000 STREAMS s1 >
                    List<MapRecord<String, Object, Object>> list = stringRedisTemplate.opsForStream().read(
                            Consumer.from("g1", "c1"),
                            StreamReadOptions.empty().count(1).block(Duration.ofSeconds(2)),
                            StreamOffset.create("stream.orders", ReadOffset.lastConsumed())
                    );
                    // 2.判断订单信息是否为空
                    if (list == null || list.isEmpty()) {
                        // 如果为null,说明没有消息,继续下一次循环
                        continue;
                    }
                    // 解析数据
                    MapRecord<String, Object, Object> record = list.get(0);
                    Map<Object, Object> value = record.getValue();
                    VoucherOrder voucherOrder = BeanUtil.fillBeanWithMap(value, new VoucherOrder(), true);
                    // 3.创建订单
                    createVoucherOrder(voucherOrder);
                    // 4.确认消息 XACK
                    stringRedisTemplate.opsForStream().acknowledge("s1", "g1", record.getId());
                } catch (Exception e) {
                    log.error("处理订单异常", e);
                    handlePendingList();
                }
            }
        }

        private void handlePendingList() {
            while (true) {
                try {
                    // 1.获取pending-list中的订单信息 XREADGROUP GROUP g1 c1 COUNT 1 BLOCK 2000 STREAMS s1 0
                    List<MapRecord<String, Object, Object>> list = stringRedisTemplate.opsForStream().read(
                            Consumer.from("g1", "c1"),
                            StreamReadOptions.empty().count(1),
                            StreamOffset.create("stream.orders", ReadOffset.from("0"))
                    );
                    // 2.判断订单信息是否为空
                    if (list == null || list.isEmpty()) {
                        // 如果为null,说明没有异常消息,结束循环
                        break;
                    }
                    // 解析数据
                    MapRecord<String, Object, Object> record = list.get(0);
                    Map<Object, Object> value = record.getValue();
                    VoucherOrder voucherOrder = BeanUtil.fillBeanWithMap(value, new VoucherOrder(), true);
                    // 3.创建订单
                    createVoucherOrder(voucherOrder);
                    // 4.确认消息 XACK
                    stringRedisTemplate.opsForStream().acknowledge("s1", "g1", record.getId());
                } catch (Exception e) {
                    log.error("处理订单异常", e);
                }
            }
        }
    }