Redis的事务与锁

一.Redis事务

Redis的事务和传统关系数据库的事务并不相同。在关系数据库中，用户首先向数据库服务器发送BEGIN，然后执行各个相互一致的写操作和读操作，最后，用户可以选择发送COMMIT来确认之前所做的修改，或者发送ROLLBACK来放弃那些修改。

在Redis里面也有简单的方法可以处理一连串相互一致的读操作和写操作。Redis的事务以特殊命令MULTI为开始，之后跟着用户传入的多个命令，最后以EXEC为结束。在Redis里面，被MULTI命令和EXEC命令包含的所有命令会一个接一个地执行，知道所有命令都执行完毕为止。当一个事务执行完毕之后Redis才会处理其他客户端的命令。当Redis从一个客户端那里接收到MULTI命令时，Redis会将这个客户端之后发送的所有命令都放入到一个队列里面，直到这个客户端发送EXEC命令为止，然后Redis就会在不被打断的情况下，一个接一个地执行存储在队列里面的命令。需要注意的是，在没有执行EXEC命令之前，Redis只是把传过来的命令放到队列里，并没有执行真正的操作。

由于这种简单的事务在EXEC命令被调用之前不会执行任何实际操作，所以用户将没办法根据读到的数据来做决定。这个问题看上去似乎无足轻重，但实际上无法以一致的形式读取数据将导致某一类型的问题变得难以解决，除此之外，因为再多个事务同事处理同一个对象时通常需要用到二阶提交，所以如果事务不能以一致的形式读取数据，那么二阶提交将无法实现，从而导致一些原本可以执行的事务沦落至执行失败的地步。

Redis提供了一个WATCH命令，在用户使用WATCH命令对Redi键进行监视之后，直到用户执行EXEC命令的这段时间里面，如果有其他客户端抢先对任何被监视的键进行了替换，更新或删除等操作，那么当用户尝试执行EXEC命令的时候，事务将失败并返回一个错误。通过使用WATCH,MULTI/EXEC,UNWATCH/DISCARD等命令，程序可以在执行某些重要操作的时候，通过确保自己正在使用的数据没有发生变化来避免数据出错。

什么是DISCARD?UNWATCH命令可以在WATCH命令执行之后，MULTI命令执行之前对连接进行充值，同样地，DISCARD命令也可以在MULTI命令执行之后，EXEC命令执行之前对连接进行重置。这也就是说，用户在使用WATCH命令监视一个或多个键，接着使用MULTI开始一个新的事务，并将多个命令入队到事务队列之后，仍然可以通过发送DISCARD命令来取消WATCH命令并清空所有已入队命令。

二.Redis锁

Redis中的锁是基于命令SETNX来实现的，SETNX key value， 如果key不存在，就设置key对应字符串value。在这种情况下，该命令和SET一样。当key已经存在时，就不做任何操作。SETNX是”SET if Not eXists”。锁要做的就是将一个随机生成的128位UUID设置为键的值，并使用这个值来防止锁被其他进程获得。

当我们需要加锁的时候，客户端尝试使用SETNX命令，如果返回1，表示获取到了锁，执行需要锁住的代码，然后释放锁，需要注意的是如果出现异常导致锁没有正常释放，这个影响还是很大的，这里我们需要使用expire命令来为key设置超时时长，过了超时时间Redis就会将这个key删除掉，即强制释放锁。

使用Redis实现分布式锁在很多场景下十分有用，典型的秒杀场景中就可以使用Redis分布式锁。下面介绍下Redis分布式锁在秒杀场景中的应用

所谓秒杀，从业务角度看，是短时间内多个用户“争抢”资源，这里的资源在大部分秒杀场景里是商品；将业务抽象，技术角度看，秒杀就是多个线程对资源进行操作，所以实现秒杀，就必须控制线程对资源的争抢，既要保证高效并发，也要保证操作的正确。

刚才提到过，实现秒杀的关键点是控制线程对资源的争抢，根据基本的线程知识，可以不加思索的想到下面的一些方法： 
1、秒杀在技术层面的抽象应该就是一个方法，在这个方法里可能的操作是将商品库存-1，将商品加入用户的购物车等等，在不考虑缓存的情况下应该是要操作数据库的。那么最简单直接的实现就是在这个方法上加上synchronized关键字，通俗的讲就是锁住整个方法； 
2、锁住整个方法这个策略简单方便，但是似乎有点粗暴。可以稍微优化一下，只锁住秒杀的代码块，比如写数据库的部分； 
3、既然有并发问题，那我就让他“不并发”，将所有的线程用一个队列管理起来，使之变成串行操作，自然不会有并发问题。

上面所述的方法都是有效的，但是都不好。为什么？第一和第二种方法本质上是“加锁”，但是锁粒度依然比较高。什么意思？试想一下，如果两个线程同时执行秒杀方法，这两个线程操作的是不同的商品,从业务上讲应该是可以同时进行的，但是如果采用第一二种方法，这两个线程也会去争抢同一个锁，这其实是不必要的。第三种方法也没有解决上面说的问题。

那么如何将锁控制在更细的粒度上呢？可以考虑为每个商品设置一个互斥锁，以和商品ID相关的字符串为唯一标识，这样就可以做到只有争抢同一件商品的线程互斥，不会导致所有的线程互斥。分布式锁恰好可以帮助我们解决这个问题。

分布式锁是控制分布式系统之间同步访问共享资源的一种方式。在分布式系统中，常常需要协调他们的动作。如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源，那么访问这些资源的时候，往往需要互斥来防止彼此干扰来保证一致性，在这种情况下，便需要使用到分布式锁。

我们来假设一个最简单的秒杀场景：数据库里有一张表，column分别是商品ID，和商品ID对应的库存量，秒杀成功就将此商品库存量-1。现在假设有1000个线程来秒杀两件商品，500个线程秒杀第一个商品，500个线程秒杀第二个商品。我们来根据这个简单的业务场景来解释一下分布式锁。 
通常具有秒杀场景的业务系统都比较复杂，承载的业务量非常巨大，并发量也很高。这样的系统往往采用分布式的架构来均衡负载。那么这1000个并发就会是从不同的地方过来，商品库存就是共享的资源，也是这1000个并发争抢的资源，这个时候我们需要将并发互斥管理起来。这就是分布式锁的应用。 

而key-value存储系统，如Redis，因为其一些特性，是实现分布式锁的重要工具。

参考：http://blog.csdn.net/u010359884/article/details/50310387