Redis中分布式锁Redlock的示例分析
这篇文章主要介绍了Redis中分布式锁Redlock的示例分析，具有一定借鉴价值，感兴趣的朋友可以参考下，希望大家阅读完这篇文章之后大有收获，下面让小编带着大家一起了解一下。
Redlock实现库
Java Redisson Star 9458
C# RedLock.net Star 259
Go redsync.go Star 249
虽然后面的算法是一样的，不过这个点赞数确实服。
单点Redis锁
先简单回顾一下单点的Redis锁是怎么实现的。
获取锁
SET resource_name my_random_value NX PX 30000客户端A在Redis上设置一个特定的键值对，同时给一个超时时间(避免死锁)。其他客户端在访问的时候先看看这个key是否已经存在，并且值等于my_random_value。如果已存在就等待，否则就获取成功，执行业务代码。resource_name和my_random_value是所有客户端都知道并且共享的。
释放锁
if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1])else return 0end对比key获取到的对应的value是否相等，如果相等，就删除(释放)，否则就返回失败。
单点Redis锁的缺陷
这个缺陷其实很明显，如果只有一个Redis实例，这个挂了，所有依赖他的服务都挂了。显然不太适合大型的应用。
简单的Redis主从架构碰到的问题
为了避免单点故障，我们给Redis做一个Master/Slave的主从架构，一个Master，一台Slave。下面就会碰到这么一个问题。下面是使用场景。
客户端A在Master上获取到一个锁。
Master把这个数据同步到Slave的时候挂了(因为Master和Slave之间同步是异步的)。
Slave变成了Master。
客户端B通过相同的key，和value获取到锁。分布式锁失效
Redlock算法
假设我们有N(假设5)个Redis master实例，所有节点相互独立，并且业务系统也是单纯的调用，并没有什么其他的类似消息重发之类的辅助系统。下面来模拟一下算法：
1.客户端获取服务器当前的的时间t0，毫秒数。
2.使用相同的key和value依次向5个实例获取锁。客户端在获取锁的时候自身设置一个远小于业务锁需要的持续时间的超时时间。举个例子，假设锁需要10秒，超时时间可以设置成比如5-50毫秒。这个避免某个Redis本身已经挂了，但是客户端一直在尝试获取锁的情况。超时了之后就直接跳到下一个节点。
3.客户端通过当前时间(t1)减去t0，计算获取锁所消耗的时间t2(=t1-t0)。只有t2小于锁的业务有效时间(也就是第二步的10秒)，并且，客户端在至少3(5/2+1)台上获取到锁我们才认为锁获取成功。
4.如果锁已经获取，那么锁的业务有效时间为10s-t2。
5.如果客户端没有获取到锁，可能是没有在大于等于N/2+1个实例上获取锁，也可能是有效时间(10s-t2)为负数，我们就尝试去释放锁，即使是并没有在那个节点上获取到。
锁的释放
释放比较简单，直接删除所有实例上对应的key就好。
感谢你能够认真阅读完这篇文章，希望小编分享的“Redis中分布式锁Redlock的示例分析”这篇文章对大家有帮助，同时也希望大家多多支持编程网，关注编程网行业资讯频道，更多相关知识等着你来学习!
免责声明：
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的，并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据，供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
