本文介绍了Redis实现分布式锁的理论，包括单机版和分布式场景下的RedLock。讨论了分布式锁的安全性和活性属性，并解释了为何单机实现存在单点故障问题。文中提到了加锁、解锁的Redis命令以及通过Lua脚本保证原子性。在分布式场景下，通过连接多个独立的Redis实例，确保在超过半数节点上加锁成功才能认为加锁成功，以解决单点故障和安全性问题。
基于Redis实现的分布式锁是一个常用的组件，我们通过Redis官网的文章来回顾下它是如何实现的。
1.什么是Redis锁
讨论技术实现细节之前，我们应该考虑下分布式锁应该具备哪些特性，提供哪些功能。
Safety and Liveness是分布式系统的算法和设计中两个非常重要的属性，我们用这两个属性对分布式锁做个定义。
- Safety—something bad will never happen（某些“坏”情况要保证永远不会发生）
- Liveness—something good will must happen (but we don’t know when)（某些“好”情况可能会发生）
1.Safety property。
分布式锁作为一个“锁”，所谓安全特性我认为其实也是基本功能，即同一时刻，只能有一个客户端可以持有锁（这里是指对同一资源）。
2.Liveness property A。
不会发生死锁。即使一个持有锁的实例挂了或者是发生了分区不一致，也不会死锁。
3.Liveness property B。
错误容忍。只要大多数（超过半数）的节点获取到了锁，就算是持有了锁。
单机情况下，如果Master节点失败了，我们通过FailOver的实现将Master转移到一个Slave节点，这样的方式为什么还不够呢？
可以对市面上常见的Redis分布式锁做个分析，最简单的Redis锁的实现方式是在一个Redis实例中创建一个Key，这个Key有一个过期时间（通过expire命令实现），所以最终这个锁会被释放（LivenessPropertyA）。如果客户端需要释放资源，则删除这个Key。
表面上看这种模式可以很好的工作，但是它隐藏了一个问题：这个架构的单点问题。如果Redis的Master节点挂了怎么办？OK我们可以增加一个Slave，然后当主节点挂了启用Slave节点。但是这个方案是不可行的，如果这样我们无法
最低0.47元/天 解锁文章
扫一扫
494
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
