19.Redis实现分布式锁

分布式锁:

分布式锁是控制分布式系统之间同步访问共享资源的一种方式。在分布式系统中,常常需要协调他们的动作。如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源,那么访问这些资源的时候,往往需要互斥来防止彼此干扰来保证一致性,在这种情况下,便需要使用到分布式锁。


使用Redis实现分布式锁,有几个重要函数需要介绍:

SETNX命令(SET if Not eXists)
语法:
SETNX key value
功能:
当且仅当 key 不存在,将 key 的值设为 value ,并返回1;若给定的 key 已经存在,则 SETNX 不做任何动作,并返回0。

GETSET命令
语法:
GETSET key value
功能:
将给定 key 的值设为 value ,并返回 key 的旧值 (old value),当 key 存在但不是字符串类型时,返回一个错误,当key不存在时,返回nil。

GET命令
语法:
GET key
功能:
返回 key 所关联的字符串值,如果 key 不存在那么返回特殊值 nil 。

DEL命令
语法:
DEL key [KEY …]
功能:
删除给定的一个或多个 key ,不存在的 key 会被忽略。



import common.chitai.util.SpringContextUtil;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import redis.chitai.SharedCache;
import redis.chitai.impl.SharedCacheImpl;

/**
 * Redis分布式锁
 *
 * @author zhangheng
 * @date 2018/6/4
 */
public class RedisLock {
    static final Logger log = LoggerFactory.getLogger(RedisLock.class);

    private static final String LOCK_KEY_PREFIX = "chitailock:";

    /**
     * 延迟时间
     */
    private static final int DEFAULT_ACQUIRY_RESOLUTION_MILLIS = 100;

    private static SharedCache cache = SpringContextUtil.getBean(SharedCacheImpl.class);

    /**
     * 锁的key值
     */
    private String lockKey;

    /**
     * 缓存的值
     */
    private String value;

    /**
     * 锁超时时间,防止线程在入锁以后,无限的执行等待。默认60s
     */
    private int expireMsecs = 60 * 1000;

    /**
     * 锁等待时间,防止线程饥饿。默认10s
     */
    private int timeoutMsecs = 10 * 1000;

    private volatile boolean locked = false;

    /**
     * Detailed constructor with default acquire timeout 10000 msecs and lock expiration of 60000 msecs.
     *
     * @param lockKey lock key (ex. account:1, ...)
     */
    public RedisLock(String lockKey) {
        this.lockKey = LOCK_KEY_PREFIX + lockKey;
    }

    /**
     * Detailed constructor with default lock expiration of 60000 msecs.
     */
    public RedisLock(String lockKey, int timeoutMsecs) {
        this(lockKey);
        this.timeoutMsecs = timeoutMsecs;
    }

    /**
     * Detailed constructor.
     * 过期时间务必设置为大于需要锁的代码段落执行时间的最长时间
     * 否则会出现很严重的问题
     */
    public RedisLock(String lockKey, int timeoutMsecs, int expireMsecs) {
        this(lockKey, timeoutMsecs);
        this.expireMsecs = expireMsecs;
    }

    /**
     * @return lock key
     */
    public String getLockKey() {
        return lockKey;
    }

    private String get(final String key) {
        return cache.get(key);
    }

    private boolean setNX(final String key, final String value) {
        return cache.setnx(key, value);
    }

    private String getSet(final String key, final String value) {
        return cache.getset(key, value);
    }

    /**
     * 获得 lock.
     * 实现思路: 主要是使用了redis 的setnx命令,缓存了锁.
     * reids缓存的key是锁的key,所有的共享, value是锁的到期时间(注意:这里把过期时间放在value了,没有时间上设置其超时时间)
     * 执行过程:
     * 1.通过setnx尝试设置某个key的值,成功(当前没有这个锁)则返回,成功获得锁
     * 2.锁已经存在则获取锁的到期时间,和当前时间比较,超时的话,则设置新的值
     * PS:过期时间务必设置为大于需要锁的代码段落执行时间的最长时间,否则会出现很严重的问题!!!!
     *
     * @return true if lock is acquired, false acquire timeouted
     * @throws InterruptedException in case of thread interruption
     */
    public synchronized boolean lock() throws InterruptedException {
        int timeout = timeoutMsecs;
        while (timeout >= 0) {
            long expires = System.currentTimeMillis() + expireMsecs + 1;
            value = String.valueOf(expires); //锁到期时间
            if (this.setNX(lockKey, value)) {
                // lock acquired
                locked = true;
                return true;
            }

            String currentValueStr = this.get(lockKey); //redis里的时间
            if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {
                //判断是否为空,不为空的情况下,如果被其他线程设置了值,则第二个条件判断是过不去的
                // lock is expired

                String oldValueStr = this.getSet(lockKey, value);
                //获取上一个锁到期时间,并设置现在的锁到期时间,
                //只有一个线程才能获取上一个线上的设置时间,因为jedis.getSet是同步的
                if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
                    //防止误删(覆盖,因为key是相同的)了他人的锁——这里达不到效果,这里值会被覆盖,但是因为什么相差了很少的时间,所以可以接受

                    //[分布式的情况下]:如过这个时候,多个线程恰好都到了这里,但是只有一个线程的设置值和当前值相同,他才有权利获取锁
                    // lock acquired
                    locked = true;
                    return true;
                }
            }
            timeout -= DEFAULT_ACQUIRY_RESOLUTION_MILLIS;

            /*
                延迟100 毫秒,这里使用随机时间可能会好一点,可以防止饥饿进程的出现,即,当同时到达多个进程,
                只会有一个进程获得锁,其他的都用同样的频率进行尝试,后面有来了一些进行,也以同样的频率申请锁,这将可能导致前面来的锁得不到满足.
                使用随机的等待时间可以一定程度上保证公平性
             */
            Thread.sleep(DEFAULT_ACQUIRY_RESOLUTION_MILLIS);

        }
        return false;
    }


    /**
     * Acqurired lock release.
     */
    public synchronized void unlock() {
        if (locked) {
            String currentValueStr = this.get(lockKey); //redis里的时间
            if (value.equals(currentValueStr)) {  //避免由于执行时间大于锁,导致前面的锁解开了后面的锁
                cache.del(lockKey);
            }
            locked = false;
        }
    }

}

以下是针对 **Redis分布式缓存领域20道高频面试题** 的标准面试答案详解,内容符合中高级Java开发工程师在真实技术面试中的表达规范:逻辑清晰、原理深入、关键词突出、语言专业。每道题均包含 **核心概念 + 实现机制 + 应用场景 + 注意事项**,便于应试者精准作答。 --- ### 1. Redis的数据类型? Redis支持五种基本数据类型和三种扩展类型: | 数据类型 | 说明 | 典型应用场景 | |---------|------|---------------| | **String(字符串)** | 最基础类型,可存储文本、数字、序列化对象 | 缓存、计数器、分布式锁 | | **Hash(哈希)** | 键值对集合,适合存储对象属性 | 用户信息、商品详情 | | **List(列表)** | 有序可重复队列,支持双向插入删除 | 消息队列、最新消息排行 | | **Set(集合)** | 无序不重复元素集合 | 好友关系、标签去重 | | **ZSet(有序集合)** | 带分数的Set,按分值排序 | 排行榜、延迟任务 | | **Bitmaps** | 位数组操作 | 用户签到、活跃统计 | | **HyperLogLog** | 基数估算结构 | UV统计(误差率<0.81%) | | **Geospatial(GEO)** | 地理位置坐标存储与计算 | 附近的人、距离计算 | ```java // Java示例(使用Jedis) jedis.set("name", "Tom"); jedis.hset("user:1", "name", "Jerry"); jedis.lpush("msg_queue", "task1"); ``` > ✅ 所有操作都是原子性的,天然适合高并发场景 --- ### 2. Redis的持久化机制? Redis提供两种持久化方式保障数据安全: #### (1)RDB(Redis Database) - **原理**:定时生成数据集的时间点快照(Snapshot) - **触发方式**: - 配置自动触发:`save 900 1`(900秒内至少1次修改) - 手动执行:`SAVE`(阻塞)、`BGSAVE`(fork子进程异步保存) - **优点**:文件紧凑、恢复快、适合备份 - **缺点**:可能丢失最后一次快照后的数据 #### (2)AOF(Append Only File) - **原理**:记录每条写命令日志,重启时重放重建数据 - **同步策略**: - `appendfsync always`:每次写都刷盘(最安全,性能差) - `appendfsync everysec`:每秒刷盘(推荐,默认) - `appendfsync no`:由操作系统决定 - **优点**:数据完整性高,可读性强 - **缺点**:文件大,恢复慢 > ✅ 生产建议:**同时开启RDB+AOF**,兼顾性能与可靠性 --- ### 3. Redis的主从复制原理? 主从复制用于实现数据冗余、读写分离和故障转移。 #### 工作流程: 1. **建立连接**: - 从节点配置 `slaveof <masterip> <port>` 或使用 `REPLICAOF` - 发送PING确认主节点可达 2. **全量同步(Full Resynchronization)**: - 主节点执行 `BGSAVE` 生成RDB - 将RDB文件发送给从节点 - 从节点清空旧数据并加载RDB 3. **增量同步(Partial Resynchronization)**: - 主节点将后续写命令写入**复制积压缓冲区(Replication Backlog)** - 从节点通过偏移量(offset)请求缺失命令 - 使用PSYNC命令进行增量传输 #### 关键组件: - **run_id**:主节点唯一标识 - **replication offset**:复制流的字节偏移量 - **repl_backlog_buffer**:环形缓冲区,默认1MB > ✅ 支持级联复制(主→从→从),减少主库压力 --- ### 4. Redis的哨兵机制? **Sentinel(哨兵)** 是Redis的高可用解决方案,监控主从集群并在主节点宕机时自动切换。 #### 核心功能: - **监控(Monitoring)**:持续检查主从节点是否正常 - **通知(Notification)**:异常时发送告警 - **故障转移(Failover)**:主节点失败后提升一个从节点为新主 - **配置中心(Configuration Provider)**:客户端可通过哨兵获取最新主节点地址 #### 故障转移流程: 1. 多个哨兵对主节点进行主观下线判断 2. 达到法定数量(quorum)后标记为客观下线 3. 选举领导者哨兵执行failover 4. 选择优先级最高的从节点升级为主 5. 更新其他从节点指向新主 6. 对外广播新的主节点地址 ```bash # sentinel.conf 示例 sentinel monitor mymaster 127.0.0.1 6379 2 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 15000 ``` > ✅ 至少部署3个哨兵节点,避免脑裂问题 --- ### 5. Redis的集群模式? **Redis Cluster** 是官方提供的分布式方案,支持数据分片和高可用。 #### 核心特性: - **数据分片**:16384个哈希槽(hash slot),每个key通过CRC16算法映射到槽 - **节点通信**:使用Gossip协议传播节点状态 - **高可用**:每个主节点可配多个从节点,主故障时从节点接管 - **客户端路由**:客户端直接连接任意节点,收到MOVED或ASK重定向 #### 架构要求: - 至少6个节点(3主3从) - 所有节点两两互通(ping/pong消息) ```bash # 创建集群 redis-cli --cluster create 127.0.0.1:7000 ... --cluster-replicas 1 ``` > ✅ 不支持多数据库(SELECT db不可用),仅支持db0 --- ### 6. Redis的缓存穿透、缓存击穿、缓存雪崩? | 问题 | 定义 | 解决方案 | |------|------|----------| | **缓存穿透** | 查询不存在的数据,绕过缓存直击数据库 | 1. 缓存空值(设置短TTL)<br>2. 使用布隆过滤器预判是否存在 | | **缓存击穿** | 热点key过期瞬间大量请求涌入数据库 | 1. 设置永不过期或逻辑过期<br>2. 加互斥锁(如Redis分布式锁) | | **缓存雪崩** | 大量key在同一时间过期导致数据库压力激增 | 1. 过期时间加随机值(如TTL+30min±5min)<br>2. 多级缓存架构<br>3. 高可用集群部署 | > ✅ 防御原则:不让请求直接打到数据库 --- ### 7. 如何解决Redis的并发竞争? 并发竞争指多个客户端同时修改同一key,可能导致数据覆盖。 #### 解决方案: 1. **分布式锁(推荐)** ```java // 使用SETNX实现锁 Boolean locked = jedis.setnx("lock:update_user", "1"); if (locked) { jedis.expire("lock:update_user", 10); // 执行业务逻辑 jedis.del("lock:update_user"); } ``` 2. **Lua脚本保证原子性** ```lua -- 原子递增并限制最大值 local current = redis.call("GET", KEYS[1]) if not current or tonumber(current) < 100 then return redis.call("INCR", KEYS[1]) else return 0 end ``` 3. **消息队列串行化处理** - 将更新请求放入MQ,单消费者顺序处理 > ✅ 推荐:Redisson等框架封装的公平锁更可靠 --- ### 8. Redis的事务机制? Redis事务通过 `MULTI` / `EXEC` 实现一组命令的批量执行。 #### 特性: - **不支持回滚**:即使某条命令失败,其余命令仍会继续执行 - **原子性**:所有命令一次性提交(但非传统意义上的ACID事务) - **隔离性**:事务执行期间不会被其他命令打断 ```bash MULTI SET name Tom INCR age EXEC ``` #### 局限性: - 无法捕获语法错误以外的运行时错误 - 不支持条件判断和循环 > ✅ 替代方案:使用Lua脚本实现复杂原子操作 --- ### 9. Redis的发布订阅机制? Pub/Sub模型实现进程间消息通信。 ```bash # 订阅频道 SUBSCRIBE news # 发布消息 PUBLISH news "Hello World" # 查看订阅者数量 PUBSUB NUMSUB news ``` #### 特点: - 实时性强,低延迟 - 消息不持久化,离线消息丢失 - 不保证送达(fire-and-forget) > ✅ 适用场景:实时通知、聊天室 > ⚠️ 不适用于需要可靠传递的消息系统(建议用Kafka/RocketMQ) --- ### 10. Redis的Lua脚本使用? Lua脚本可在Redis服务端原子执行复杂逻辑。 #### 示例:实现带过期时间的限流器 ```lua local key = KEYS[1] local limit = tonumber(ARGV[1]) local expire_time = ARGV[2] local current = redis.call('GET', key) if current and tonumber(current) > limit then return 0 else redis.call('INCRBY', key, 1) redis.call('EXPIRE', key, expire_time) return 1 end ``` 调用方式: ```java jedis.eval(luaScript, 1, "rate_limit:user_123", "100", "60"); ``` > ✅ 优势:网络开销小、原子性强、减少多次往返 --- ### 11. Redis的内存淘汰策略? 当内存达到 `maxmemory` 限制时触发淘汰策略: | 策略 | 说明 | |------|------| | `noeviction` | 默认,内存不足时报错 | | `allkeys-lru` | 淘汰最近最少使用的任意key | | `volatile-lru` | 仅淘汰设置了过期时间的key中LRU的 | | `allkeys-random` | 随机淘汰任意key | | `volatile-random` | 随机淘汰带过期时间的key | | `volatile-ttl` | 优先淘汰剩余时间最短的key | | `allkeys-lfu` | 淘汰最不经常使用(Least Frequently Used)的key(Redis 4.0+) | ```conf maxmemory 2gb maxmemory-policy allkeys-lru ``` > ✅ 推荐:缓存场景用 `allkeys-lru`,有明确过期策略可用 `volatile-*` --- ### 12. Redis的Pipeline机制? Pipeline用于批量发送命令,减少网络RTT开销。 ```java // 传统方式:N次往返 for (int i = 0; i < 1000; i++) { jedis.set("key:" + i, "value:" + i); } // Pipeline:一次往返 try (Pipeline pipeline = jedis.pipelined()) { for (int i = 0; i < 1000; i++) { pipeline.set("key:" + i, "value:" + i); } pipeline.sync(); // 执行并等待响应 } ``` > ✅ 性能提升显著(特别是跨机房调用),但注意不能保证原子性 --- ### 13. Redis的布隆过滤器? 布隆过滤器是一种空间效率极高的概率型数据结构,用于判断元素是否存在。 #### 原理: - 使用多个哈希函数将元素映射到位数组 - 查询时所有位均为1 → 可能存在;任一位为0 → 一定不存在 - 存在误判率(可调),但不会漏判 ```bash # 使用RedisBloom模块 BF.ADD user_filter "user1001" BF.EXISTS user_filter "user1001" # 返回1 BF.EXISTS user_filter "user9999" # 可能返回1(误判) ``` > ✅ 应用:防止缓存穿透、垃圾邮件识别、爬虫URL去重 --- ### 14. Redis分布式锁实现? 基于 `SETNX` + `EXPIRE` 实现简单分布式锁: ```java public boolean tryLock(String key, String value, int expireSec) { String result = jedis.set(key, value, "NX", "EX", expireSec); return "OK".equals(result); } public void unlock(String key, String value) { String script = "if redis.call('get', KEYS[1]) == ARGV[1] then " + "return redis.call('del', KEYS[1]) else return 0 end"; jedis.eval(script, 1, key, value); } ``` #### 改进方案(Redisson): ```java RLock lock = redisson.getLock("business_lock"); lock.lock(); // 自动续期(watchdog机制) try { // 业务逻辑 } finally { lock.unlock(); } ``` > ✅ 注意事项: - 必须设置超时防止死锁 - 解锁需校验value防止误删 - 推荐使用Redisson等成熟框架 --- ### 15. Redis的持久化方式对比? | 对比项 | RDB | AOF | |--------|-----|-----| | 文件大小 | 小(压缩二进制) | 大(日志文本) | | 恢复速度 | 快 | 慢 | | 数据安全性 | 可能丢失最后一次快照后数据 | 更高(最多丢失1秒) | | 写性能影响 | BGSAVE时有影响 | appendfsync策略决定 | | 可读性 | 二进制,不可读 | 文本,可读可追加 | | 适用场景 | 备份、灾难恢复 | 数据完整性要求高的系统 | > ✅ 最佳实践:**双开**,RDB做定期备份,AOF保障在线数据安全 --- ### 16. Redis的高可用方案? 常见高可用架构: | 方案 | 说明 | |------|------| | **主从复制 + 哨兵(Sentinel)** | 自动故障检测与切换,适合中小规模 | | **Redis Cluster** | 官方分片集群,自带高可用和负载均衡 | | **Codis / Twemproxy** | 中间件方案,支持大规模集群管理 | | **云托管Redis** | 如阿里云Redis、AWS ElastiCache,平台级保障 | > ✅ 推荐组合:Cluster用于大数据量,Sentinel用于小集群 --- ### 17. Redis的性能优化技巧? #### 关键优化点: 1. **合理选择数据结构**:用Hash代替多个String存储对象 2. **禁用危险命令**:`KEYS *` → 改用 `SCAN` 3. **启用Pipeline**:批量操作减少网络开销 4. **控制Key大小**:避免大Key(>10KB)导致阻塞 5. **设置合理的过期时间**:防止内存无限增长 6. **使用连接池**:HikariCP/Redisson优化客户端资源 7. **监控慢查询**:`slowlog get` 分析耗时命令 8. **调整TCP参数**:`tcp-keepalive` 保持长连接 > ✅ 工具推荐:`redis-benchmark` 压测,`redis-cli --stat` 实时监控 --- ### 18. Redis的热点数据处理? 热点数据是指访问频率极高的Key,可能导致单节点压力过大。 #### 解决方案: 1. **本地缓存 + Redis二级缓存** ```java Object data = localCache.get(key); if (data == null) { data = jedis.get(key); localCache.put(key, data, 10); // TTL=10s } ``` 2. **Key拆分(影子Key)** - 将 `hotkey` 拆为 `hotkey::1`, `hotkey::2`... - 随机访问其中一个,分散压力 3. **客户端缓存(Client Side Caching)** - Redis 6.0+支持tracking模式,允许客户端缓存数据 4. **多级缓存架构** - Nginx层 → Local Cache → Redis → DB > ✅ 核心思想:把流量挡在Redis之外 --- ### 19. Redis与Memcached的区别? | 对比维度 | Redis | Memcached | |---------|--------|-----------| | 数据类型 | 支持丰富类型(String/Hash/ZSet等) | 仅支持String | | 持久化 | 支持RDB/AOF | 不支持 | | 集群 | 原生Cluster支持 | 需第三方工具 | | 线程模型 | 单线程(6.0+网络IO多线程) | 多线程 | | 内存管理 | jemalloc,碎片较少 | slab分配器 | | 分布式 | 客户端分片或Cluster | 客户端一致性哈希 | | 高可用 | 支持主从、哨兵、Cluster | 无内置HA机制 | | 功能扩展 | 支持Lua、Pub/Sub、事务、GEO等 | 功能较单一 | > ✅ 推荐:现代应用优先选用Redis,除非追求极致吞吐且无需持久化 --- ### 20. Redis的持久化恢复机制? Redis启动时根据配置自动恢复数据: #### 恢复流程: 1. 如果启用了AOF且AOF文件存在: - 优先加载AOF文件(数据更完整) - 逐条重放写命令重建数据 2. 否则: - 加载最新的RDB快照文件 - 恢复当时的数据状态 #### 注意事项: - AOF重写不影响恢复过程(只保留最终状态) - 若RDB和AOF都关闭,则启动为空实例 - 可通过 `INFO persistence` 查看持久化状态 ```bash # 强制生成RDB BGSAVE # 修复损坏的AOF redis-check-aof --fix appendonly.aof ``` > ✅ 生产环境务必开启持久化,并定期验证dump文件可用性 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值