Redis下分布式锁的实现

本文可作为redis in action第六章的学习笔记


其实,对redis而言,锁和事务与watch等等是分不开的。
我们先来聊聊事务和watch
事务,在关系型事务上的意思就是:一个事务内的sql,要不全部都执行成功,要么全部都不执行。
不过redis的事务只能部分满足"一荣俱荣,一损俱损"的特性。
怎么说?
在关系型数据库中,一个事务内部如果发生了错误,所有sql就都回滚到初始状态
在redis的事务中,所谓的错误,至少分两种:
1 语法错误
例如 我把set dlf abc 写成了sett dlf abc
2 运行错误
dlf这是个String类型的key,sadd这是对set类型数据做操作的
命令:sadd dlf kkk也就会出错,这就是运行错误
如果在一个事务中,一共三个命令,第二个命令有语法错误,那么三条命令就等于都没有执行。
如果在一个事务中,一共三个命令,第二个命令有运行错误,那么第一三条命令还是执行了的。
所以大家得尽力解决运行错误,你得记得每一个键都是什么类型的。
我记不住呀!
你说你记不住?那你还写什么代码?不会回家看孩子去。


watch命令
watch一般也是跟实物连用的。
线程A,watch某个数据后,如果在线程A执行exec之前,线程B修改了那个数据,那么线程A的事务就会失败。
与此同时,线程B修改的那个数据也已经进入redis了。
所以一般情况下,watch都会包含在一个while循环中。

while (System.currentTimeMillis() < end) {            conn.watch(inventory);            Transaction trans = conn.multi();    //...进行事务操作            List<Object> results = trans.exec();             // 如果返回的是null 就说明因为watch的域被改变了            // 事务也就被打断了            if (results == null){                continue;            }            return true;        }

那while有什么问题呢?
如果负载很大,事务就会不断的重试!
数据库的那种锁叫悲观锁,我用的时候你不能用。
redis的这个watch机制,叫做乐观锁,就是假定不会有人来打扰我,如果有人打扰(修改了我要操作的数据)我了,那就以别人的数据为准,我再做一遍。
那有什么办法呢?
锁!!


另一方面
我们抛开redis暂且不谈,在单机情况下,java的synchronized关键词能保证同步性。那么多机下呢?
就得用分布式锁了。


也就说,不管是从redis的watch的多次重试上来说,还是从多机互斥上来说,我们都得有一个能支持分布式的不会重试的锁!


OK,我们先说一个命令
SETNX命令（SET if Not eXists）
语法：
SETNX key value
功能：
当且仅当 key 不存在，将key的值设为 value ，并返回1；若给定的 key 已经存在，则 SETNX 不做任何动作，并返回0。


我们设计的redis锁,准确的说保存的就是一个字符串
key是锁的名字,value是一个uuid
OK,开始上代码

     /**     * 如果过了acquireTimeout时间后,我还没有获得锁,我就放弃了     * 同时直接返回null     * 用户获得锁以后,最多使用lockTimeout长时间 过了之后     * 别的客户端 也就能取到锁了     */    public String acquireLockWithTimeout(        Jedis conn, String lockName, long acquireTimeout, long lockTimeout)    {//        String identifier = UUID.randomUUID().toString();        String lockKey = "lock:" + lockName;        int lockExpire = (int)(lockTimeout / 1000);        long end = System.currentTimeMillis() + acquireTimeout;        while (System.currentTimeMillis() < end) {            //等于1 就说明之前并没有这个key            if (conn.setnx(lockKey, identifier) == 1){                conn.expire(lockKey, lockExpire);                return identifier;            }                //代码运行到这里 说明锁已经被别人拿走了            //等于-1 表示之前也没有设置超时时间            if (conn.ttl(lockKey) == -1) {                conn.expire(lockKey, lockExpire);            }            try {//等1毫秒再试                Thread.sleep(1);            }catch(InterruptedException ie){                Thread.currentThread().interrupt();            }        }        //别人拿到锁了 我等的时间太久了 老子不等了        return null;    }

如果返回的值不为null,那么就说明获得锁了,而且获得的那个identifier,在释放锁的时候也有用。
下面就是释放锁了:
 

 /**     * 释放成功 返回true 反之返回false     * @param conn     * @param lockName     * @param identifier     * @return     */    public boolean releaseLock(Jedis conn, String lockName,     String identifier) {        String lockKey = "lock:" + lockName;        while (true){            conn.watch(lockKey);            //如果不相等 会怎么样 为什么有这一步的检查            if (identifier.equals(conn.get(lockKey))){                Transaction trans = conn.multi();                trans.del(lockKey);                List<Object> results = trans.exec();                if (results == null){                    continue;                }                return true;            }            //unwatch 没有进入事务 就得手动unwatch            conn.unwatch();            break;        }        return false;    }

我自己再看到这个代码的时候,很疑惑identifier.equals(conn.get(lockKey)这个是干什么?

就算别人把我的锁的identifier从2dsafd改成了2fsae,能咋么?我直接删除了就是了么。反正只要我不还锁,别人都无法获得锁,能有啥问题么。

假如线程A再2:15获得了锁,并且锁的lockTimeout是3分钟 返回的uuid(就是那个identifier)假如是abc
2:16的时候,线程b想要获得锁,那肯定是获得不了的,线程b阻塞到那了。
到2:18的时候,线程A还没有主动释放锁,但是锁的过期时间已经到了,redis已经删除了那个锁
到2:19的时候线程b就已经获得锁了,返回的uuid假如是edf,并且过期时间也是3分钟,在2:22之前,理论上,只有线程b持有锁。
然后到2:20的时候,线程A来释放锁。如果不检查两个identifier是否相等,线程a就把线程b的锁给删除了
然后2:21线程c就获得了自己本不应该获得的锁(此时线程锁还应该在线程b手上)
亲爱的朋友们,你们明白了么。
那具体怎么使用这个锁呢?

String locked = acquireLockWithTimeout(conn, lockName,1000);//你的代码                releaseLock(conn, identifier, locked);

参考资料
http://qifuguang.me/2015/09/30/Redis%E4%BA%8B%E5%8A%A1%E4%BB%8B%E7%BB%8D/
https://my.oschina.net/OutOfMemory/blog/300173
http://blog.csdn.net/ugg/article/details/41894947