时间：2023-03-03 11:18:03 | 栏目：Redis | 点击：次
经常会有到这样的需求，就是在一个查询接口，第一次查询的时候，如果没有查询到就要执行初始化方法，初始化数据出来，之后的查询就可以直接查询库里的数据了。这样设计的目的是，如果需要初始化的数据特别大，无法再一次调用方法里处理完，或者说数据并不是每条都需要初始化，这种情况下，优先查询的数据优先初始化。
这种方案随之而来就会引发一个问题。查询接口众所周知是个自然幂等的，不需要我们额外去做幂等处理。但是在方案中，这个查询就不单单是个查询了。没有查询到就要执行初始化方法，本质上是个插入逻辑。这就需要我们自己去做幂等了。
单台服务，我们可以用Java的锁来实现幂等，每条数据的主键id来当锁。但在现在基本上都是分布式服务，如同上篇文章说的，我们可以用分布式锁RedissonLock来实现。
并发第一次请求时，竞争RedissonLock，谁获得了锁，谁就执行初始化方法，没有竞争到锁的请求，可以设置一个等待时间，等待锁释放。锁释放了，就可以先查询数据有没有初始化好，完成了就直接查库。这里，就要提一下RedissonLock是如何实现等待的？
RedissonLock在加锁方法提供了一个api，提供了一个参数waitTime即等待时间。
public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit)
在waitTime时间内会订阅消息，这里用的是redis本身的发布订阅功能。
RFuture<RedissonLockEntry> subscribeFuture = subscribe(threadId);
if (!subscribeFuture.await(time, TimeUnit.MILLISECONDS)) {
if (!subscribeFuture.cancel(false)) {
subscribeFuture.onComplete((res, e) -> {
if (e == null) {
unsubscribe(subscribeFuture, threadId);
}
});
}
acquireFailed(threadId);
return false;
}
这样，在释放锁的时候，同时发布消息出来。所有监听该锁的线程都将收到通知，那么，这些线程将再次去竞争加锁，从而达到我们需要的幂等功能。我们在看看释放锁的逻辑，是不是发布消息了？
protected RFuture<Boolean> unlockInnerAsync(long threadId) {
return commandExecutor.evalWriteAsync(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.<Object>asList(getName(), getChannelName()), LockPubSub.UNLOCK_MESSAGE, internalLockLeaseTime, getLockName(threadId));
}
可以看出在unlockInnerAsync方法里，执行了lua脚本，在脚本里，我们很容易能看到执行了publish命令。
Redisson巧妙的用了redis的发布订阅功能，实现了分布式锁的等待功能。那么我们在实际业务应用中，redis的发布订阅功能还有哪些使用场景呢？欢迎留言讨论！