【Redis合集-05】Redis 持久化机制深度解析：RDB、AOF 与混合持久化

原创 已于 2026-06-11 00:13:51 修改 · 736 阅读 · 5 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
GEO检测
标签
#redis #java #mybatis
于 2026-06-10 23:59:23 首次发布

目录

1. Redis 持久化的两种思路

2. RDB 快照持久化

2.1 RDB 是什么

2.2 RDB 的触发方式

方式一：手动触发

方式二：自动触发（配置 save 参数）

方式三：通过 LASTSAVE 查看上次保存时间

2.3 BGSAVE 的底层原理：Copy-On-Write

2.4 RDB 文件的修复与检查

2.5 RDB 的优缺点

3. AOF 日志持久化

3.1 AOF 是什么

3.2 AOF 的三种写入策略

3.3 AOF 重写（Rewrite）

3.4 AOF 文件修复

3.5 AOF 的优缺点

4. 混合持久化（RDB-AOF Hybrid）

4.1 混合持久化解决什么问题

4.2 开启混合持久化

5. RDB 和 AOF 的选择与组合

5.1 生产环境的配置建议

5.2 同时开启 RDB 和 AOF 时的恢复逻辑

5.3 数据恢复流程

6. 持久化相关的性能优化

6.1 fork 引起的阻塞

6.2 AOF 刷盘策略的选择

6.3 多核 CPU 的利用

7. 运维实践中的注意事项

7.1 定期备份 RDB 文件

7.2 AOF 文件大小监控

7.3 主从架构下的持久化

7.4 避免持久化引起的性能抖动

8. 总结

Redis 作为内存数据库，数据都放在内存里。一旦进程退出或服务器宕机，内存数据就全没了。所以持久化是 Redis 数据安全的第一道防线，也是面试和实际运维中都绕不开的核心话题。

1. Redis 持久化的两种思路

Redis 提供了两种完全不同的持久化方式：

  • RDB（Redis Database）：快照，把某个时间点的内存数据直接写到磁盘文件里。

  • AOF（Append Only File）：日志，记录每一次写命令，重启时重放这些命令来恢复数据。

两种方式可以单独使用，也可以同时开启。

2. RDB 快照持久化

2.1 RDB 是什么

RDB 就是把 Redis 某一时刻的全量内存数据保存到一个二进制文件（默认叫 dump.rdb）中。

可以想象成给 Redis 的内存拍了一张照片，这张照片记录了拍照那一刻的所有数据。如果 Redis 挂了，用这张照片就能恢复到拍照时的状态。

2.2 RDB 的触发方式

方式一：手动触发
# 同步阻塞保存，主线程执行，保存期间不处理任何请求
SAVE

# 异步后台保存，fork 子进程执行，主线程继续处理请求
BGSAVE

  • SAVE：生产中禁用。它会在主线程中执行，如果数据量大，会阻塞所有客户端请求长达数秒甚至更久。

  • BGSAVE：推荐使用。Redis 会 fork 一个子进程，子进程负责把数据写入磁盘，主进程继续处理请求。

方式二：自动触发（配置 save 参数）
# redis.conf 中的配置（默认值）
save 900 1       # 900 秒内至少 1 次修改，触发 BGSAVE
save 300 10      # 300 秒内至少 10 次修改，触发 BGSAVE
save 60 10000    # 60 秒内至少 10000 次修改，触发 BGSAVE

多条 save 规则只要满足任意一条，就会自动触发一次 BGSAVE。这个机制非常实用，我们不需要手动执行备份，系统会根据数据变化频率自动保存。

如果不需要自动 RDB，可以注释掉所有 save 行，或者写 save ""。

方式三：通过 LASTSAVE 查看上次保存时间
# 查看上次 BGSAVE 成功执行的时间戳
LASTSAVE

返回值是一个 Unix 时间戳，可以转换为可读时间。运维时可以用它来判断备份是否按时执行。

2.3 BGSAVE 的底层原理：Copy-On-Write

BGSAVE 之所以能在备份的同时不阻塞读写，靠的是操作系统提供的写时复制（Copy-On-Write，COW）机制。

执行流程如下：

  1. Redis 主进程调用 fork() 创建一个子进程。

  2. 刚 fork 完的那一刻，父子进程共享同一块物理内存（内存页表相同）。

  3. 子进程开始遍历内存数据，写入 RDB 文件。

  4. 在此期间，如果主进程需要修改某个数据（比如 SET），操作系统会把包含该数据的内存页复制一份，主进程在新页面上修改，子进程继续读旧页面。

  5. 子进程完成写入后退出，RDB 文件生成完毕。

整个过程，主进程基本不受影响，只是 fork 那一瞬间需要短暂停顿。

重点理解：fork() 的速度和 Redis 实例的内存大小直接相关。内存越大，页表越大，fork 越慢。对于几十 GB 的大实例，fork 可能耗时几百毫秒甚至上秒，这期间主线程是阻塞的。

2.4 RDB 文件的修复与检查

# 检查 RDB 文件是否有损坏
redis-check-rdb dump.rdb

# 如果损坏，可以尝试修复（会丢弃无法修复的数据）
redis-check-rdb --fix dump.rdb

2.5 RDB 的优缺点

优点：

  • RDB 是单一紧凑的二进制文件，非常适合做冷备份。每天生成一份 dump.rdb，压缩后存到对象存储或异地机房，出问题时直接拿它恢复。

  • 恢复速度快。直接加载一个 RDB 文件，比逐条重放 AOF 日志快得多。

  • 子进程写入，主进程几乎不受影响。

缺点：

  • 两次快照之间的数据会丢失。如果 5 分钟保存一次，最坏情况就是丢 5 分钟的数据。

  • fork 子进程在内存大的时候耗时较长，会有短暂的阻塞。

3. AOF 日志持久化

3.1 AOF 是什么

AOF（Append Only File）记录的是每次写命令，追加到文件末尾。Redis 重启时，通过逐条重放 AOF 文件中的命令来恢复数据。

这就像 MySQL 的 binlog，记录了所有修改数据的操作。

3.2 AOF 的三种写入策略

AOF 的写入策略决定了性能和数据安全性之间的平衡。配置参数为 appendfsync：

# redis.conf
appendfsync always     # 每个写命令都刷盘，最安全也最慢
appendfsync everysec   # 每秒刷盘一次，折中方案（默认）
appendfsync no         # 不主动刷盘，交给操作系统决定

三种策略对比：

策略原理数据安全性性能
always每个写命令完成后立即调用 fsync 刷盘最高，不丢数据最差
everysec每秒执行一次 fsync，异步线程负责最多丢 1 秒数据折中
no不调用 fsync，由操作系统决定何时刷盘（通常 30s）最差，可能丢大量数据最高

推荐使用 everysec，它是性能和安全性的最佳平衡。绝大部分业务场景下，丢 1 秒的数据是可以接受的。

3.3 AOF 重写（Rewrite）

AOF 文件会随着时间不断变大。比如对一个计数器反复执行 100 次 INCR，AOF 里就记录了 100 条命令，但恢复时只需要知道最终值就行。

AOF 重写就是把 AOF 文件压缩的过程：Redis 读取当前数据状态，生成一条条等价的 SET 命令写入新的 AOF 文件。

# 手动触发 AOF 重写
BGREWRITEAOF

重写过程同样通过子进程完成，利用 COW 机制，主进程几乎不受影响。重写期间的新写命令会同时写入旧 AOF 文件和一个重写缓冲区，子进程写完新文件后，主进程再把缓冲区里的增量命令追加到新文件末尾，最后用新文件替换旧文件。

自动触发的配置：

# 当 AOF 文件大小比上次重写后增长了 100% 时触发
auto-aof-rewrite-percentage 100

# AOF 文件最小达到 64MB 才考虑重写
auto-aof-rewrite-min-size 64mb

3.4 AOF 文件修复

# 检查 AOF 文件是否有损坏
redis-check-aof --fix appendonly.aof

# 查看 AOF 文件内容（可以看到具体的命令）
cat appendonly.aof

AOF 文件是文本格式（可以配置为混合格式），直接用 cat 就能看到里面的命令。排查问题时非常方便。

3.5 AOF 的优缺点

优点：

  • 数据安全性高。everysec 策略下最多丢 1 秒数据，always 下几乎不丢。

  • AOF 是文本文件（或混合文件），可读性强，便于排查问题。

  • 自动重写机制可以控制文件大小。

缺点：

  • 相同数据量下，AOF 文件通常比 RDB 大。

  • 恢复速度比 RDB 慢，因为要逐条重放命令（混合持久化改善了这一点）。

  • 频繁 fsync 会带来一定的性能开销。

4. 混合持久化（RDB-AOF Hybrid）

4.1 混合持久化解决什么问题

纯 AOF 的恢复速度慢，因为需要逐条执行命令。纯 RDB 的数据安全性差，因为两次快照之间有丢失窗口。

Redis 4.0 引入的混合持久化结合了两者的优点：

  • AOF 重写时，子进程把当前内存数据以 RDB 格式 写入 AOF 文件的开头。

  • 重写期间的增量命令继续以 AOF 格式 追加到文件后面。

这样，AOF 文件的结构变成了：

恢复时，Redis 先加载前面的 RDB 部分（速度快），再重放后面的 AOF 增量命令（数据新）。既保证了恢复速度，又保证了数据安全性。

4.2 开启混合持久化

# redis.conf（Redis 4.0+ 默认开启）
aof-use-rdb-preamble yes

设置为 yes 后，BGREWRITEAOF 生成的 AOF 文件就是混合格式。不需要额外操作，AOF 重写会自动按混合格式生成。

5. RDB 和 AOF 的选择与组合

5.1 生产环境的配置建议

根据不同的场景需求，常见的组合策略有以下几种：

追求性能，可以接受少量数据丢失：

# 只开 RDB
save 900 1
save 300 10
save 60 10000
# 关闭 AOF
appendonly no

适用于缓存、排行榜等非核心数据。Redis 挂了就挂了，从数据库重新加载就行。

追求数据安全，可接受小幅性能下降：

# 同时开 RDB 和 AOF
save 900 1
save 300 10
save 60 10000
appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes

适用于订单、支付等核心业务数据。绝大部分场景都推荐这套配置。

极致安全：

appendfsync always

每条写命令都刷盘，性能下降明显，一般只在金融、账务等对数据零容忍的场景使用。即便如此，也要先压测确认性能能否满足。

5.2 同时开启 RDB 和 AOF 时的恢复逻辑

Redis 重启时，如果同时存在 RDB 和 AOF 文件，优先使用 AOF 文件来恢复数据，因为 AOF 通常数据更完整。

如果只想要 RDB 的恢复速度但又需要 AOF 的数据安全，4.0 之后的混合持久化就是为此设计的。

5.3 数据恢复流程

# 1. 先把备份文件拷贝到 Redis 数据目录
cp dump.rdb /var/lib/redis/
cp appendonly.aof /var/lib/redis/

# 2. 检查文件完整性
redis-check-rdb dump.rdb
redis-check-aof --fix appendonly.aof

# 3. 启动 Redis
redis-server /etc/redis/redis.conf

启动后可以用 INFO Persistence 查看持久化状态：

redis-cli INFO Persistence

输出示例：

# Persistence
loading:0                        # 0 表示没有在加载数据
rdb_last_save_time:1680000000    # 上次 RDB 保存的时间戳
rdb_last_bgsave_status:ok        # 上次 BGSAVE 的状态
aof_enabled:1                    # AOF 是否开启
aof_last_write_status:ok         # 上次 AOF 写入的状态
aof_last_rewrite_time_sec:3      # 上次 AOF 重写耗时（秒）

6. 持久化相关的性能优化

6.1 fork 引起的阻塞

BGSAVE 和 BGREWRITEAOF 都需要 fork() 子进程。在内存大的实例上，fork 耗时可能达到秒级。

优化方向：

  • 控制单实例内存大小，建议不超过 16GB。超过的话考虑拆分或使用 Redis Cluster。

  • 避免在业务高峰期触发 BGSAVE 或重写。

  • 对 Linux 内核参数进行调优，关闭 THP（透明大页）：

# 关闭透明大页，减少 fork 时的内存复制开销
echo never > /sys/kernel/mm/transparent_hugepage/enabled

6.2 AOF 刷盘策略的选择

always 策略下每次写都 fsync，性能影响巨大。大多数场景用 everysec 就够了。如果 Redis 部署在 SSD 上，fsync 的开销会更低，安全性也更有保障。

6.3 多核 CPU 的利用

持久化过程中，主进程只用一个 CPU 核心处理请求，子进程也只用另一个核心写文件。如果有 4 核 CPU，其实只用了 2 核。所以持久化不会明显拖慢 Redis，但也别指望它能充分利用多核。

7. 运维实践中的注意事项

7.1 定期备份 RDB 文件

即使开了 AOF，也建议保留 RDB 备份，因为 RDB 恢复快。常见做法是：

# crontab 定时任务：每天凌晨 3 点备份
0 3 * * * cp /var/lib/redis/dump.rdb /backup/redis/dump_$(date +\%Y\%m\%d).rdb

备份文件最好压缩后上传到对象存储或异地服务器，防止本机磁盘损坏。

7.2 AOF 文件大小监控

设置监控告警，当 AOF 文件超过阈值（比如 10GB）时及时处理。AOF 文件过大通常是重写没有正常触发或重写太慢导致的。

7.3 主从架构下的持久化

很多人在主库上关掉持久化，让从库来做。这种做法有一定风险：

  • 如果主从同时挂了（比如机房断电），数据全丢。

  • 从库做持久化时，主库的数据可能还没同步过来，存在不一致。

更稳妥的做法是：主库开 AOF（everysec），从库开 RDB（用于备份）。这样既保证了主库的数据安全，又有从库的冷备。

7.4 避免持久化引起的性能抖动

  • 设置 save 参数时，避免在短时间内触发太多次 BGSAVE。

  • 对于写密集场景，适当调高 auto-aof-rewrite-percentage，避免频繁重写。

  • 监控 info Persistence 中的 rdb_last_bgsave_time_sec（上次 BGSAVE 耗时）和 aof_last_rewrite_time_sec（上次重写耗时），如果耗时异常增长，说明内存数据量变大了，需要考虑拆分。

8. 总结

Redis 的持久化机制经历了三个阶段的演进：

  1. 纯 RDB 时代：简单，但丢数据多。

  2. RDB + AOF 并存：安全了，但恢复慢。

  3. 混合持久化（4.0+）：兼顾恢复速度和数据安全，是目前的最佳实践。

我个人在实际项目中的经验是：大多数场景用 RDB（冷备）+ AOF（混合持久化，everysec）这套组合就足够了。数据安全性有保障，恢复速度也快，性能开销在可接受范围内。

如果是纯缓存场景，数据可以从数据库重新加载，关掉持久化也没问题。但如果是存储了计数器、分布式锁、排行榜等不可再生数据，持久化就是必须的，宁可牺牲一点性能也要保证数据不丢。

排查持久化问题的第一手工具，关键命令：

# 随时查看持久化状态
INFO Persistence

# 检查 AOF 文件健康度
redis-check-aof --fix appendonly.aof

最后，如有改进之处欢迎指正，觉得有帮助的话不妨点赞收藏支持一下，感谢！

Redis - 主从集群脑裂：数据丢失的隐藏杀手
小工匠
06-16 474
摘要： Redis主从集群中的脑裂问题会导致数据丢失，表现为客户端写入原主库的数据在切换后被全量同步清除。脑裂常由主库假故障（如资源争抢或实例阻塞）引发，此时哨兵触发切换但原主库仍在接收写入。通过配置min-slaves-to-write和min-slaves-max-lang参数，可限制主库在从库同步异常时拒绝写入，减少数据丢失风险。建议参数设置需结合从库数量和哨兵超时时间，并注意该方案无法完全避免数据丢失。本质上是Redis异步复制在性能与一致性间的权衡，关键运维措施包括避免主库资源竞争和监控阻塞情况。
从零实现一个分布式锁：Redis与Zookeeper
最新发布
2502_94055806的博客
06-22 56
│ 客户端A │ ──────────────────────────────────────→ │ Zookeeper │。│ 客户端A │ ───────────────────────────────────────→ │ Redis │。│ 客户端A │ ───────────────────────────────────────→ │ Redis │。printf("\n--- Zookeeper分布式锁 ---\n");printf("--- Redis分布式锁 ---\n");
先更库还是先删缓存？数据库与 Redis 双写一致性全对比
2603_94941239的博客
06-22 192
先更库，后删缓存。不是因为它完美，而是因为它的最坏情况只是"短暂不一致"，而反过来的最坏情况是"永久脏数据"。能用 MQ 异步删，就别在主链路上同步删。能让 Canal 干的活，就别让业务代码扛。双写一致性的本质不是选顺序，而是承认一定会不一致，然后设计一个能自愈的机制。
Redis 数据结构
土司先生的博客
06-22 153
redis 的 string , list 队列，Set 集，的数据结构讲解
Redis SET NX EX 使用说明
bsklhao的博客
06-22 179
在 Redis 中，SET NX EX是一种将设置键值对、条件判断和过期时间结合在一起的原子操作。
百度 C++/PHP 研发一二面：一面扫八股和算法，二面开始逼近 Redis、MySQL 和秒杀设计
TechPioneer_lp的博客
06-15 248
这篇百度C++/PHP研发面经展现了后端岗位的面试进阶路径：一面侧重算法、操作系统、网络等基础（如链表判环、HTTP协议），二面则深入Redis/MySQL底层、高并发设计（如秒杀系统）。面经揭示百度筛选标准：基础合格后，重点考察缓存/数据库系统理解、高并发设计能力。建议准备时：一面夯实算法和语言基础（C++关键字/多态），二面吃透Redis/MySQL原理，并构建系统设计思维。笔试不佳仍有面试机会，但二面才是真正的能力分水岭。
[036][缓存模块]基于 Redis 自定义缓存锁的设计与实现
2403_86882821的博客
06-21 245
本文介绍了一种基于Redis的轻量级分布式锁组件的设计与实现，通过注解+AOP+Lua脚本的方式解决高并发场景下的缓存击穿、重复计算和资源竞争问题。该组件提供固定租期和自动续期两种模式，支持SpEL动态Key生成，确保操作的原子性和安全性。核心实现包含自定义注解@RedisLockable、AOP切面、Lua脚本加解锁逻辑以及自动续期机制。优点包括声明式编程、灵活Key设计、双模式选择和原子操作，但也存在线程泄露风险、缺乏重试机制等不足，建议改用ScheduledExecutorService并增加取消回调
Redis 从入门到实战
qq_72113648的博客
06-20 246
上面命令后面加上 --raw 参数即可正常显示中文redis-cli连接成功后，会看到提示符。如果设置了Redis密码，则需要使用AUTH命令手动验证密码让我们来练习几个最基础的通用命令，来管理 Redis 中的 Key。- 设置一个键值对- 获取一个键的值- 查找所有符合给定模式的 Key（- 判断一个 Key 是否存在- 返回 Key 所存储的值的类型- 为 Key 设置过期时间（单位：秒）- 删除一个或多个 Key。
Redis 的IO
菜鸟的博客
06-17 230
为了避免用户导致冲突甚至内核崩溃，用户应用与内核时分离的：用户空间只执行受限的命令，而且不能直接调用系统资源，必须通过内核提供的内核空间可以执行特权命令，调用一切系统资源Linux系统为了提高IO效率，会在用户空间和内核空间都加入缓冲区:写数据时，要把用户缓冲数据拷贝到内核缓冲区，然后写入设备读数据时，要从设备读取数据到内核缓冲区，然后拷贝到用户缓冲区顾名思义，非阻塞IO的recvfrom操作会立即返回结果而不是阻塞用户进程。
反向海淘跨境缓存架构优化：taocarts Redis分层缓存实战技术
taocarts_bidfans的博客
06-16 292
反向海淘系统存在大量高频访问、动态更新、实时性要求高的数据，包括实时汇率、商品库存、热门商品数据、物流轨迹、用户会话、接口返回数据等，这类数据若频繁请求数据库或第三方API，会导致数据库压力过载、接口响应延迟、系统卡顿、第三方限流封禁等问题，严重影响用户体验与系统稳定性。taocarts系统基于Redis搭建分层缓存架构，针对反向海淘专属业务场景，设计差异化缓存策略、过期机制、预热规则、击穿防护，完美适配跨境业务高并发、高动态、高稳定的运行需求。汇率、库存等实时数据缓存更新不及时，出现数据滞后、展示错乱；
Go 企业级工程能力实战（8）：Redis 不只是缓存——分布式限流、在线心跳与分布式锁从零实现
binbin3828的博客
06-21 116
Redis 在场景Redis 能力关键命令解决什么问题分布式限流原子计数器INCREXPIRE多实例共享限流计数在线心跳带 TTL 的状态存储SETEX高频写入 + 自动过期 + 批量查询分布式锁（扩展）互斥锁SETNXEXPIRE+ Lua 脚本多实例下资源互斥（库存扣减/定时任务去重）接口抽象Limiter接口让内存和 Redis 两种实现无缝切换，调用方完全不感知优雅降级：Redis 不可用时自动回退到内存方案，服务不崩溃，只是限流精度下降做减法。
Spring AI 实战指南（八）：Spring AI + Redis + PGVector + DeepSeek 企业级性能优化与高并发架构设计
2601_94975336的博客
06-17 165
更高级方案。自动总结用户：Java开发准备面试目标大厂100条聊天记录80%以上当你的项目发展到这一步时，你已经不仅仅是在做一个 Spring AI Demo，而是在构建一个真正可上线的 AI 平台。ChatClient↓↓RAG↓↓↓Agent↓MCP↓性能优化↓企业级AI架构。
正规 API 中转站怎么判断？个人和企业如何挑选稳定又相对省心的 AI API 接口（附 Dify、Cursor 配置与报错排查）
weixin_54442559的博客
06-21 468
如果只给一个最朴素的判断标准，我会说：稳定不是零报错，而是报错好查、切换好换、成本好算。便宜也不是单价最低，而是你把重试、超时、人工排查和团队协作都算进去之后，总成本仍然可控。个人开发者更适合先看接入门槛和错误提示是否清楚，先把脚本、Dify、Cursor 这些常见入口跑通。团队用户更应该看权限、日志、预算和统一管理。企业用户则优先看合规、审计、分权和备选方案，而不是只盯着价格。我自己的经验是，真正好用的 AI API 接口，不是让你完全不报错，而是让你知道错在哪、改哪、怎么切。
Redis 过期删除三大策略详解
2609_95039045的博客
06-22 171
策略本质定时删除用 CPU 换内存，太贵，不用惰性删除用内存换 CPU，太懒，单用会漏定期删除抽样巡逻，可控可调，是主力Redis 组合拳定期巡逻 + 惰性把关 + Fast 应急 = 性能与内存的最优解Redis 的过期删除，不是某一种策略的胜利，而是两种策略互相补短的艺术。理解这一点，才算真正读懂了 Redis 的内存管理哲学。
Docker搭建Elasticsearch+Redis+Logstash+Filebeat日志分析系统完整指南
曼陀罗的博客
06-17 258
3节点的Elasticsearch集群提供高可用存储Logstash负责日志采集和处理Filebeat作为轻量级日志采集器Kibana提供可视化分析界面Redis/Kafka作为消息缓冲队列这套系统可支持大规模日志采集和分析场景，并可根据实际需求进行横向扩展。在实际生产环境中，建议根据日志量动态调整各组件资源配置，并建立完善的监控告警体系。
防重复提交-Redis注解AOP组件设计
weixin_51864284的博客
06-16 233
重复提交如果每个接口都手写一遍，代码会很快变乱。更好的方式是把它收进一个注解组件里，让业务方只关心“这个接口要不要防重”，而不是每次都重复写 Redis 判断逻辑。核心就两步：先拿到 key，再尝试写入 Redis。如果写不进去，说明这次请求已经在处理中，直接返回。它的目标不是“绝对禁止所有重复”，而是把大部分重复请求挡在入口，把并发冲突变成可控问题。
搜狗电话面试：网络、MySQL、Redis、锁和 Linux 命令一次全扫
TechPioneer_lp的博客
06-16 129
这篇搜狗后端电话面经展现了典型的基础知识快扫模式，覆盖网络协议（TCP握手/挥手、粘包）、数据库（MySQL隔离级别、索引）、Redis缓存问题、进程通信、Linux命令等核心考点，最后以两数之和算法题收尾。这种面试重点考察候选人知识体系的完整性和口头表达能力，特别容易暴露基础薄弱环节。面经价值在于揭示了后端岗位的基础能力门槛：网络、数据库、操作系统等知识必须形成系统认知，才能通过电话面试的即时问答考验。准备此类面试需重点强化各模块的逻辑串联和场景化表达，而不仅是碎片化知识点记忆。
Redis的使用
2401_87522762的博客
06-17 333
本文介绍了在Ubuntu和CentOS系统下安装和操作Redis的方法。Ubuntu系统中使用apt命令安装Redis，并通过service命令管理服务状态；CentOS系统则使用yum安装，通过systemctl进行服务管理。两个系统均可使用redis-cli命令启动客户端进行键值操作。文章提供了查看状态、启动、停止和重启Redis服务的具体命令，并强调不同系统需使用对应的操作指令。
Linux——Redis
炘爚的博客
06-16 316
Redis是一个开源的内存数据结构存储系统，支持多种数据结构（字符串、哈希、列表等），常用于缓存、会话存储和消息队列。它通过RDB快照和AOF日志实现持久化，保证数据安全。Redis采用旁路缓存模式与数据库协作：读请求优先查询Redis，未命中则查询数据库并回写缓存；写请求先更新数据库再删除缓存以确保一致性。Redis提供主从复制、哨兵模式等高可用方案，并面临缓存雪崩、击穿、穿透等问题，可通过随机过期时间、互斥锁、布隆过滤器等策略解决。其高性能、丰富的数据结构和原子操作特性使其成为分布式系统的关键组件。
Redis 为什么速度远超MySQL？
2603_94941287的博客
06-22 167
维度RedisMySQL存储介质内存磁盘（+ Buffer Pool 缓存）数据结构哈希表/跳表等，O(1)B+ 树，O(logN)线程模型单线程命令执行 + 多线程 IO（6.0+）多线程 + 连接池IO 模型epoll 多路复用（事件驱动）典型延迟微秒级毫秒级事务支持无（仅简单事务）ACID 完整支持适用场景缓存、计数、排行榜、分布式锁复杂查询、事务、持久化Redis 快，不是因为某一个点，而是内存 + 哈希表 + 单线程无锁 + epoll 多路复用。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值