Redis分布式锁

Redis分布式锁如何实现 ?#

在Redis中提供了一个命令setnx(SET ifnot exists)
由于Redis的单线程的，用了命令之后，只能有一个客户端对某一个key设置值，在没有过期或删除key的时候是其他客户端是不能设置这个key的。

如何控制Redis实现分布式锁有效时长呢?#

Redis的setnx指令不好控制这个问题，我们当时采用的Redis的一个框架redisson实现的。
在redisson中需要手动加锁，并且可以控制锁的失效时间和等待时间，当锁住的一个业务还没有执行完成的时候，在redisson中引入了一个看门狗Watch Dog机制，就是说每隔一段时间就检查当前业务是否还持有锁，如果持有就增加加锁的持有时间，当业务执行完成之后需要使用释放锁就可以了。
还有一个好处就是，在高并发下，一个业务有可能会执行很快，先客户1持有锁的时候，客户2来了以后并不会马上拒绝，它会自选不断尝试获取锁，如果客户1释放之后，客户2就可以马上持有锁，性能也得到了提升。

redisson实现的分布式锁是可重入的吗?#

候选人:嗯，是可以重入的。这样做是为了避免死锁的产生。这个重入其实在内部就是判断是否是当前线程持有的锁，如果是当前线程持有的锁就会计数，如果释放锁就会在计算上减一。在存储数据的时候采用的hash结构，大key可以按照自己的业务进行定制，其中小key是当前线程的唯一标识，val是当前线程重入的次数

redisson实现的分布式锁能解决主从一致性的问题吗#

这个是不能的，比如，当线程1加锁成功后，master节点数据会异步复制到slave节点，此时当前持有Redis锁的master节点宕机，slave节点被提升为新的master节点，假如现在来了一个线程2，再次获取锁，由于新的master节点没有同步旧master节点的数据，导致线程1和线程2同时拥有一个锁。
但是可以使用redisson提供的红锁来解决，但是这样的话，性能就太低了，如果业务中非要保证数据的强一致性，建议采用ZooKeeper实现的分布式锁。Redis满足AP思想，而ZooKeeper满足CP思想。

CAP原则#

CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance），但是CAP 原则指示3个要素最多只能同时实现两点，不可能三者兼顾，由于网络硬件肯定会出现延迟丢包等问题，但是在分布式系统中，我们必须保证部分网络通信问题不会导致整个服务器集群瘫痪，另外即使分成了多个区，当网络故障消除的时候，我们依然可以保证数据一致性，所以我们必须保证分区容错性。
至于剩下的一致性和可用性，我们需要二选一，但是鱼和熊掌不可兼得，假设我们选择一致性，那我们就不能让用户访问无法进行数据同步的机器，毕竟该机器上的数据和其他正常机器上的不一致，但是这样我们就丢弃了可用性；假设我们选择可用性，那我们就可以让用户访问无法进行数据同步的服务器，虽然保证了可用性，但是我们无法保证数据一致性。