基于redis的分布式锁：
大概原理：跟基于DB的类似，基于redis的分布式锁是争抢redis上的一个键，谁给这个键赋值了谁就抢到了锁，主要是用了redis的setnx机制，也就是set if not exists。实际一般不用setnx这个api，主要是粒度略粗，不能指定失效时间，用set(key,value,"nx","px",1000)，几个参数分别为键、值、设置方式、时间单位、时间。
---------Talk Is Cheap, Just Show Me The Code-------------------------------------------------
获取锁：
/**
* 阻塞锁
* @return
*/
public boolean lock(){
boolean flag = tryLock();
if(flag){
return true;
}else{
int time = (int) (Math.random() * 1000);
try {//随机睡眠一段时间，避免多个线程同时睡眠，同时醒来
Thread.sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
return lock();
}
}
/**
* 非阻塞锁
* @return
*/
public boolean tryLock(){
String str = UUID.randomUUID().toString();
Jedis jedis = new Jedis("localhost");
String result = jedis.set(lock,str,"NX","PX",1000);
if(result!=null && result.equals("OK")){
local.set(str);
return true;
}
return false;
}
释放锁：
/**
* 释放锁
* @return
*/
public void unlock(){
String script =
"if redis.call("get",KEYS[1]) == ARGV[1] then " +
" return redis.call("del",KEYS[1]) " +
"else " +
" return 0 " +
"end";
ArrayList<String> keysList = new ArrayList<>();
keysList.add(lock);
ArrayList<String> argsList = new ArrayList<>();
String args = local.get();
argsList.add(args);
Jedis jedis = new Jedis("localhost");
jedis.eval(script, keysList, argsList);
}
解锁过程就是删除redis中数据的过程，由于有失效时间的问题，如果已经失效了就不用再删了，没失效则删除。
注意，这里用了一段lua脚本，原因是要保证解锁操作为原子操作，如果用普通jedis的api，要经过get值，比较，del值三个阶段，该过程中可能键已失效，导致误删。redis支持lua脚本，此处我们将该过程写成脚本，发到redis端，因为redis为单进程单线程，执行过程中可以保证该过程的原子性。
测试代码：
@Test
public void testLock(){
for(int i=0;i<10;i++){
MyThread t = new MyThread("mythread"+i);
t.start();
cdl.countDown();
}
try {
Thread.sleep(10000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
//内部类
class MyThread extends Thread{
private String threadName;
public MyThread(){};
public MyThread(String threadName){
this.threadName = threadName;
}
@Override
public void run() {
try {
cdl.await();
} catch (InterruptedException e) {
e.printStackTrace();
}
if(redisLock.lock()){
System.out.println("线程-"+threadName+"获得锁，orderId为："+MyResources.getInstance().getNextId());
redisLock.unlock();
}
}
}
执行结果：
线程-mythread3获得锁，orderId为：1
线程-mythread6获得锁，orderId为：2
线程-mythread5获得锁，orderId为：3
线程-mythread1获得锁，orderId为：4
线程-mythread2获得锁，orderId为：5
线程-mythread0获得锁，orderId为：6
线程-mythread7获得锁，orderId为：7
线程-mythread8获得锁，orderId为：8
线程-mythread9获得锁，orderId为：9
线程-mythread4获得锁，orderId为：10
------------------------------------------------
结果就不解释了，redis的分布式锁相比数据库的，一大优势是性能高，但没有缺点么？显然也不是：
1、锁的失效时间难以把握，过短业务没处理完就失效了，造成多个业务竞争资源，可能会失去锁应有的作用，过长会导致其它锁盲目等待，导致锁的性能较低，经验来看，一般为单线程处理业务时长的2-3倍较合适；
2、可能出现锁失效的问题，比如某个线程执行时间特别长，超出了有效期，别的线程也会抢到锁，可能造成锁失效；
3、在redis集群中不太适合，因为是基于master节点的，master节点挂掉的时候如果数据没有同步到salve中，那么会造成锁失效；
整体来说，redis的分布式锁仍然有较多问题，下一篇我们整理基于zk的分布式锁，并对三种锁作比较。