Redis 核心知识与项目实践解析-阿里云开发者社区

Redis 核心知识与项目实践解析

2025-07-17 58

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 本文围绕 Redis 展开，涵盖其在项目中的应用（热点数据缓存、存储业务数据、实现分布式锁）、基础数据类型（string 等 5 种）、持久化策略（RDB、AOF 及混合持久化）、过期策略（惰性 + 定期删除）、淘汰策略（8 种分类）。还介绍了集群方案（主从复制、哨兵、Cluster 分片）及主从同步机制，分片集群数据存储的哈希槽算法。对比了 Redis 与 Memcached 的区别，说明了内存用完的情况及与 MySQL 数据一致性的保证方案。此外，详解了缓存穿透、击穿、雪崩的概念及解决办法，如何保证 Redis 中是热点数据，Redis 分布式锁的实现及问题解决，以及项目中分布式锁

项目中 Redis 的应用场景：我们项目中 Redis 用得很广，主要有三个作用：一是做热点数据缓存和接口数据缓存；二是存储业务数据，像验证码、用户信息、用户行为数据、数据计算结果、排行榜数据等；三是实现分布式锁，解决并发环境下的资源竞争问题。
Redis 的常用数据类型：有 5 种基础数据结构，分别是 string（字符串）、list（列表）、hash（字典）、set（集合）和 zset（有序集合）。
Redis 的数据持久化策略：提供了两种方式将数据持久化到硬盘。一是 RDB 持久化（全量），在指定时间间隔内把内存中的数据集快照写入磁盘；二是 AOF 持久化（增量），以日志形式记录服务器处理的每一个写、删除操作。Redis 4.0 版本支持混合持久化方式，只需设置 aof-use-rdb-preamble yes。
Redis 的数据过期策略：有两种。一是惰性删除，只有在取出 key 时才检查是否过期，对 CPU 友好，但可能有太多过期 key 未删除；二是定期删除，每隔一段时间抽取一批 key 检查过期情况，默认每秒扫描 10 次（可通过 hz 配置修改），每次抽 20 个，若过期比例超 25% 就循环抽取，且最大执行时间 25ms，避免卡死线程。Redis 采用定期删除 + 惰性删除的组合策略。
Redis 的数据淘汰策略：共 8 种。淘汰易失数据的有 volatile-lru（最近最少用）、volatile-lfu（最不经常用）、volatile-ttl（将要过期）、volatile-random（随机）；淘汰全库数据的有 allkeys-lru、allkeys-lfu、allkeys-random；还有不淘汰的 no-eviction（写操作报错）。
Redis 集群使用及方案：我们项目用的是哨兵集群，一主二从，三个哨兵分布在三台 Linux 机器。了解的集群方案有三种：主从复制集群（读写分离，一主多从，解决高并发读）、哨兵集群（主从结构加哨兵监控，主节点故障时自动切换，解决高可用）、Cluster 分片集群（多主多从，解决高并发写和海量数据存储，每个主节点存部分数据）。
Redis 主从同步：允许从节点从主节点通过网络拷贝完整数据备份，主库可读写，写操作自动同步到从库，从库只读。同步分两阶段：全量复制（slave 请求增量同步被拒后，master 生成 RDB 发送，slave 清空本地数据加载 RDB）；增量复制（master 将 RDB 期间的命令记入 repl_baklog，持续发送给 slave，slave 执行命令保持同步）。
Redis 分片集群数据存储和读取：采用哈希槽分区算法，共 16384 个哈希槽（0-16383），不同节点管理不同哈希槽。操作数据时，用 CRC16 算法对 key 计算后取模 16383（slot=CRC16 (key)%16383），得到对应的槽，再找到该槽所在节点进行存取。
Redis 事务及命令：Redis 支持事务，相关命令有 MULTI、EXEC、DISCARD、WATCH，但我们开发中基本不用。
Redis 与 Memcached 的区别：Redis 提供更复杂的数据结构和丰富操作，Memcached 仅支持简单字符串；Redis 原生支持集群，Memcached 不支持；Redis 支持持久化，重启可恢复数据，Memcached 不支持，重启数据清空。
Redis 内存用完的情况：达到内存上限时，写命令返回错误，读命令正常；也可配置内存淘汰机制，达到上限时冲刷旧内容。
Redis 与 MySQL 数据一致性保证：有几种方案，一是先更新 MySQL 再更新 Redis，可能因 Redis 更新失败导致不一致；二是先删 Redis 缓存再更新 MySQL，查询时重新添加缓存，高并发下性能低且可能有旧数据入缓存；三是用 MQ 异步同步，保证最终一致性。我们项目按业务选方案：一致性要求不高的场景不处理（如用户行为数据）；时效数据设过期时间（如接口缓存设 60S，60S 后重新加载）；一致性高但时效要求不高的场景，用 MQ 发送消息更新缓存直到成功（如首页广告、推荐数据）；一致性和时效要求都高的场景，用 Seata 的 TCC 模式（很少用）。
缓存穿透及解决：指查询数据库和缓存都没有的数据，导致频繁访问数据库，压力增大。解决方案：缓存空对象（维护简单但效果一般）；布隆过滤器（维护复杂但效果好）。
缓存击穿及解决：缓存中没有但数据库有的数据（通常缓存过期），并发用户多，同时查缓存未命中后都访问数据库，导致数据库压力骤增。解决方案：热点数据提前预热；设置热点数据永远不过期；加锁、限流。
缓存雪崩及解决：大量缓存在同一时间失效，大量请求落到数据库，导致数据库压力飙升，原因是 key 过期时间相同。解决方案：key 的过期时间引入随机因素。
保证 Redis 中是热点数据的方法：数据库有 1000 万数据，Redis 只能缓存 20 万时，配置 Redis 内存淘汰策略为 LFU 算法，淘汰使用频率低的数据，留下的就是热点数据。
Redis 分布式锁实现及问题解决：主要靠 SETNX 指令（不存在时设值，成功返回 1，失败返回 0）实现。但需解决一些问题：死锁（上锁时设超时时间，如 stringRedisTemplate.opsForValue ().setIfAbsent (PRODUCT_ID, "binghe", 30, TimeUnit.SECONDS)）；锁超时（业务执行时间超锁超时，其他请求获取锁导致并发问题，可引入 watch dog 机制自动续期，或开子线程每 20S 重设超时时间）；归一问题（确保加锁和解锁是同一线程，用 ThreadLocal 绑定唯一标识，存到锁值中，释放时校验）；可重入问题（同一业务多次需获取锁时，用计数器，加锁计数器 + 1，解锁 - 1，减为 0 时从 Redis 删除锁）；阻塞与非阻塞问题（获取锁失败时，可阻塞后续请求直到锁释放，用自旋思想，设置自旋超时避免资源消耗）。
项目中分布式锁的应用：最近项目中，任务调度时用 Redis 分布式锁防止集群部署下定时任务重复执行，后期因任务增多、规则复杂且单节点效率有限，切换为 XXL-JOB，就不再用分布式锁了。

Redis 核心知识与项目实践解析

热门文章

最新文章

相关课程

相关电子书

相关实验场景

探索云世界

热门

云计算

大数据

云原生

人工智能

数据库

开发与运维

活动广场

任务中心

训练营

直播

乘风者计划

下载

镜像站

技术资料

Redis 核心知识与项目实践解析

热门文章

最新文章

相关课程

相关电子书

相关实验场景