首页 > 数据库 >Redis实战中的一些问题

Redis实战中的一些问题

时间：2024-11-13 17:14:26浏览次数：3  
标签：实战 事务 队列 Redis 命令 Key 一些 延迟

1.延迟队列

1.1 延迟队列概念

        延迟队列（Delayed Queue）是一种常见的队列类型，它允许队列中的消息在指定的延迟时间后才被处理。简单来说，就是消息被放入队列后，系统会等待一段时间，然后才会将它们取出并执行。Redis本身没有内置的延迟队列数据结构，但我们可以通过一些巧妙的方式实现延迟队列的功能。

1.2 延迟队列的应用场景

延迟队列通常用于以下几种场景：

  • 任务调度：比如定时任务的执行，系统中某些任务需要在一定的时间后执行，延迟队列可以在指定的时间点后自动触发任务。

  • 订单超时处理：例如，电商平台中，当用户下单后，如果在规定时间内没有支付，系统需要自动关闭订单并释放库存，延迟队列可以用来在特定时间后执行这个操作。

  • 消息重试：某些异步任务可能会失败，系统希望在一段时间后重新尝试，这时就可以通过延迟队列来控制重试的时机。

  • 流量控制：例如某些API接口访问频率过高时，我们可以使用延迟队列来控制访问间隔，避免过载。

1.3 如何实现延迟队列

        尽管 Redis 没有专门的延迟队列数据类型，但我们可以利用 Redis 的 有序集合（Sorted Set） 来实现延迟队列的功能。具体做法是将消息的执行时间作为有序集合的分值（score），然后按照时间顺序逐步取出和处理消息。

实现思路

  1. 使用有序集合：我们可以将延迟的任务存入 Redis 的有序集合，集合中的每个任务包括一个“执行时间”（score）和任务的具体内容（value）。分值（score）通常是任务的延迟执行时间戳。

  2. 定时扫描：使用定时任务（比如 Redis 的 ZPOPMIN 命令）来周期性地扫描有序集合，获取当前时间前的所有任务并处理它们。

具体实现步骤

假设我们需要将某个任务延迟 10 秒后执行：

  1. 加入任务到有序集合：

    long delayTime = System.currentTimeMillis() + 10000;  // 当前时间 + 10秒
String task = "task-123";  // 任务ID或任务内容
jedis.zadd("delay_queue", delayTime, task);  // 将任务加入有序集合

  2. 处理延迟任务： 定时扫描有序集合，取出当前时间到期的任务并执行：

    long currentTime = System.currentTimeMillis();
Set<String> tasks = jedis.zrangeByScore("delay_queue", "-inf", String.valueOf(currentTime));

for (String task : tasks) {
    // 执行任务
    processTask(task);

    // 删除已处理的任务
    jedis.zrem("delay_queue", task);
}

  3. 删除任务： 如果任务被执行或不再需要，可以通过 zrem 删除该任务。

1.4 关键点

  • 定时扫描：你可以通过 Redis 的 ZPOPMIN 命令获取到最早到期的任务，并在合适的时机执行它们。

  • 时间戳的计算：延迟时间可以通过 System.currentTimeMillis() 获取当前时间戳，然后加上延迟的时间（单位：毫秒），作为分值存入有序集合。

  • 性能考虑：定时扫描的频率不宜过高，通常可以设置一个适当的时间间隔（例如，每秒扫描一次），来平衡性能与实时性。

1.5 小结

        通过 Redis 的有序集合，我们可以高效地实现延迟队列。通过存储任务的延迟执行时间戳，并定期扫描有序集合，可以确保任务在指定的时间点执行。这种方式应用广泛，适用于任务调度、超时处理、消息重试等场景。

2. Redis中的大Key处理

2.1 什么是大Key数据

        大 Key 就是 Redis 中那些存储的数据量过大、占用内存过多的键，通常来说：

  • String 类型的值大于 10 KB
  • Hash、List、Set、ZSet 类型的元素个数超过 5000 个

        这两个维度是判断一个键是否为“大 Key”的常见标准。当然，Redis 本身并没有明确规定“多大”算“大”，但以上的参考值是比较常见的实践标准。

2. 2 大 Key 带来的问题

        大 Key 在 Redis 中可能会导致多个问题，具体包括：

1. 内存占用过多

        大 Key 会占用大量的 Redis 内存，尤其是当 Redis 中有很多大 Key 时，可能会导致内存迅速增长，超出服务器的内存限制，甚至可能导致 Redis 崩溃或频繁的内存回收（例如触发 OOM 错误）。

2. 阻塞操作

        Redis 是单线程的，当你对一个大 Key 进行操作时（例如读取、修改、删除），这些操作可能会非常耗时。由于 Redis 是单线程的，这些阻塞操作会影响到 Redis 其他请求的处理，导致性能下降，甚至可能会引起 Redis 服务的“卡顿”或“无响应”。

3. 复制延迟

        如果 Redis 配置了主从复制，且存在大 Key，当主节点对大 Key 进行修改时，从节点的复制过程也会受到影响。尤其是在从节点需要同步一个大 Key 的时候，复制过程会显著变慢，可能导致主从节点数据不同步，甚至丢失。

4. 迁移与备份问题

        当使用 Redis 的迁移命令（如 MIGRATE）或者进行持久化（如 RDB 或 AOF）时，大 Key 的存在会导致迁移和备份的时间变得非常长，甚至可能因为迁移期间 Redis 被长时间阻塞而导致业务中断。

2.3 大Key的查找

        要定位 Redis 中的大 Key，可以使用一些方法和工具，常见的方式有：

1. 使用 Redis 内置命令

  • MEMORY USAGE：通过 MEMORY USAGE <key> 命令，可以查看某个键的内存使用情况。如果某个键占用的内存非常大，就可以认为它是大 Key。

    MEMORY USAGE mybigkey

  • SCAN 命令扫描所有键并检测内存使用：虽然 Redis 没有直接提供一个列出所有大 Key 的命令，但你可以使用 SCAN 命令遍历所有键，并结合 MEMORY USAGE 命令来统计每个键的内存占用，最终找出占用内存最多的键。

    SCAN 0 MATCH * COUNT 1000

    这个命令会扫描所有的键，并返回每次扫描的部分键。然后，你可以使用 MEMORY USAGE 来检查每个键的内存占用。

2. 使用 Redis 命令行工具

  • Redis Desktop Manager、RedisInsight 等图形化工具：这些工具提供了更直观的查看 Redis 中的键和键的内存使用情况，可以通过图形界面更容易找到大 Key。

3. 使用 redis-cli 的 --bigkeys 参数

        Redis 提供了 redis-cli --bigkeys 命令，用于扫描 Redis 数据库中的大 Key。这个命令会检查 Redis 实例中所有键的大小，并输出占用内存最多的几个键。

redis-cli --bigkeys

该命令会返回类似下面的输出：

192 keys scanned 1 big key found with 10 KB of memory

4. 使用监控工具

        使用如 Prometheus、Grafana 等监控工具，通过监控 Redis 内存的使用趋势和热点键，可以帮助你识别出哪些键占用了过多内存。

2.4 大 Key的删除

删除大 Key 的方法和普通键类似，都是使用 Redis 的标准命令 DEL。但是，删除大 Key 时可能需要注意以下几点：

1. 正常删除

        使用 DEL <key> 命令直接删除大 Key。如果键非常大，这个删除操作可能会比较耗时，甚至会导致 Redis 阻塞。在生产环境中，尽量避免直接删除大 Key，因为它会影响 Redis 的响应时间。

DEL mybigkey
2. 渐进删除

        对于非常大的 Key，建议采用 渐进式删除 或 惰性删除，比如使用 Redis 提供的 UNLINK 命令，它是一个非阻塞删除命令，执行删除时 Redis 会在后台删除键，不会影响前台的请求。

UNLINK mybigkey

UNLINK 命令删除键值对的效率高，可以减少阻塞时间。

3. 拆分大 Key

        对于一些数据量过大的结构（比如大哈希、大集合等），可以考虑将其拆分成多个小键，以减少单个键的内存压力。这可以通过业务逻辑进行拆分和分布式存储。例如，将一个大的哈希表拆分为多个哈希表。

2.5 小结

  • 大 Key 是 Redis 中占用大量内存的键，通常是大字符串、大哈希、大集合等。
  • 大 Key 会引发内存占用过高、阻塞操作、复制延迟和备份问题。
  • 定期使用命令（如 MEMORY USAGE、SCAN、--bigkeys）找到大 Key。
  • 可以通过 DEL 或 UNLINK 删除大 Key，考虑使用渐进删除策略来减少阻塞。

对于 Redis 中的大 Key，及时发现和处理它们是保证 Redis 性能和稳定性的关键。

3. Redis中的管道技术

3.1 Redis 中的管道技术（Pipeline）

        Redis 的 管道（Pipeline） 技术是一种优化 Redis 客户端与 Redis 服务器之间通信性能的机制。它允许客户端一次性将多个命令发送到 Redis 服务器，而不需要等待每个命令的回复。具体来说，管道 是将多个 Redis 命令打包成一个请求，在网络上一次性发送到 Redis 服务器，然后 Redis 服务器处理所有命令并将结果返回给客户端。

        传统的 Redis 操作是 同步阻塞 的，也就是说，客户端发送一个命令后，必须等待 Redis 服务器处理完该命令并返回结果，然后才能继续发送下一个命令。而使用管道技术，客户端可以将多个命令一次性发送出去，而不必等待每个命令的响应，直到所有命令都被服务器处理完之后，才一次性返回所有的结果。这种方式显著提高了 Redis 的性能，尤其是在需要批量处理命令的场景中。

3.2 Redis 管道技术的作用

        管道技术的主要作用是 减少网络延迟 和 提升吞吐量，它主要体现在以下几个方面：

1. 减少网络延迟

        在普通的 Redis 请求过程中，客户端发送每个命令时，都需要等待 Redis 服务器的响应。网络通信是同步的，每发送一个命令就需要等待一个响应，这样的过程会导致大量的延迟，特别是在高延迟的网络环境下或者命令数量较多时，延迟会更加明显。

        而使用管道技术时，客户端可以将多个命令发送到 Redis 服务器，而不需要等待每个命令的响应。这样，客户端和服务器之间的通信效率大大提高，因为它只需进行一次网络交互就能完成多个命令的发送，从而减少了网络延迟的影响。

2. 提升吞吐量

        使用管道技术，可以通过批量发送命令来提高 Redis 的吞吐量。在高并发的情况下，客户端可以一次性发送多个命令，而 Redis 服务器会批量处理并返回结果。与逐个命令发送相比，管道化的方式显著降低了网络通信的开销，增加了单位时间内 Redis 服务器处理命令的数量。

3 减少客户端和 Redis 之间的通信开销

        管道技术减少了客户端与 Redis 之间频繁的请求-响应循环。每发送一个命令就需要等待服务器返回结果，这会消耗大量的时间和带宽。而使用管道时，多个命令一次性发送，Redis 服务器在批量处理时只会一次性返回所有的响应，这大大减少了客户端和服务器之间的通信开销。

3.4 Redis 管道的工作原理

        Redis 管道的工作原理可以简要概括为：

  1. 客户端发送多个命令：客户端将多个 Redis 命令打包到一起，通过管道一次性发送给 Redis 服务器。客户端无需等待每个命令的响应，直接继续发送后续的命令。

  2. Redis 服务器处理命令：Redis 服务器接收到客户端的命令后，会依次处理每个命令并将结果存储起来。

  3. 一次性返回结果：当客户端发送完所有命令后，Redis 会一次性将所有命令的结果返回给客户端。

  4. 客户端获取结果：客户端接收到 Redis 服务器的响应后，从中解析出每个命令的执行结果。

3.4 使用管道技术的场景

  1. 批量插入数据：在需要向 Redis 中批量插入数据时，使用管道技术可以显著提高性能。例如，批量 SET 或者 HSET 命令可以通过管道一次性发送到 Redis，而无需每次发送命令并等待响应。

  2. 批量删除数据：当需要删除大量的键时，通过管道技术可以一次性发送多个 DEL 命令，从而减少请求延迟。

  3. 高并发读写：当应用需要进行高并发的读取和写入操作时，使用管道技术可以显著减少请求响应的等待时间，提高吞吐量。

  4. 提高吞吐量的后台任务：一些任务（如日志处理、批量数据更新等）可能需要频繁访问 Redis，此时使用管道技术可以有效提高任务的处理速度和 Redis 的吞吐量。

4. Redis 的事务

        Redis 的事务机制 是基于 MULTI/EXEC 命令的，它支持一组命令的原子执行，但并不直接支持 回滚。这意味着，虽然你可以将一组命令打包在一起执行，并保证它们要么全部执行成功，要么完全不执行（原子性），但如果事务中某个命令执行失败，Redis 不会自动撤销已经执行的命令，也就是说 Redis 不支持事务回滚。

4.1 为什么 Redis 不支持事务回滚

        要理解 Redis 为什么不支持事务回滚，我们需要先了解 Redis 事务的执行方式和其设计理念。

1. Redis 事务的基本机制

        Redis 事务的核心是 MULTI/EXEC 命令。

  • MULTI：标记事务的开始，接下来所有的命令都会被放入事务队列，而不会立即执行。
  • EXEC：提交事务，执行事务队列中的所有命令。
  • DISCARD：放弃事务，清空事务队列。

        在调用 EXEC 后，Redis 会依次执行事务队列中的命令，并保证它们的 原子性。这意味着要么所有命令都成功执行，要么一个都不执行。

        然而，Redis 事务是基于命令队列的批量执行，不像传统的关系型数据库那样具有回滚机制。也就是说，一旦某个命令被执行，无法撤销或回滚。事务中的每个命令在提交时就被添加到队列中，Redis 只是依次执行这些命令。

2. Redis 事务中的“失败”处理

        虽然 Redis 事务支持 原子性，但它并没有传统数据库那种回滚机制。如果事务中的某个命令出错，Redis 会跳过该命令，并继续执行队列中的其他命令。事务本身会继续执行，直到所有命令都执行完毕。因此，事务不能像传统的数据库那样回滚到事务开始时的状态。

例如：

MULTI SET key1 "value1" SET key2 "value2" INCR key1 # 假设这里出错（比如 key1 不存在或者类型不匹配） EXEC

        在上述例子中，如果 INCR key1 出错（例如 key1 的值是字符串而不是数字），Redis 会跳过这条命令并继续执行队列中的其他命令。但 SET key1 "value1" 会被执行，Redis 并不会撤销它。

        Redis 不支持事务回滚的原因与其设计哲学和高性能目标相关。Redis 是一个 单线程 的高性能数据库，它的事务实现旨在简化事务处理逻辑，从而优化性能：

  • 简化实现：Redis 的事务机制是非常简洁的，它通过队列的方式来实现原子性。加入回滚机制会增加实现的复杂性，特别是当需要保证事务的原子性和一致性时，回滚会涉及到保存和恢复事务执行前的状态，增加了实现和维护的难度。

  • 性能考量：Redis 是为高性能设计的，支持回滚会增加更多的系统开销，例如需要在执行前保存快照或者操作日志，增加了 I/O 操作和内存消耗。而 Redis 的目标是提供尽可能高效的读写操作，回滚机制可能会影响到整体性能。

  • 单线程模型：Redis 是单线程运行的，虽然在内部有多个异步操作（比如网络 I/O），但是事务本质上是按顺序执行的。实现一个事务回滚的机制意味着需要在事务执行期间对每个命令的状态进行详细跟踪，这与 Redis 的单线程设计原则不太匹配。

4.2 如何应对 Redis 不支持事务回滚

        虽然 Redis 不支持事务回滚，但你可以采用一些替代方案来实现类似的功能：

1. 手动补偿操作

        你可以在应用层进行错误处理和补偿操作。一旦事务中的某个命令失败，你可以手动执行补偿逻辑来恢复数据的完整性。比如在操作失败时，通过某些手段将数据恢复到预期状态。

2. 使用 Redis 的“乐观锁”

        虽然 Redis 不支持传统的回滚机制，但它提供了 WATCH 命令，可以用来实现 乐观锁。你可以在事务开始前使用 WATCH 命令来监视某个键，如果在事务执行过程中该键的值发生变化，Redis 会阻止执行事务，避免产生不一致的情况。

WATCH key1 MULTI SET key1 "value1" INCR key1 EXEC

        如果在 WATCH 命令和 EXEC 之间，key1 被其他客户端修改，那么事务会被取消，从而避免了数据的不一致。

3. 重试机制

        在某些情况下，你可以通过应用层的重试机制来弥补事务回滚的缺失。如果某个命令失败，你可以捕获错误并重新尝试执行该命令，或者重新执行整个事务。

4.3 小结

  • Redis 的事务 支持命令的 原子性，即保证事务中的所有命令要么全部成功，要么全部不执行，但 不支持事务回滚。这是因为 Redis 的事务设计简单、轻量，目标是提供高性能和高效的并发执行。

  • 为什么不支持回滚：主要是为了简化实现，保持高性能，并避免引入复杂的回滚机制。

  • 替代方案：可以使用 WATCH 命令实现乐观锁、手动补偿操作、或在应用层实现重试机制来弥补回滚的缺失。

标签：实战,事务,队列,Redis,命令,Key,一些,延迟
From： https://blog.csdn.net/m0_53926113/article/details/143732608

相关文章

  • 家电安装工的操作标准和规范是确保家电安全、高效运行以及延长使用寿命的基础。安装过
    家电安装工的操作标准和规范是确保家电安全、高效运行以及延长使用寿命的基础。安装过程中必须遵循一定的技术规范和安全标准。以下是一些常见家电安装工的操作标准和规范：一、基本要求工作准备：在安装前，了解并检查家电的型号、品牌及产品说明书。确认安装环境符合要求，确保安......
  • Fastapi使用redis
    异步版本rediss.pyfromfastapiimportFastAPI,Depends,APIRouterimportredis.asyncioasaioredisimportuvicornfromcontextlibimportasynccontextmanagerapp=FastAPI()#Redis连接池配置REDIS_URL="redis://192.168.252.128:6379/0"@asyncconte......
  • NGINX负载均衡实战教程：打造高可用性架构 转载
    nginx负载均衡nginx负载均衡介绍反向代理与负载均衡nginx负载均衡配置Keepalived高可用nginx负载均衡器修改Web服务器的默认主页开启nginx负载均衡和反向代理安装Keepalived配置Keepalived编写脚本监控Keepalived和nginx的状态配置keepalived......
  • 实战：Mailivery 模拟登录
    问题情景混淆群内的小伙伴遇到这么个问题，Mailivery这个网站登录后，明明提交的表单（邮箱和密码也正确）、请求头等等都没问题，为啥一直重定向到登录页面呢？唉，该出手时就出手啊，我也看看咋回事吧！url:https://app.mailivery.io/login登录参数分析显而易见，需要：邮箱（有邮箱校验）、密码......
  • 瓷砖的规格种类非常多，适用于不同场景和用途。常见的规格通常按尺寸、材质、功能和安装
    瓷砖的规格种类非常多，适用于不同场景和用途。常见的规格通常按尺寸、材质、功能和安装方式等进行分类。下面是一些常见瓷砖规格及其施工建议的对比表格，帮助选择适合的规格和施工人数。瓷砖规格与施工建议规格/尺寸(mm)适用场景常见材质适用类型施工人数建议优点缺点......
  • 抹水泥挂网是墙面装修和修复中常见的工艺，主要用于增强水泥抹灰层的附着力和抗裂性，尤其
    抹水泥挂网是墙面装修和修复中常见的工艺，主要用于增强水泥抹灰层的附着力和抗裂性，尤其适用于旧墙面或不平整的基础墙面。为了避免空鼓和脱落，在抹水泥时钉上方格网是一个有效的措施，下面是一些详细的步骤和说明：1. 为什么要钉方格网？方格网（通常为钢丝网或玻璃纤维网）在抹水泥时起到......
  • 前端一些常见的报错
    都是错误案例是否存在这个变量？这个变量是否有值（是否赋值成功）？接口数据是否正确（是否成功赋值）？代码从上到下执行的，逻辑是否正确？名字是否打错（包括大小写）？控制台（编辑器）报错信息有没有提示、提示一般会写哪个组件第几行报错，可以点进去看组件命名大小写是否正确......
  • 在 Windows 系统中，可以使用内置的命令行工具来分割和合并大文件，虽然没有专门的 split
    在Windows系统中，可以使用内置的命令行工具来分割和合并大文件，虽然没有专门的split命令（类似于Linux中的split命令），但可以通过一些其他方式实现这一功能。以下是一些常用方法：1.使用 fsutil 命令分割大文件fsutil是Windows提供的一个工具，可以用于管理文件系统，但并不直......
  • selenium测试的一些语法
    元素定位语法通过ID定位：使用find_element_by_id方法，传入元素的ID属性值作为参数。例如，定位一个ID为username的输入框：element=driver.find_element_by_id("username")通过名称定位：使用find_element_by_name方法，根据元素的名称属性来定位。比如定位一个名称为password......
  • SUSE Linux 里一些常用的命令
    在SAPBusinessoneversionforHANA中经常用到的一些命令。重启HANA数据库的服务：用putty或者直接登录suse服务器，打开命令行，先登录数据库用户，如果当时HANA数据库安装使用的是ndb，那对应的就是su-ndbadm--先登录对应的数据库用户su-ndbadm--然后重启数据库服务./H......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99