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