思路一：通过get 和set 命令实现
这种方式很容易想到，就是当每次请求到来时通过get判断这个锁是否存在，如果不存在则set创建。这种方法有一个弊端，由于get和set是两次Redis请求，二者之间有延时，在高并发的环境下，有可能在get检测到锁不存之后在set之前已经被其他线程set，这时当前线程再set，这样锁就失效了。所以这种方法只能应对并发量不是很高的情况。
思路二：通过setnx 和 expire命令实现
在访问需要互斥访问的资源时，通过setnx命令去设置一个lock 键，setnx的作用是判断锁是否存在，如果不存在则创建，返回成功，如果存在则返回失败，服务器返回给客户端，指示客户端稍后重试。expire命令用于给该锁设定一个过期时间，用于防止线程crash，导致锁一直有效，从而导致死锁。例如：设定锁的有效期为100秒，那么即使线程奔溃，在100秒后锁会自动失效。
setnx lock "lock"
如果成功则设置过期时间
expire lock 100
访问互斥资源结束后,删除锁
del lock
思路三：通过watch和Redis的事务命令实现
这种方式的效果和思路二类似。在请求到时先watch改资源锁，然后再通过在事务执行 创建锁的过程，锁的键值能唯一标识改请求（比如用时间+用户标识）。如果当前还有其他线程请求该资源，当判断该锁存在时则返回错误重试（例如睿思BT tracker返回“服务器过载，自动重试的”的提示就属于此类情况）。如果有多个请求同时判断改锁不存在而创建锁，这样也会由于watch了这个锁，导致之前watch的线程执行事务失败，返回客户端自动重试。这样达最终达到了锁的目的。
