Redis应用问题解决-深圳市維司達科技有限公司

应用问题解决

缓存穿透

主要现象：

1、应用服务器压力变大了

2、redis命中率降低

3、一直查询数据库

服务器压力变大，向缓存请求数据时命中率低，一直查询数据库导致缓存没有起到效果，数据库压力大。导致服务器崩溃

主要原因是：

通常是因为遭到了黑客攻击或恶意攻击

解决方法：

一个一定不存在缓存及查询不到的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。

解决方案：

（1）对空值缓存：如果一个查询返回的数据为空（不管是数据是否不存在），我们仍然把这个空结果（null）进行缓存，设置空结果的过期时间会很短，最长不超过五分钟。

（2）设置可访问的名单（白名单）：

使用bitmaps类型定义一个可以访问的名单，名单id作为bitmaps的偏移量，每次访问和bitmap里面的id进行比较，如果访问id不在bitmaps里面，进行拦截，不允许访问。

（3）采用布隆过滤器：（布隆过滤器（BloomFilter）是1970年由布隆提出的。它实际上是一个很长的二进制向量（位图）和一系列随机映射函数（哈希函数）。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。）

将所有可能存在的数据哈希到一个足够大的bitmaps中，一个一定不存在的数据会被这个bitmaps拦截掉，从而避免了对底层存储系统的查询压力。

（4）进行实时监控：当发现Redis的命中率开始急速降低，需要排查访问对象和方问的数据，和运维人员配合，可以设置黑名单限制服务。

缓存击穿

主要现象：

1.数据库访问压力瞬时增加

2.redis里面没有出现大量key过期

3、redis正常运行但是数据库已经崩溃。

主要原因：

redis某个key过期了，大量访问使用这个key

解决方案：

key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题。

解决问题：

（1）预先设置热门数据：在redis高峰访问之前，把一些热门数据提前存入到redis里面，加大这些热门数据key的时长。

（2）实时调整：现场监控哪些数据热门，实时调整key的过期时长。

（3）使用锁：

（1）就是在缓存失效的时候（判断拿出来的值为空），不是立即去loaddb。

（2）先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX）去 set一个 mutex key

（3）当操作返回成功时，再进行load db的操作，并回设缓存，最后删除mutex key

（4）当操作返回失败，证明有线程在load db，当前线程睡眠一段时间再重试整个get缓存的方法。

缓存雪崩

特点：

1.数据库压力变大导致服务器崩溃

原因：

1、在极少时间段，查询大量key的集中过期情况

解决方案

缓存失效时的雪崩效应对底层系统的冲击非常可怕！。

解决方案:

（1）构建多级缓存架构：nginx缓存+redis缓存+其他缓存（ehcache等）

（2）使用锁或队列：

用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。不适用高并发情况。

（3）设置过期标志更新缓存：

记录缓存数据是否过期（设置提前量），如果过期会触发通知另外的线程在后台去更新实际key的缓存。

（4）将缓存失效时间分散开：

比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

分布式锁

设置锁和过期时间

随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的JavaAPI并不能提供分布式锁的能力。为了解决这个问题就需要一种跨VM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题。

分布式锁主流的实现方案：

1.基于数据库实现分布式锁。

2.基于缓存（Redis等）

3. 基于 Zookeeper

每一种分布式锁解决方案都有各自的优缺点

1、使用setnx上锁，通过del释放锁

2、如果锁一直没有释放：设置key过期时间，自动释放

3、上锁之后突然出现异常，无法设置过期时间了：上锁时候同时设置过期时间就可以

UUID防止误删

1. 发生误删的情况

想象有两个客户端（A和B）同时竞争一个分布式锁。客户端A先获取锁（使用SETNX设置“mylock”为某个值，并设置过期时间如30秒），然后开始执行一个耗时任务（如数据库操作）。如果A的任务执行超过30秒，锁自动过期。这时，客户端B看到锁已过期，便成功获取了同一个锁（重新设置“mylock”为新值）。随后，A的任务终于完成，它试图释放锁（直接使用DEL “mylock”删除键），结果误删了B正在使用的锁（redis对不同客户端没有做内置的区分），导致B的任务被中断或出现并发冲突。这就是误删：A删除了不属于自己的锁，影响了其他客户端的安全性，造成系统不稳定或数据不一致。

1. 为什么A的锁被释放了（但任务还在进行）

锁被释放是因为在设计分布式锁时，通常会为锁设置一个过期时间（使用Redis的EX或PX选项，例如PX 30000表示30秒后自动过期）。这是为了防止“死锁”：如果客户端A在持有锁期间崩溃或网络断开，锁不会永久占用资源，其他客户端（如B）无法获取，导致整个系统卡住。Redis服务器会在过期时间到达后自动删除（或视作无效）该键，这相当于“释放”了锁。

然而，锁的过期不影响客户端A的任务继续执行。因为：

任务是客户端侧的逻辑（如您的C++代码中执行的数据库操作或计算），它不依赖Redis锁的存在。锁只是一个“协调信号”，用于防止其他客户端同时操作共享资源。
Redis不会主动通知A“你的锁过期了”，A的任务会继续运行，直到完成。这就造成了“锁已释放，但任务未结束”的情况。如果任务执行时间超过预期（如网络延迟、计算复杂），就会出现这种不匹配，导致潜在的并发问题。

2. 为什么A的任务还在进行（即使锁已释放）

A的任务还在进行是因为分布式锁的本质是客户端自管理的协调机制，而不是Redis强制执行的。锁只是Redis中的一个键值对，用于标记“资源被占用”，但它不控制或中断客户端的任务执行。换句话说：

当A获取锁成功后，它会开始执行任务（如更新共享数据）。
即使锁过期（键被删除），A的任务不会被自动停止或回滚——这是由您的代码决定的。任务的继续执行取决于客户端的编程逻辑，而不是Redis。
这是一种“乐观”设计：假设任务能在过期时间内完成。但在现实中，任务时间不确定（例如，外部API调用超时），所以锁过期后，其他客户端（如B）可能获取锁并开始自己的任务，而A的任务还在后台运行，潜在导致数据冲突（如两个人同时写同一个文件）。

如果不设置过期时间，锁可能会变成“永久锁”，但这更危险（崩溃时无人释放）。因此，过期时间是必须的，但需要结合其他机制（如心跳续期）来处理长任务。

3. 为什么A任务执行后还要释放锁

A在任务结束后还要释放锁，这是标准分布式锁编程模式的一部分：获取锁 → 执行任务 → 释放锁。这确保了锁的“成对”使用，避免资源被永久占用。具体来说：

在代码中，您通常会写成：如果获取锁成功，则执行任务；任务完成后，调用释放锁的函数（例如，使用DEL或Lua脚本删除键）。
即使锁已过期，A的代码还是会执行释放逻辑，因为客户端A不知道锁是否过期（Redis不提供通知）。A假设锁还是自己的，所以会尝试删除键。
这就是误删问题的根源：如果锁已过期并被B重新获取，A的释放操作（DEL）会误删B的锁，导致B的任务被中断。

为了避免这个问题，我们使用UUID（如前所述）：释放时不直接DEL，而是检查键的值是否匹配A的UUID，只有匹配才删除。这样，即使锁过期，A的释放也不会影响B。

4. 如何避免这种问题（建议）

任务时间估算：设置合理的过期时间，比预期任务时间稍长。
心跳续期：在任务执行中，A可以周期性发送命令（如EXPIRE）延长锁的过期时间（例如，每10秒续期一次）。这需要额外线程或定时器实现。
使用UUID + Lua脚本：如之前讲解，确保释放时有所有权校验。
高级方案：采用Redlock算法（在多个Redis实例上获取锁），提高容错性。
代码实现提示（C++示例）：在获取锁后，启动一个线程监控任务时间，如果快过期就续期；释放时用hiredis执行Lua脚本。

这个机制体现了分布式系统的复杂性：锁不是万能的，需要结合业务逻辑设计。如果您有具体的代码场景或想看C++实现示例，随时告诉我，我可以提供更针对性的帮助！

2. 为什么要使用UUID

使用UUID（通用唯一标识符）是为了在释放锁时添加一个“所有权校验”机制，确保只有锁的真正持有者才能删除它。UUID是一个由客户端生成的唯一字符串（如随机生成的36位字符），作为锁的值（value）存储在Redis中。如果不使用UUID，直接删除键可能会像上述场景那样误删他人锁，因为过期后键可能被别人重用。UUID的作用类似于一个“版本号”或“令牌”，它防止了误删问题：释放时先检查值是否匹配自己的UUID，只有匹配才删除。这样，即使锁过期被别人获取，旧持有者也无法删除新锁，从而保证锁操作的原子性和安全性，避免并发冲突，尤其在高并发分布式环境中。

3. 如何使用UUID

在使用时，首先在客户端生成一个唯一的UUID（例如用C++的随机库生成）。获取锁：使用Redis命令如“SET mylock [UUID] NX PX 30000”（NX确保键不存在时设置，PX设置毫秒过期时间）。如果成功，执行任务。释放锁时，不要直接DEL，而是使用Lua脚本原子执行检查和删除：脚本内容为“if redis.call('GET', KEYS[1]) == ARGV[1] then return redis.call('DEL', KEYS[1]) else return 0 end”，通过EVAL命令调用（如“EVAL [脚本] 1 mylock [UUID]”）。如果脚本返回1，表示匹配UUID并成功删除；否则不操作。这样，UUID确保了释放操作的安全性，整个过程原子且高效。

LUA保证删除原子性

1. 为什么需要原子性（非原子场景的风险）

在分布式锁的释放过程中，如果不使用原子操作，可能会出现竞态条件（race condition）。例如，客户端A想释放锁时，需要先检查键的值是否匹配自己的UUID（用GET命令），如果匹配再删除键（用DEL命令）。但这两个操作是分开的：假如在A执行GET（确认匹配）之后、但DEL之前，其他客户端（如B）突然修改了键的值（例如B重新设置了锁），那么A的DEL就会误删不匹配的键，导致安全问题。这违反了原子性原则——操作不是“全成功或全失败”，中间可能被中断或干扰，造成误删或数据不一致。原子性确保“检查 + 删除”作为一个不可分割的整体执行，防止并发冲突，尤其在高并发分布式环境中。

2. Lua脚本如何保证原子性

Redis的Lua脚本执行是单线程的、原子性的：当脚本运行时，Redis会锁定整个脚本的执行过程，不允许其他命令中断它（Redis主线程会独占执行该脚本，直到完成）。这意味着脚本内的所有操作（如GET、条件判断、DEL）作为一个原子单元完成，要么全执行成功，要么全失败（例如脚本出错返回错误）。与其他命令（如MULTI/EXEC事务）不同，Lua脚本更灵活，能包含逻辑判断（如if-then），非常适合“检查并操作”的场景。脚本通过EVAL命令调用，传入KEYS（键列表）和ARGV（参数列表），确保在脚本内部的检查和删除不会被外部干扰，从而保证操作的原子性和一致性。

3. 具体情景解释（分布式锁释放示例）

假设客户端A持有锁“mylock”（值是A的UUID），任务完成后想释放：如果不用Lua，A先发GET "mylock"（检查值是否等于A的UUID），假如匹配，再发DEL "mylock"。但在GET和DEL之间，如果锁已过期且B获取了它（设置新UUID），A的DEL就会误删B的锁。现在用Lua脚本解决：脚本内容为“if redis.call('GET', KEYS[1]) == ARGV[1] then return redis.call('DEL', KEYS[1]) else return 0 end”。A执行EVAL [脚本] 1 mylock [A的UUID]：脚本原子地先GET检查值是否匹配A的UUID，如果匹配就DEL并返回1（成功）；否则返回0（不删除）。整个过程在Redis内部原子执行，即使B在脚本运行中试图修改，也不会干扰，因为脚本独占执行。这防止了误删，确保只有真正持有者才能释放锁。