对Redis分布式锁是有局限性的认识

前两篇文章探讨了Redis锁的细节，并对Redis锁存在的一些问题提供了对应的处理方案，那么这时的Redis锁是不是一个完美的存在？
答案是否定的，Redis锁仍然存在局限性

如下图所示：
场景一：
现在是Redis的主写从读的模式。
用户A提交订单，则库存-1，票剩余0。
同时B提交订单，若成果就会出现超卖情况。幸好有锁，B订单提交失败

场景二：当线程A成功对库存-1后，还没来得及同步给从节点，主机就挂了
于是会重新选主，从节点变为主节点，但是原来的这个从节点并不知道数据库的库存已经减少为0，且线程A对其上锁了。于是他先查看自己的缓存发现库存是1，且自己还能抢到新锁，于是也减少了库存。

这就导致超卖现象，也就是redis分布式锁的局限性

于是Redis官方提出了redlock（红锁）代替传统的SETNX上锁方式

Redlock是如何处理上述局限性的，以及Redlock适用场景是什么，本文就不重复描述网络上已有的介绍。

RedLock是一种实现锁的算法。简单描述如下：

现在有5个独立部署的Redis（注意不是主从模式），以前给一个redis上锁，现在给所有的redis都上锁。以前给一个redis释放锁，现在给所有的redis释放锁。这样即使一台redis没释放锁挂机了，其他机子知道：他挂机了，且锁没释放。以前仅知道：他挂机了，锁信息也丢失了，就当没上锁处理。

实际上，比如锁的超时时间是3s，给第四个redis上锁时超过了3s，第四台第五台redis上锁就失败了呀。这有的成功有的失败，这锁倒是算怎么回事。redlock规定：只要有2n+1台上锁成功，整体就算成功。

redis1 上锁后挂了，其他redis也保留着锁的信息。锁信息不会完全丢失

参考文章：

细说Redis分布式锁：setnx/redisson/redlock？了解一波？

Is Redlock Safe? 一场关于 Redlock 的辩论

总结来说，如果你的项目不涉及高并发场景，那么setnx实现分布式锁就可以满足基本需求。你只需要了解如何使用lua脚本获取锁，释放锁、锁延时等。spring提供了一个工具类：StringRedisTemplate，里面封装了大量API，包括执行lua脚本，如果你不想使用lua脚本，也有获取锁，释放锁的API。

一共三篇文章从贯穿Redis分布式锁的前世今生，对其有了一定的认识和思考。便可在自己的项目中结合这些利弊判断是否需要上锁，上锁的方式等