本文目录一览：
- 1、redis分布式锁常见问题及解决方案
- 2、Redis主从复制丢失数据的情况分析
- 3、Redis主从模式下过期数据和数据不一致
- 4、高并发没锁可不行,三种分布式锁详解
最大的问题就是因为客户端或者网络问题 ， 导致 redis 中的 key 没有删除，锁无法释放，因此其他客户端无法获取到锁 。
借助Redis setNX命令设置一个标志位就行 。设置成功的放行 ， 设置失败的就轮询等待 。
这个问题也有开源库解决了 ， 就是redis红锁 。下一个问题是分布式锁可以重入么？如果想要实现可重入的分布式锁的话，需要在设置value的时候加上线程信息和加锁次数的信息 。
使用Redis实现分布式锁最简单的方案是使用命令SETNX 。SETNX（SET if Not eXist）的使用方式为：SETNX key value ， 只在键key不存在的情况下，将键key的值设置为value，若键key存在，则SETNX不做任何动作 。
Redis主从复制丢失数据的情况分析Redis 内存淘汰机制有以下几个：noeviction： 当内存不足以容纳新写入数据时，新写入操作会报错 ， 这个一般没人用吧，实在是太恶心了 。
不过，为了避免出现客户端和所有从库都不能连接的情况，我们需要把复制进度差值的阈值设置得大一些 。可以周期性地运行这个流程来监测主从库间的不一致情况 。
用于初次复制或其它无法进行部分复制的情况，将主节点中的所有数据都发送给从节点 。当数据量过大的时候，会造成很大的网络开销。
传统的Redis集群采用的主从复制模式，一般为一主多从，主节点有读写权限 ， 但是从节点只有读的权限 。主节点会定期将数据同步到从节点中，保证数据一致性的问题 。
应用数据已经过期，主库的惰性删除会发生作用，主动对该数据进行删除操作，保证 客户端应用不会拿到过期的数据 。如果 读取的是 Slave 库，则有可能会拿到过期数据，一般造成这样原因有两个 。
Redis主从模式下过期数据和数据不一致1、数据到达过期时间，并不做处理，而是等下次访问该数据时 ， 先判断该数据是否过期，未过期，返回数据 ；发现已过期 ， 删除该数据 ， 返回不存在 。这种方式虽然节约 CPU 性能 ， 发现必须删除的时候才删除 。
2、从库不会进行过期扫描，主库删除时，会在AOF文件里增加一条del指令 ， 同步到所有从库，从库通过此指令来删除 。由于指令的同步存在异步，所以会出现主从数据不一致的情况 。
3、因为指令同步是异步进行的，所以主库过期的 key 的 del 指令没有及时同步到从库的话 ， 会出现主从数据的不一致 这是由 redis 的过期策略来决定 。redis 过期策略是： 定期删除+惰性删除。
4、原因一：跟 Redis 的版本有关系，Redis 2 之前版本，读从库并不会判断数据是否过期，所以有可能返回过期数据 。解决方案：升级Redis的版本，至少要2 以上版本 ， 读从库 ， 如果数据已经过期，则会过滤并返回空值 。
高并发没锁可不行,三种分布式锁详解目前分布式锁的实现方案主要包括三种：基于数据库实现分布式锁主要是利用数据库的唯一索引来实现，唯一索引天然具有排他性，这刚好符合我们对锁的要求：同一时刻只能允许一个竞争者获取锁 。
基于数据库实现分布式锁 悲观锁 利用select … where … for update 排他锁 。注意：其他附加功能与实现一基本一致，这里需要注意的是“where name=lock ”，name字段必须要走索引，否则会锁表 。
【redis主从切换导致锁丢失 主从切换导致redis锁失效】高并发始终要注意的问题：原子性 分布式锁常见的可以使用redis、zookeeper、seata 。目前用的比较多的redis ， 使用分布式锁组件redisson 。如果是直接操作redisTemplate，需要注意finally中释放锁 ， 避免程序问题导致锁无法释放 。
