1. 项目概述为什么是Redis如果你刚开始接触Web开发听到“数据库”这个词脑子里蹦出来的多半是MySQL、PostgreSQL这类关系型数据库。它们确实强大能帮你把数据整整齐齐地存进表格里用SQL语言进行复杂的查询。但当你开始做一个真正的、有用户访问的Web应用时很快会遇到一个头疼的问题速度。想象一下你的网站首页需要展示最新的10篇文章。每次用户打开首页你的服务器都要去MySQL数据库里执行一次SELECT * FROM articles ORDER BY create_time DESC LIMIT 10。如果只有几十个用户这没什么。但如果同时有几千、几万人访问呢数据库服务器会瞬间被大量的查询请求淹没CPU和磁盘I/O飙升页面加载时间从几百毫秒变成几秒甚至十几秒用户体验直线下降。这就是典型的“数据库瓶颈”。这时候就该Redis登场了。它不是一个用来替代MySQL的“全能”数据库而是一个专门解决这类性能问题的“特种兵”。它的核心价值在于把最常用、最耗时的数据从慢速的磁盘数据库搬到超高速的内存里。用户请求来了先去内存里找找到了就直接返回速度能提升几十甚至上百倍。这个“内存里的数据仓库”就是缓存。所以这个教程要做的就是带你从一个Web新手的角度理解为什么需要Redis并亲手把它集成到你的项目中实现一个高性能的数据访问层。我们不会深究Redis所有复杂的高级功能而是聚焦于最核心、最实用的场景缓存。让你能用最小的学习成本获得最显著的性能提升。2. 核心思路与架构设计2.1 缓存的核心思想空间换时间在计算机科学里“空间换时间”是一个经典策略。Redis就是这个策略的完美体现。磁盘比如你的MySQL数据文件存储空间大、成本低但读写速度慢毫秒级。内存RAM存储空间小、成本高但读写速度极快微秒级甚至纳秒级。缓存的工作流程可以类比你去图书馆查资料无缓存每次都去数据库你想看某本书每次都跑到图书馆数据库的书架磁盘上找。路远、人多并发高时效率极低。有缓存引入Redis你在自己的书桌内存上放一个常用书籍收纳盒Redis。第一次需要某本书时你去图书馆取来同时放一份到自己的收纳盒里。下次再需要时直接从桌上拿瞬间完成。这个“收纳盒”有几个关键特性键值对存储每本书数据都有一个唯一的编号键Key比如“ISBN-12345”。通过这个编号你能瞬间找到它值Value。Redis最基本、最常用的数据结构就是键值对。内存存储所有数据都在RAM里所以读写飞快。数据可设置过期时间你不能把图书馆所有的书都搬到自己桌上。同样缓存也不能无限增长。你可以给收纳盒里的书贴个标签“一周后归还”。到期后自动从桌上清理掉需要时再去图书馆取新的。这保证了缓存的数据不会一直陈旧。支持多种数据结构Redis的“值”不只是简单的字符串。它可以是列表List适合存最新文章ID、哈希Hash适合存一个用户的完整信息对象、集合Set适合存点赞用户ID等这让它非常灵活。2.2 典型Web应用缓存架构对于一个典型的“前端 - Web服务器 - 数据库”三层架构引入Redis后数据流会变成这样graph TD A[用户请求] -- B[Web服务器/应用]; B -- C{查询缓存?}; C -- 缓存命中 -- D[Redisbr/内存缓存]; D -- E[返回数据]; C -- 缓存未命中 -- F[MySQL数据库]; F -- G[查询数据库]; G -- H[写入缓存]; H -- D; D -- E;我们来拆解一下这个流程这也是我们后续代码要实现的核心逻辑接收请求用户访问网站首页。查询缓存应用服务器首先不是直接去查MySQL而是构造一个缓存键Cache Key比如homepage:latest_articles然后向Redis发起查询“嘿Redis你有这个键对应的数据吗”缓存命中如果Redis返回了数据太好了应用服务器直接把这个数据组装成HTML或JSON返回给用户。整个过程完全绕过了缓慢的数据库查询。缓存未命中如果Redis说“没有”可能是第一次查询或者缓存过期被清除了应用服务器就只能“老老实实”地去执行原来的SQL查询从MySQL获取数据。回填缓存从MySQL拿到数据后在返回给用户之前应用服务器会做一件至关重要的事把这份数据按照之前构造的缓存键写入Redis。并且通常会设置一个过期时间TTL比如300秒5分钟。后续请求在接下来的5分钟内所有请求首页的用户都会直接命中Redis缓存享受飞一般的速度。5分钟后缓存过期下一个请求会触发新一轮的“未命中-查询数据库-回填缓存”流程。这个模式就是业界最常用的“Cache-Aside”模式也叫“旁路缓存”。它逻辑清晰对应用侵入性小是我们入门的最佳选择。2.3 工具选型为什么是Redis你可能听过Memcached它也是一个老牌的内存缓存系统。那为什么现在大家更倾向于用Redis呢简单对比一下特性RedisMemcached对新手的影响数据结构丰富字符串、列表、哈希、集合、有序集合等简单仅键值对值只能是字符串Redis胜出。列表存最新消息、哈希存用户对象用起来更自然减少应用层序列化/反序列化的麻烦。持久化支持RDB快照、AOF日志不支持Redis胜出。虽然缓存可以丢失但支持持久化意味着重启服务后可以快速恢复部分热数据或者你可以把它用作不那么重要的主数据库如会话存储。功能范围广泛发布订阅、Lua脚本、事务等专注缓存Redis胜出。除了缓存你未来还可能用它做排行榜有序集合、简单消息队列列表一专多能。性能极高极高持平。在纯缓存场景下两者性能都是毫秒乃至微秒级对于Web应用来说都绰绰有余。复杂度稍高极简Memcached略优。但Redis的复杂度带来的功能优势远大于其学习成本。提示对于新手项目不用纠结直接选Redis。它的多功能性让你在成长过程中不用频繁切换工具社区活跃资料丰富遇到问题更容易找到答案。3. 环境准备与核心工具安装3.1 安装Redis服务器Redis官方支持Linux、macOS也可以通过WSL2在Windows上获得很好的体验。这里以最通用的LinuxUbuntu为例。1. 通过系统包管理器安装最简单打开终端执行以下命令# 更新软件包列表 sudo apt update # 安装Redis服务器和命令行客户端 sudo apt install redis-server -y安装完成后Redis服务会自动启动。你可以用下面命令检查状态sudo systemctl status redis-server如果看到active (running)说明服务已经跑起来了。2. 基本安全配置重要默认安装的Redis为了易用性监听所有网络接口0.0.0.0且没有密码。这在生产环境是极度危险的会被轻易入侵。即使是本地学习也建议养成好习惯。 编辑Redis配置文件sudo nano /etc/redis/redis.conf找到并修改以下几行# 绑定地址改为只允许本地连接 bind 127.0.0.1 # 取消保护模式因为我们已经绑定了本地但如果你需要从其他服务器连接需要更复杂的配置 # protected-mode yes # 保持yes但因为我们绑定了127.0.0.1所以安全 # 可选但推荐设置一个访问密码。取消注释并设置你的密码 requirepass your_strong_password_here保存退出后重启Redis服务使配置生效sudo systemctl restart redis-server3. 使用Redis命令行客户端redis-cli测试# 如果没设密码直接连接 redis-cli # 如果设置了密码连接后需要认证 redis-cli 127.0.0.1:6379 AUTH your_strong_password_here OK连接成功后尝试几个基本命令127.0.0.1:6379 SET mykey Hello, Redis! # 设置一个键值对 OK 127.0.0.1:6379 GET mykey # 获取键的值 Hello, Redis! 127.0.0.1:6379 EXPIRE mykey 10 # 设置10秒后过期 (integer) 1 127.0.0.1:6379 TTL mykey # 查看剩余生存时间 (integer) 7 # 等待10秒后... 127.0.0.1:6379 GET mykey (nil) # 返回nil表示键不存在已过期 127.0.0.1:6379 QUIT # 退出3.2 在Web项目中引入Redis客户端你的Web应用比如用Node.js的Express、Python的Django/Flask、Java的Spring Boot等需要通过一个Redis客户端库来与Redis服务器“对话”。以Node.js (Express) 项目为例初始化你的项目如果还没有mkdir my-web-app cd my-web-app npm init -y npm install express安装最流行的Node.js Redis客户端ioredisnpm install ioredis为什么选ioredis它支持Promise异步/await语法功能全面性能好而且支持Redis集群等高级特性是当前社区的事实标准。在项目中创建并配置Redis客户端。通常我们会创建一个单独的模块如redisClient.js// redisClient.js const Redis require(ioredis); // 创建Redis客户端实例 const redisClient new Redis({ host: 127.0.0.1, // Redis服务器地址 port: 6379, // 默认端口 password: your_strong_password_here, // 如果你设置了密码 // 连接重试策略 retryStrategy(times) { const delay Math.min(times * 50, 2000); return delay; }, }); // 监听连接错误 redisClient.on(error, (err) { console.error(Redis Client Error:, err); // 在实际生产环境中这里可能需要更优雅的错误处理比如告警 }); console.log(Redis客户端已创建尝试连接...); // 可选用一个简单的PING命令测试连接 redisClient.ping().then((reply) { console.log(Redis连接成功:, reply); }).catch((err) { console.error(Redis连接测试失败:, err); }); module.exports redisClient;以Python (Flask) 项目为例安装Redis客户端库pip install redis创建并配置客户端# redis_client.py import redis import logging logging.basicConfig(levellogging.INFO) logger logging.getLogger(__name__) class RedisClient: _instance None def __new__(cls): if cls._instance is None: cls._instance super().__new__(cls) cls._instance._init_client() return cls._instance def _init_client): try: self.client redis.Redis( host127.0.0.1, port6379, passwordyour_strong_password_here, # 可选 decode_responsesTrue, # 将返回的bytes自动解码为str非常方便 socket_connect_timeout5, socket_keepaliveTrue ) # 测试连接 self.client.ping() logger.info(Redis连接成功) except redis.ConnectionError as e: logger.error(fRedis连接失败: {e}) # 根据实际情况决定是抛出异常还是返回一个降级状态 raise def get_client(self): return self.client # 创建一个全局可用的客户端实例 redis_client RedisClient().get_client()实操心得连接管理与单例模式千万不要在每次处理请求时都创建一个新的Redis连接创建连接TCP三次握手、认证是有开销的。应该像上面示例那样在应用启动时创建一个连接池或单例客户端所有请求复用这个连接。ioredis和redis-py默认都内置了连接池管理。4. 核心场景实战为文章列表添加缓存现在我们用一个最经典的场景来实战为博客网站的文章列表添加缓存。假设我们有一个简单的Express应用。4.1 项目基础结构无缓存版本首先看看没有Redis时的“慢速”版本// app_no_cache.js (简化版) const express require(express); const app express(); // 假设我们有一个模拟数据库查询的函数 const { getLatestArticlesFromDB } require(./fakeDb); app.get(/api/articles/latest, async (req, res) { try { console.time(DB_QUERY); // 开始计时 // 直接查询数据库 const articles await getLatestArticlesFromDB(10); console.timeEnd(DB_QUERY); // 结束计时打印耗时 res.json({ success: true, data: articles }); } catch (error) { res.status(500).json({ success: false, message: error.message }); } }); // 模拟的“数据库”查询函数故意延迟模拟IO耗时 // fakeDb.js module.exports.getLatestArticlesFromDB function(limit) { return new Promise((resolve) { // 模拟数据库查询耗时 100ms setTimeout(() { const articles Array.from({ length: limit }, (_, i) ({ id: i 1, title: 文章标题 ${i 1}, content: 这里是文章 ${i 1} 的内容..., createdAt: new Date().toISOString(), })); resolve(articles); }, 100); }); };这个接口每次请求都要等至少100毫秒。并发一高数据库压力巨大。4.2 集成Redis缓存完整实现现在我们引入之前创建好的redisClient实现Cache-Aside模式。// app_with_cache.js const express require(express); const app express(); const redisClient require(./redisClient); // 导入我们创建好的客户端 const { getLatestArticlesFromDB } require(./fakeDb); app.get(/api/articles/latest, async (req, res) { const cacheKey api:articles:latest; // 1. 定义缓存键 const CACHE_TTL 300; // 缓存过期时间单位秒 (5分钟) try { // 2. 第一步尝试从缓存获取 console.time(CACHE_GET); const cachedData await redisClient.get(cacheKey); console.timeEnd(CACHE_GET); if (cachedData) { // 3. 缓存命中 console.log(缓存命中直接返回); // Redis返回的是字符串我们需要解析成JSON对象 return res.json({ success: true, source: cache, data: JSON.parse(cachedData) }); } // 4. 缓存未命中查询数据库 console.log(缓存未命中查询数据库...); console.time(DB_QUERY); const articles await getLatestArticlesFromDB(10); console.timeEnd(DB_QUERY); if (!articles || articles.length 0) { // 处理数据库无数据的情况 return res.json({ success: true, data: [] }); } // 5. 将数据库结果写入缓存回填 // 注意这里使用setex命令它等价于 SET EXPIRE是原子操作 console.time(CACHE_SET); await redisClient.setex(cacheKey, CACHE_TTL, JSON.stringify(articles)); console.timeEnd(CACHE_SET); // 6. 返回数据给用户 res.json({ success: true, source: database, data: articles }); } catch (error) { console.error(接口处理出错:, error); // 7. 缓存或数据库出错时的降级策略 // 尝试直接查数据库即使慢一点也要保证服务可用 try { const articles await getLatestArticlesFromDB(10); res.json({ success: true, source: database_fallback, data: articles }); } catch (dbError) { res.status(500).json({ success: false, message: 服务暂时不可用 }); } } });代码逻辑逐行解析定义缓存键cacheKey是Redis中唯一标识这份数据的字符串。命名最好有规律比如业务:子业务:参数方便管理和清理。这里用api:articles:latest。尝试获取缓存使用redisClient.get(key)。这是一个异步操作但速度极快通常1ms。缓存命中如果cachedData不是null说明缓存存在。直接解析JSON并返回。注意在响应中加入了source: cache方便调试时知道数据来源。缓存未命中如果cachedData是null执行原有的数据库查询逻辑。回填缓存这是最关键的一步。使用setex(key, seconds, value)命令将数据库查询结果序列化为JSON字符串存入Redis并设置过期时间TTL。setex是原子操作比先set再expire更安全。返回数据将来自数据库的新数据返回给用户。错误处理与降级这是生产环境必须考虑的。如果Redis服务挂了redisClient.get报错我们的代码不能崩溃。通过try...catch捕获Redis操作异常降级为直接查询数据库。这保证了即使缓存失效核心业务依然可用只是性能下降。4.3 效果测试与对比启动两个版本的服务器用工具如curl、Postman 或浏览器进行测试。第一次请求缓存未命中请求: GET http://localhost:3000/api/articles/latest 控制台输出: 缓存未命中查询数据库... DB_QUERY: 105.234ms CACHE_SET: 2.123ms 响应: {success:true,source:database,data:[...]}可以看到这次请求耗时约107msDB查询缓存写入和没加缓存时差不多。立即发起第二次请求缓存命中请求: GET http://localhost:3000/api/articles/latest 控制台输出: CACHE_GET: 0.876ms 缓存命中直接返回 响应: {success:true,source:cache,data:[...]}奇迹发生了响应时间从100多毫秒降到了1毫秒左右性能提升了两个数量级。在接下来的300秒内所有请求都会享受这个速度。注意事项缓存穿透想象一个场景有人恶意请求一个不存在的数据ID比如/api/article/999999。这个ID在数据库里不存在。按照我们的逻辑缓存没有去查数据库数据库也没有所以不会回填缓存。下次同一个恶意请求过来又会重复这个过程。这会导致缓存完全失效请求直接压到数据库上这就是缓存穿透。解决方案即使数据库查询结果为空null或空数组我们也应该在缓存中存一个特殊的“空值标记”比如__NULL__并设置一个较短的过期时间比如30秒。这样短时间内相同的恶意请求就会命中缓存中的空标记从而保护数据库。if (!articles || articles.length 0) { // 缓存空结果防止缓存穿透 await redisClient.setex(cacheKey, 30, __NULL__); return res.json({ success: true, data: [] }); }5. 进阶技巧与生产环境考量基础的缓存用上了效果立竿见影。但要真正用到生产环境还有一些坑要避开有一些技巧要掌握。5.1 缓存更新策略数据一致性难题缓存最大的挑战是数据一致性。数据库里的文章更新了但缓存里的还是旧数据用户就看到过时的信息。怎么解决1. 主动失效最常用在更新数据库的操作中同步删除或更新对应的缓存。这要求你清楚地知道哪些缓存键需要清理。// 更新文章内容的接口 app.put(/api/article/:id, async (req, res) { const articleId req.params.id; const newContent req.body.content; // 1. 更新数据库 await updateArticleInDB(articleId, newContent); // 2. 主动使相关缓存失效 const cacheKey api:article:${articleId}; await redisClient.del(cacheKey); // 删除这篇文章的详细缓存 // 如果文章列表缓存也包含了这篇文章也需要清理列表缓存 // 但列表缓存键可能不止一个如最新列表、分类列表清理起来麻烦 const listCacheKey api:articles:latest; await redisClient.del(listCacheKey); // 简单粗暴地删除整个列表缓存 // 更精细的做法是使用通配符删除或维护一个缓存键的集合 res.json({ success: true }); });注意数据库更新和缓存删除必须放在一个数据库事务中吗不一定。Redis操作可能失败为了最终一致性常见的做法是“先更新数据库再删除缓存”。即使缓存删除失败下次查询时也会因为缓存未命中而从数据库加载到新数据。这被称为“Cache-Aside 延迟双删”策略的简化版。2. 设置合理的过期时间TTL给所有缓存都设置一个不过分长的TTL如5-30分钟。即使出现短时间的不一致数据最终也会通过过期而变得一致。这是一种最终一致性的妥协适用于对实时性要求不极高的场景如新闻列表、商品描述。3. 发布订阅模式复杂但实时利用Redis自身的Pub/Sub功能。当数据库更新时发布一个消息所有订阅了该消息的应用实例收到后清理自己的本地缓存或分布式缓存。这适用于大型分布式系统对新手来说复杂度较高。我的经验对于中小型项目“主动失效 较短TTL”的组合拳是最实用、最可靠的。先保证核心流程读缓存、写数据库、删缓存正确再根据业务容忍度调整TTL。5.2 缓存键设计与批量操作键设计规范 好的缓存键应该像文件路径一样清晰。推荐使用冒号分隔的层级结构user:profile:123(用户ID为123的资料)product:detail:456(商品ID为456的详情)article:list:latest:page:1:size:10(文章最新列表第1页每页10条) 这方便以后用通配符进行批量管理比如redisClient.keys(article:list:*)可以找到所有文章列表缓存注意keys命令在生产环境慎用可能阻塞服务可以用scan命令替代。批量操作提升性能 如果你需要一次性获取多个用户的信息不要用循环一个个GET。// 低效做法 for (const userId of userIds) { const user await redisClient.get(user:${userId}); // ... } // 高效做法使用pipeline或mget // 方法1: mget (适用于多个独立的key) const keys userIds.map(id user:${id}); const users await redisClient.mget(...keys); // 一次网络往返获取所有值 // 方法2: pipeline (适用于混合了get、set等多种命令的批量操作) const pipeline redisClient.pipeline(); userIds.forEach(id pipeline.get(user:${id})); const results await pipeline.exec(); // 一次网络往返执行所有命令pipeline能将多个命令打包一次性发送给Redis服务器极大地减少了网络延迟带来的开销在高并发场景下性能提升显著。5.3 内存管理与淘汰策略Redis是内存数据库内存满了怎么办你不能让它崩溃。这就需要配置内存淘汰策略。在redis.conf中通过maxmemory-policy参数设置noeviction默认内存不足时新写入操作会报错。生产环境一般不推荐。allkeys-lru从所有key中淘汰最近最少使用的LRU。这是最常用的策略。volatile-lru只从设置了过期时间的key中淘汰LRU。allkeys-random随机淘汰所有key。volatile-random随机淘汰有过期时间的key。volatile-ttl淘汰剩余生存时间TTL最短的key。建议对于纯缓存场景设置为allkeys-lru。同时务必通过maxmemory参数设置最大内存使用量如maxmemory 1gb并确保它小于你的服务器物理内存给系统和其他进程留出空间。5.4 高可用与监控高可用单点Redis服务器如果宕机所有缓存失效流量直接压垮数据库。生产环境需要考虑主从复制配置一个主节点Master负责写多个从节点Slave负责读和备份。主节点挂了可以手动或自动切换到一个从节点。哨兵模式在主从基础上增加哨兵进程来监控节点健康实现自动故障转移。Redis Cluster官方提供的分布式方案将数据分片存储在多个节点上支持水平扩展和高可用。对于大型应用是终极方案。监控你不能对缓存系统“睁眼瞎”。需要监控命中率keyspace_hits / (keyspace_hits keyspace_misses)。这是衡量缓存效益的核心指标。命中率越高如95%说明缓存效果越好。命中率过低要么是缓存容量不够要么是淘汰策略不合适要么是业务数据本身就不适合缓存如完全随机的查询。内存使用量确保不会触达maxmemory引发淘汰或错误。连接数防止连接泄露或被恶意攻击。慢查询Redis虽然快但复杂命令如keys * 对大集合进行SMEMBERS也可能阻塞。需要监控并优化。可以使用redis-cli --stat查看实时状态或集成更专业的监控工具如RedisInsight、Grafana Prometheus。6. 常见问题排查与调试技巧即使按照教程一步步来你也可能会遇到问题。这里记录一些我踩过的坑和解决方法。6.1 连接失败症状应用启动时报连接错误如ECONNREFUSED或Connection lost。检查Redis服务是否运行sudo systemctl status redis-server检查绑定地址和端口确认redis.conf中的bind设置。如果是本地开发确保是127.0.0.1或localhost。检查客户端配置的host和port是否匹配。检查防火墙如果Redis服务器在另一台机器确保防火墙开放了6379端口。检查密码如果设置了requirepass客户端配置中的password必须正确。6.2 读写超时或响应慢症状偶尔出现Command timed out或响应时间波动大。检查网络如果是远程Redis网络延迟是首要怀疑对象。用ping命令测试延迟。检查Redis负载在Redis服务器上运行redis-cli --latency-history查看延迟历史或redis-cli info stats查看命令统计。如果instantaneous_ops_per_sec持续很高说明并发量大可能需要升级配置或优化命令。避免大Key单个Key对应的Value体积过大如一个包含几万元素的List或Hash在序列化、网络传输、内存分配时都会很慢。确保Value大小合理建议小于10KB。避免使用阻塞命令keys *、flushall在生产环境绝对禁止。对于大数据集用scan代替keys。6.3 数据乱码或类型错误症状取出来的数据是乱码或者操作时提示WRONGTYPE Operation。编码问题确保存和取使用相同的字符编码。在Node.js的ioredis中默认返回Buffer如果你存的是字符串取的时候可能需要.toString()。或者像Pythonredis-py那样配置decode_responsesTrue。数据类型错误Redis命令是类型敏感的。你不能对一个字符串类型的Key执行LPUSH列表操作。用TYPE key命令查看Key的类型。常见的错误是用SET存了一个值后来想用GET取出来再修改结果用了HSET哈希操作。6.4 缓存雪崩与缓存击穿这两个是高频面试题也是生产环境的高风险点。缓存雪崩大量缓存Key在同一时间点或极短时间内过期导致所有请求瞬间涌向数据库造成数据库压力激增甚至宕机。解决方案差异化过期时间不要给所有缓存设置相同的TTL。可以在基础TTL上增加一个随机值如300 Math.random() * 60让缓存失效时间点分散开。永不过期后台更新缓存不设过期时间而是启动一个后台任务定期比如在访问低峰期去更新缓存。或者在获取缓存时发现数据“逻辑上”已旧比如通过一个版本号字段则触发异步更新。服务降级与熔断当数据库压力过大时快速失败返回降级内容如默认列表、友好提示保护数据库。缓存击穿某个热点Key如明星出轨新闻过期的瞬间有大量并发请求同时发现缓存失效都去查询数据库导致数据库瞬间压力巨大。解决方案互斥锁第一个发现缓存失效的请求去获取一个分布式锁可以用Redis的SET key value NX PX timeout命令实现然后去查询数据库并回填缓存。其他并发请求则等待锁释放后重新读取缓存。这保证了只有一个请求会去查数据库。逻辑过期在Value中不仅存储数据还存储一个逻辑过期时间。即使物理缓存未过期如果发现逻辑上已过期则触发异步更新当前请求先返回旧数据。这避免了请求的阻塞。永不过期对极热点数据直接设置为永不过期通过其他机制如消息通知来更新。6.5 调试利器redis-cli 常用命令遇到问题时别光看应用日志直接连上Redis看看。redis-cli -a your_password # 连接 INFO # 查看服务器所有信息 INFO memory # 只看内存信息 INFO stats # 只看统计信息 KEYS pattern:* # 查看匹配模式的键生产环境慎用 SCAN 0 MATCH pattern:* COUNT 100 # 安全地迭代键 TYPE mykey # 查看键的数据类型 TTL mykey # 查看键的剩余生存时间 GET mykey # 获取字符串值 LRANGE mylist 0 -1 # 获取列表所有元素 HGETALL myhash # 获取哈希所有字段和值 MONITOR # 实时打印所有执行的命令调试时用非常影响性能 SLOWLOG GET 10 # 获取最近的10条慢查询7. 从缓存到多面手Redis的其他妙用掌握了缓存你就掌握了Redis 80%的用途。但剩下的20%能让你的应用如虎添翼。1. 会话存储用Redis存用户Session比存在应用服务器内存或文件里好得多。特别是在多台应用服务器负载均衡的场景下用户请求可以被任何一台服务器处理因为它们都能从同一个Redis里读到Session。// 使用 express-session 和 connect-redis const session require(express-session); const RedisStore require(connect-redis)(session); app.use(session({ store: new RedisStore({ client: redisClient }), secret: your_session_secret, resave: false, saveUninitialized: false, }));2. 分布式锁在分布式系统中协调多个进程/服务做一件事如抢购商品、定时任务防重复执行需要锁。Redis的SET key value NX PX milliseconds命令可以轻松实现一个简单的分布式锁。async function acquireLock(lockKey, timeoutMs 5000) { const identifier Math.random().toString(); // 生成唯一标识 const result await redisClient.set(lockKey, identifier, PX, timeoutMs, NX); return result OK ? identifier : null; // 获取成功返回标识失败返回null } async function releaseLock(lockKey, identifier) { // 使用Lua脚本保证原子性只有锁的持有者才能释放 const luaScript if redis.call(GET, KEYS[1]) ARGV[1] then return redis.call(DEL, KEYS[1]) else return 0 end ; await redisClient.eval(luaScript, 1, lockKey, identifier); }3. 简单消息队列利用Redis的List数据结构可以实现一个简单的生产者-消费者模型。// 生产者 await redisClient.lpush(task_queue, JSON.stringify({ taskId: 1, data: ... })); // 消费者 (阻塞式弹出避免忙等待) const task await redisClient.brpop(task_queue, 0); // 0表示无限等待 console.log(Processing task:, task);4. 排行榜利用Sorted Set有序集合可以轻松实现按分数排序的排行榜如游戏积分榜、热搜榜。// 用户得分增加 await redisClient.zincrby(leaderboard, 10, user:123); // 获取前10名 const top10 await redisClient.zrevrange(leaderboard, 0, 9, WITHSCORES);Redis的世界远比缓存广阔。但作为Web新手我强烈建议你先把缓存这一个点吃透、用稳。当你的应用因为缓存而性能飞升时你会有巨大的成就感。之后再根据实际需求慢慢探索它的其他领域。记住技术是为业务服务的选择最适合你当前场景的工具和用法而不是追求技术的“时髦”。