前言
相关系列
- 《Redis & 目录》(持续更新)
- 《Redis & 线程控制 & 源码》(学习过程/多有漏误/仅作参考/不再更新)
- 《Redis & 线程控制 & 总结》(学习总结/最新最准/持续更新)
- 《Redis & 线程控制 & 问题》(学习解答/持续更新)
Redis如何实现分布式锁?
Redis是单进程单线程的,指令执行时不会出现并发问题,因此便可通过{SETNX}指令来设置安全的分布式锁标记。{SETNX}指令的作用是在指定键不存在的情况下保存键/值,并返回0/1来表示失败/成功。而在指定键/值成功保存的情况下,由于其它{SETNX}指令不可能再保存相同键,因此成功执行{SETNX}指令的客户端就相当于持有了锁,并可以此实现对目标资源的安全访问。而在结束对目标资源的访问后,成功执行{SETNX}指令的客户端还需要调用{DEL}指令将指定键/值删除,这意味着其已经完成了解锁。
为了避免死锁问题…客户端在调用{SETNX}指令“加锁”最好可以设置合理的过期时间,从而保证锁不会因为主观/客观的原因而无法解开。
什么是红锁?
我们通常所说的红锁是指由Redisson在早期版本中提供的一种在Redis集群环境中使用的锁,相比普通的锁而言其具备更高的容错性。我们知道锁信息是存在丢失可能的,因为无论是持久化机制/主从同步都无法保证数据完全不丢失,故而程序就可能因为锁的异常解锁而出现异常/并发问题,因此Redisson便设计&提供了红锁来避免这一点。
红锁的思想是同时使用多锁来保护单一资源,这样一来即使少数锁信息因为各种原因而丢失,其余依然存在的锁信息也依然能保证锁功能的正常使用。可以很快发现的是红锁在单机/主从部署的Redis中是没有多少使用意义的,因为在这种情况下无论使用了多少锁去组成红锁,其锁信息也都会被统一保存在单个实例/主机中,因为信息一旦丢失也往往是全局性的。但在集群中就完全不一样的,有这些锁信息会被分配到不同的主节点中保存,因此锁信息丢失也仅限于宕机主节点所包含的部分。
随着版本的迭代,作为单一锁类型存在的红锁其实已经被淘汰了,如今的红锁已经转变任意类型锁为通用锁特性。如此改变的原因正如上文所说是为了增强红锁的使用范围,毕竟绝大部分公司的业务体量都无需使用Redis集群来支撑。红锁特性的具体表现是:当线程试图加/解锁任意类型的锁时,如果其操作的目标Redis实例存在任意形式(主从/集群)的从机,那么其只有在主机将锁信息同步至从机后才会返回成功。如此一来其不但维持了足够的安全性;还减少了锁信息的内存开销;当然最重要的还是将红锁的使用范围从集群层面拓展到了主从层面。