Redisson是架设在Redis基础上的一个Java驻内存数据网格（In-Memory Data Grid）。充分的利用了Redis键值数据库提供的一系列优势，基于Java实用工具包中常用接口，为使用者提供了一系列具有分布式特性的常用工具类。使得原本作为协调单机多线程并发程序的工具包获得了协调分布式多机多线程并发系统的能力，大大降低了设计和研发大规模分布式系统的难度。同时结合各富特色的分布式服务，更进一步简化了分布式环境中程序相互之间的协作。
分布式锁
分布式锁是我们工作中最常用的功能，让我们看看它是如何实现的。
RLock rlock = redisson.getLock(lockKey);
boolean isLocked = rlock.tryLock(0, 15, TimeUnit.SECONDS);
rlock.unlock();
首先，我们主要去关注加锁的过程，那么对于redisson创建，通信等一些涉及底层的代码就只能忽略了，将注意力放到核心的流程代码上。对于getLock(String name)方法，
public RLock getLock(String name) {
return new RedissonLock(this.connectionManager.getCommandExecutor(), name);
}
这里的 RLock 是继承自 java.util.concurrent.locks.Lock 的一个 interface，getLock 返回的实际上是其实现类 RedissonLock 的实例。
来看看构造 RedissonLock 的参数
- commandExecutor: 与 Redis 节点通信并发送指令的真正实现。需要说明一下，Redisson 缺省的 CommandExecutor 实现是通过 eval 命令来执行 Lua 脚本，所以要求 Redis 的版本必须为 2.6 或以上，否则你可能要自己来实现CommandExecutor。
- name: 锁的全局名称，例如上面代码中的 “foobar”，具体业务中通常可能使用共享资源的唯一标识作为该名称。
- id: Redisson 客户端唯一标识，实际上就是一个 UUID.randomUUID()。
返回的是一个RedissonLock
public RedissonLock(CommandAsyncExecutor commandExecutor, String name) {
super(commandExecutor, name);
this.commandExecutor = commandExecutor;
this.id = commandExecutor.getConnectionManager().getId();
this.internalLockLeaseTime = commandExecutor.getConnectionManager().getCfg().getLockWatchdogTimeout();
}
- 传入了一个异步处理的命令执行器，还有待上锁的name，构造函数中的this.id跟进去看，其实就是一个UUID对象，是当前要加锁客户端的唯一标识；
- 这里还有一个internalLockLeaseTime,从字面上来看，是一个内部的锁续约时间，默认是30000毫秒。
- this.entryName将UUID和传入的锁名称拼接起来，猜测一下，这个可能就是最终在Redis中要存储的加锁key。
下面进入加锁逻辑，核心代码很简单，就是tryLock,他的运行逻辑是怎么样的呢？
public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException {
long time = unit.toMillis(waitTime);
long current = System.currentTimeMillis();
final long threadId = Thread.currentThread().getId();
//申请锁返回剩余锁的过期时间
Long ttl = this.tryAcquire(leaseTime, unit, threadId);
//如果空表示申请锁成功
if (ttl == null) {
return true;
} else {
time -= System.currentTimeMillis() - current;
if (time <= 0L) {
this.acquireFailed(threadId);
return false;
} else {
current = System.currentTimeMillis();
//订阅监听redis消息，并且创建RedissonLockEntry，其中RedissonLockEntry中比较关键的是一个 Semaphore属性对象,用来控制本地的锁请求的信号量同步，返回的是netty框架的Future实现。
final RFuture<RedissonLockEntry> subscribeFuture = this.subscribe(threadId);
//阻塞等待subscribe的future的结果对象，如果subscribe方法调用超过了time，说明已经超过了客户端设置的最大wait time，则直接返回false，取消订阅，不再继续申请锁了。
if (!this.await(subscribeFuture, time, TimeUnit.MILLISECONDS)) {
if (!subscribeFuture.cancel(false)) {
subscribeFuture.addListener(new FutureListener<RedissonLockEntry>() {
public void operationComplete(Future<RedissonLockEntry> future) throws Exception {
if (subscribeFuture.isSuccess()) {
RedissonLock.this.unsubscribe(subscribeFuture, threadId);
}
}
});
}
this.acquireFailed(threadId);
return false;
} else {
boolean var16;
try {
time -= System.currentTimeMillis() - current;
if (time <= 0L) {
this.acquireFailed(threadId);
boolean var20 = false;
return var20;
}
do {
long currentTime = System.currentTimeMillis();
ttl = this.tryAcquire(leaseTime, unit, threadId);
if (ttl == null) {
var16 = true;
return var16;
}
time -= System.currentTimeMillis() - currentTime;
if (time <= 0L) {
this.acquireFailed(threadId);
var16 = false;
return var16;
}
currentTime = System.currentTimeMillis();
if (ttl.longValue() >= 0L && ttl.longValue() < time) {
this.getEntry(threadId).getLatch().tryAcquire(ttl.longValue(), TimeUnit.MILLISECONDS);
} else {
this.getEntry(threadId).getLatch().tryAcquire(time, TimeUnit.MILLISECONDS);
}
time -= System.currentTimeMillis() - currentTime;
} while(time > 0L);
this.acquireFailed(threadId);
var16 = false;
} finally {
this.unsubscribe(subscribeFuture, threadId);
}
return var16;
}
}
}
}
整个代码的逻辑是：首先，先获取了当前线程的线程id，紧接着便调用了tryAcquire方法，尝试获取锁，调用tryAcquire方法，获取成功返回null，否则返回剩余过期时间，如果获取成功返回true，否则就会进入一个死循环，去尝试加锁，并且也会在等待一段时间之后一直循环尝试加锁，阻塞住，知道第一个服务实例释放锁。对于不同的服务实例尝试会获取一把锁，也和上面的逻辑类似，都是这样实现了锁的互斥。
接下来让我看看tryAcquire方法，根据调用的名字可以猜测是一个异步执行的方法，但是能通过get()方法，将异步转成同步获取到执行结果。
private Long tryAcquire(long leaseTime, TimeUnit unit, long threadId) {
return (Long)this.get(this.tryAcquireAsync(leaseTime, unit, threadId));
}
tryAcquireAsync方法传入了leaseTime=-1，字面理解 续约时间，时间单位为秒，还有线程id，首先就进行了判断，判断这个leaseTime是否为-1，代码分为了俩个分支，为-1的代码貌似更多，那我们先来看为-1的情况，代码是如何走的。
private <T> RFuture<Long> tryAcquireAsync(long leaseTime, TimeUnit unit, final long threadId) {
if (leaseTime != -1L) {
return this.tryLockInnerAsync(leaseTime, unit, threadId, RedisCommands.EVAL_LONG);
} else {
RFuture<Long> ttlRemainingFuture = this.tryLockInnerAsync(this.commandExecutor.getConnectionManager().getCfg().getLockWatchdogTimeout(), TimeUnit.MILLISECONDS, threadId, RedisCommands.EVAL_LONG);
ttlRemainingFuture.addListener(new FutureListener<Long>() {
public void operationComplete(Future<Long> future) throws Exception {
if (future.isSuccess()) {
Long ttlRemaining = (Long)future.getNow();
if (ttlRemaining == null) {
RedissonLock.this.scheduleExpirationRenewal(threadId);
}
}
}
});
return ttlRemainingFuture;
}
}
可以看到他再次调用了一个异步方法tryLockInnerAsync(),其中传入的leaseTime变成从配置中获取的一个默认时间，通过调用了一个配置中的方法getLockWatchdogTimeout()，跟踪可以知道默认值正是30000毫秒，这个和之前的一个变量internalLockLeaseTime的默认值是一样的，还传入了线程id。这里我们可以留下一个疑问，从英文名来看，理解成看门狗超时时间，此刻我们可以去看看Redisson的官方文档，之前似乎在官方文档看到过对这个的介绍
If Redisson instance which acquired lock crashes then such lock could hang forever in acquired state. To avoid this Redisson maintains lock watchdog, it prolongs lock expiration while lock holder Redisson instance is alive. By default lock watchdog timeout is 30 seconds and can be changed through Config.lockWatchdogTimeout setting.
大概意思是说，redisson实现了一种看门狗的机制，当redisson实例获得锁之后一直保持活跃的时候，可以延长其加锁时间，当其崩溃的时候也能防止持有的锁一直保持，有自动释放机制。这个看门狗看起来是个挺核心的组件，我们可以先把加锁流程看下去，再看看这个看门狗到底是怎么运行的。
下面我们看到了一段核心之核心的代码：
<T> RFuture<T> tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
this.internalLockLeaseTime = unit.toMillis(leaseTime);
return this.commandExecutor.evalWriteAsync(this.getName(), LongCodec.INSTANCE, command, "if (redis.call('exists', KEYS[1]) == 0) then redis.call('hset', KEYS[1], ARGV[2], 1); redis.call('pexpire', KEYS[1], ARGV[1]); return nil; end; if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then redis.call('hincrby', KEYS[1], ARGV[2], 1); redis.call('pexpire', KEYS[1], ARGV[1]); return nil; end; return redis.call('pttl', KEYS[1]);", Collections.singletonList(this.getName()), new Object[]{this.internalLockLeaseTime, this.getLockName(threadId)});
}
这里他使用了lua脚本去实现了一段逻辑，也是异步操作，我们就Debug一下，一点点分析下他究竟干了什么？
-
首先呢，他先用exists命令判断了待获取锁的key anyLock 存不存在，如果不存在，就使用hset命令将锁key anyLock作为key的map结构中存入一对键值对，37f75873-494a-439c-a0ed-f102bc2f3204:1 1;
-
同时还使用了pexpire命令给anyLock设置了过期时间30000毫秒，然后返回为空；
-
如果anyLock已经存在了，会走另一个分支，此时会判断anyLock Map中是否存在37f75873-494a-439c-a0ed-f102bc2f3204:1，如果存在的话，就调用hincrby命令自增这个key的值，并且将anyLock的过期时间设置为30000毫秒，并且返回空。
-
如果上面俩种情况都不是，那么就返回这个anyLock的剩余存活时间。
分析完这个lua脚本之后，对具体redisson如何加锁的逻辑就有了一定的认知，lua脚本也可以保证执行命令的原子性。然后呢就直接返回了一个RFuture ttlRemainingFuture,并且给他加了一个监听器，如果当前的这个异步加锁的步骤完成的时候调用，如果执行成功，就直接同步获取一个Long类型的ttlRemaining。并注册一个监听。
ttlRemainingFuture.addListener(new FutureListener<Boolean>() {
public void operationComplete(Future<Boolean> future) throws Exception {
if (future.isSuccess()) {
Boolean ttlRemaining = (Boolean)future.getNow();
if (ttlRemaining.booleanValue()) {
RedissonLock.this.scheduleExpirationRenewal(threadId);
}
}
}
});
这个监听的目的是什么呢？我们先思考一个问题，假设在一个分布式环境下，多个服务实例请求获取锁，其中服务实例1成功获取到了锁，在执行业务逻辑的过程中，服务实例突然挂掉了或者hang住了，那么这个锁会不会释放，什么时候释放？回答这个问题，自然想起来之前我们分析的lua脚本，其中第一次加锁的时候使用pexpire给锁key设置了过期时间，默认30000毫秒，由此来看如果服务实例宕机了，锁最终也会释放，其他服务实例也是可以继续获取到锁执行业务。但是要是30000毫秒之后呢，要是服务实例1没有宕机但是业务执行还没有结束，所释放掉了就会导致线程问题，这个redisson是怎么解决的呢？这个就一定要实现自动延长锁有效期的机制。
如果加锁成功就会执行scheduleExpirationRenewal方法，我看下这个方法的作用：
private void scheduleExpirationRenewal(final long threadId) {
if (!expirationRenewalMap.containsKey(this.getEntryName())) {
Timeout task = this.commandExecutor.getConnectionManager().newTimeout(new TimerTask() {
public void run(Timeout timeout) throws Exception {
RFuture<Boolean> future = RedissonLock.this.commandExecutor.evalWriteAsync(RedissonLock.this.getName(), LongCodec.INSTANCE, RedisCommands.EVAL_BOOLEAN, "if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then redis.call('pexpire', KEYS[1], ARGV[1]); return 1; end; return 0;", Collections.singletonList(RedissonLock.this.getName()), new Object[]{RedissonLock.this.internalLockLeaseTime, RedissonLock.this.getLockName(threadId)});
future.addListener(new FutureListener<Boolean>() {
public void operationComplete(Future<Boolean> future) throws Exception {
RedissonLock.expirationRenewalMap.remove(RedissonLock.this.getEntryName());
if (!future.isSuccess()) {
RedissonLock.log.error("Can't update lock " + RedissonLock.this.getName() + " expiration", future.cause());
} else {
if (((Boolean)future.getNow()).booleanValue()) {
RedissonLock.this.scheduleExpirationRenewal(threadId);
}
}
}
});
}
}, this.internalLockLeaseTime / 3L, TimeUnit.MILLISECONDS);
if (expirationRenewalMap.putIfAbsent(this.getEntryName(), task) != null) {
task.cancel();
}
}
}
首先，会先判断在expirationRenewalMap中是否存在了entryName，这是个map结构，主要还是判断在这个服务实例中的加锁客户端的锁key是否存在，如果已经存在了，就直接返回；第一次加锁，肯定是不存在的，接下来就是搞了一个TimeTask，延迟internalLockLeaseTime/3之后执行，这里就用到了文章一开始就提到奇妙的变量，算下来就是大约10秒钟执行一次，调用了一个异步执行了一段lua脚本，首先判断这个锁key的map结构中是否存在对应的key8a9649f5-f5b5-48b4-beaa-d0c24855f9ab:anyLock:1,如果存在，就直接调用pexpire命令设置锁key的过期时间,默认30000毫秒。
OK，现在思路就清晰了，在上面任务调度的方法中，也是异步执行并且设置了一个监听器，在操作执行成功之后，会回调这个方法，如果调用失败会打一个错误日志并返回，更新锁过期时间失败；然后获取异步执行的结果，如果为true，就会调用本身，如此说来又会延迟10秒钟去执行这段逻辑，所以，这段逻辑在你成功获取到锁之后，会每隔十秒钟去执行一次，并且，在锁key还没有失效的情况下，会把锁的过期时间继续延长到30000毫秒，也就是说只要这台服务实例没有挂掉，并且没有主动释放锁，看门狗都会每隔十秒给你续约一下，保证锁一直在你手中。完美的操作。
到现在来说，加锁，锁自动延长过期时间，都OK了，然后就是说在你执行业务，持有锁的这段时间，别的服务实例来尝试加锁又会发生什么情况呢？或者当前客户端的别的线程来获取锁呢？很显然，肯定会阻塞住，我们来通过代码看看是怎么做到的。还是把眼光放到之前分析的那段加锁lua代码上，当加锁的锁key存在的时候并且锁key对应的map结构中当前客户端的唯一key也存在时，会去调用hincrby命令，将唯一key的值自增一，并且会pexpire设置key的过期时间为30000毫秒，然后返回nil,可以想象这里也是加锁成功的，也会继续去执行定时调度任务，完成锁key过期时间的续约，这里呢，就实现了锁的可重入性。
那么当以上这种情况也没有发生呢，这里就会直接返回当前锁的剩余有效期，相应的也不会去执行续约逻辑。返回最上层进行阻塞等待。
但当我们设置了过期时间也就是leaseTime!=-1，就不会用看门狗进行过期时间的续约。
紧接着，我们来看看锁释放的逻辑，其实也很简单，调用了lock.unlock()方法，跟着代码走流程发现，也是异步调用了一段lua脚本，现在再看lua脚本，应该就比较清晰，也就是通过判断锁key是否存在，如果不存在直接返回；否则就会判断当前客户端对应的唯一key的值是否存在，如果不存在就会返回nil;否则，值自增-1，判断唯一key的值是否大于零，如果大于零，则返回0；否则删除当前锁key，并返回1；返回到上一层方法，也是针对返回值进行了操作，如果返回值是1，则会去取消之前的定时续约任务，如果失败了，则会做一些类似设置状态的操作，这一些和解锁逻辑也没有什么关系，可以不去看他。
public void unlock() {
Boolean opStatus = (Boolean)this.get(this.unlockInnerAsync(Thread.currentThread().getId()));
if (opStatus == null) {
throw new IllegalMonitorStateException("attempt to unlock lock, not locked by current thread by node id: " + this.id + " thread-id: " + Thread.currentThread().getId());
} else {
if (opStatus.booleanValue()) {
this.cancelExpirationRenewal();
}
}
}
protected RFuture<Boolean> unlockInnerAsync(long threadId) {
return this.commandExecutor.evalWriteAsync(this.getName(), LongCodec.INSTANCE, RedisCommands.EVAL_BOOLEAN, "if (redis.call('exists', KEYS[1]) == 0) then redis.call('publish', KEYS[2], ARGV[1]); return 1; end;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()), new Object[]{LockPubSub.unlockMessage, this.internalLockLeaseTime, this.getLockName(threadId)});
}
通用对象桶（Object Bucket）
Redisson的分布式RBucketJava对象是一种通用对象桶可以用来存放任类型的对象。
RBucket<AnyObject> bucket = redisson.getBucket("anyObject");
bucket.set(new AnyObject(1));
AnyObject obj = bucket.get();
bucket.trySet(new AnyObject(3));
bucket.compareAndSet(new AnyObject(4), new AnyObject(5));
bucket.getAndSet(new AnyObject(6));
原子整长形（AtomicLong）
Redisson的分布式整长形RAtomicLong对象和Java中的java.util.concurrent.atomic.AtomicLong对象类似。
RAtomicLong atomicLong = redisson.getAtomicLong("myAtomicLong");
atomicLong.set(3);
atomicLong.incrementAndGet();
atomicLong.get();
限流器（RateLimiter）
基于Redis的分布式限流器可以用来在分布式环境下现在请求方的调用频率。既适用于不同Redisson实例下的多线程限流，也适用于相同Redisson实例下的多线程限流。该算法不保证公平性。
RRateLimiter rateLimiter = redisson.getRateLimiter("myRateLimiter");
// 初始化
// 最大流速 = 每1秒钟产生10个令牌
rateLimiter.trySetRate(RateType.OVERALL, 10, 1, RateIntervalUnit.SECONDS);
// 获取4个令牌
rateLimiter.tryAcquire(4);
// 尝试获取4个令牌，尝试等待时间为2秒钟
rateLimiter.tryAcquire(4, 2, TimeUnit.SECONDS);
rateLimiter.tryAcquireAsync(2, 2, TimeUnit.SECONDS);
// 尝试获取1个令牌，等待时间不限
rateLimiter.acquire();
// 尝试获取1个令牌，等待时间不限
RFuture<Void> future = rateLimiter.acquireAsync();