在高并发的使用场景下，如何让redis里的数据尽量保持一致，可以采用分布式锁。以分布式锁的方式来保证对临界资源的互斥读写。
redis使用缓存作为分布式锁，性能非常强劲，在一些不错的硬件上，redis可以每秒执行10w次，内网延迟不超过1ms，足够满足绝大部分应用的锁定需求。
redis常用的分布式锁的实现方式：
一、setbit / getbit
用索引号为0的第一个比特位来表示锁定状态，其中:0表示未获得锁，1表示已获得锁。
优势：简单；
劣势：竞态条件（race condition），死锁。
获得锁的过程至少需要两步：先getbit判断，后setbit上锁。由于不是原子操作，因此可能存在竞态条件；如果一个客户端使用setbit获取到锁，然后没来得及释放crash掉了，那么其他在等待的客户端将永远无法获得该锁，进而形成了死锁。所以这种形式不太适合实现分布式锁。
二、setnx / del / getset
redis官网有一篇文章专门谈论了实现分布式锁的话题。基本的原则是：采用setnx尝试获取锁并判断是否获得了锁，setnx设置的值是它想占用锁的时间（预估）：
- 如返回1，则该客户端获得锁，把lock.foo的键值设置为时间值表示该键已被锁定，该客户端最后可以通过DEL lock.foo来释放该锁。
- 如返回0，表明该锁已被其他客户端取得，这时我们可以先返回或进行重试等对方完成或等待锁超时。
通过del删除key来释放锁。某个想获得锁的客户端，先采用setnx尝试获取锁，如果获取失败了，那么会通过get命令来获得锁的过期时间以判断该锁的占用是否过期。如果跟当前时间对比，发现过期，那么先执行del，然后执行setnx获取锁。如果整个流程就这样，可能会产生死锁，请参考下面的执行序列：
所以，在高并发的场景下，如果检测到锁过期，不能简单地进行del并尝试通过setnx获得锁。我们可以通过getset命令来避免这个问题。来看看，如果存在一个用户user4，它通过调用getset命令如何避免这种情况的发生：
getset设置的过期时间跟上面的setnx设置的相同：
如果该命令返回的结果跟上一步通过get获得的过期时间一致，则说明这两步之间，没有新的客户端抢占了锁，则该客户端即获得锁。如果该命令返回的结果跟上一步通过get获得的过期时间不一致，则该锁可能已被其他客户端抢先获得，则本次获取锁失败。
这种实现方式得益于getset命令的原子性，从而有效得避免了竞态条件。并且，通过将比对锁的过期时间作为获取锁逻辑的一部分，从而避免了死锁。
三、setnx / del / expire
这是使用最多的实现方式：setnx的目的同上，用来实现尝试获取锁以及判断是否获取到锁的原子性，del删除key来释放锁，与上面不同的是，使用redis自带的expire命令来防止死锁（可能出现某个客户端获得了锁，但是crash了，永不释放导致死锁）。这算是一种比较简单但粗暴的实现方式：因为，不管实际的情况如何，当你设置expire之后，它一定会在那个时间点删除key。如何当时某个客户端已获得了锁，正在执行临界区内的代码，但执行时间超过了expire的时间，将会导致另一个正在竞争该锁的客户端也获得了该锁，这个问题下面还会谈到。
我们来看一下宿舍锁的简单实现很简单：
通过一个while（true），在当前线程上进行阻塞等待，并通过一个计数器进行自减操作，防止永久等待。