1、redis中使用WATCH实现锁机制，是最次之的方式。WATCH只会在数据被其他客户端抢先修改了的情况下，“通知”执行了这个命令的客户端，而不会阻止其他客户端对数据进行修改。此类锁成为“乐观锁”
2、redis提供SETNX命令确实具有基本的加锁功能，但他的功能并不完整，并且也不具备分布式锁常见的一些高级特性。
3、自己构建分布式锁。
4、锁不正确运行的症状
1、持有锁的进程因为操作时间过长而导致锁自动释放，但进程本身并不知晓，甚至还可能会错误的释放了其他进程持有的锁。
2、一个持有锁并打算执行长时间操作的进程已经崩溃，但其他想要获取锁的进程并不知道哪个进程持有锁，也无法检测出持有锁的进程是否崩溃，只能白白的浪费时间等待锁被释放
3、在一个进程持有的锁过期之后，其他多个进程同时尝试去获取锁，并且都获得了锁。
4、多个进程获得了同一个锁，而每个进程都以为自己是唯一获得锁的进程。
因为Redis在最新的硬件上可以每秒执行100 000 个操作，甚至 225 000 个操作，所以尽管上面提到的问题出现的几率只有万分之一，但在高负载的情况下还是可能出现
5、判断应该锁住整个数据结构还是应该锁住结构中一小部分，是一件非常简单的事情，但是，需要锁住一小部分数据不止一份的时候，有或者需要锁住结构中的多个部分的时候，这种判断就会更加困难。多个细粒度锁也有引发死锁的危险，导致程序无法运行。