【Redis】Redis 常用命令理解与汇总（超全超详细+持续更新）

敖云岚

于 2025-05-03 14:45:52 发布

阅读量1.1k

点赞数 28

分类专栏： Redis 文章标签： redis 数据库缓存

本文链接：https://blog.csdn.net/m0_75022408/article/details/147676454

版权

一、Redis 的概述

Redis，Remote Dictionary Server，远程字典服务器，由意大利人 Salvatore Sanfilippo（又名 Antirez）开发，是一个使用 ANSIC 语言编写、支持网络、可基于内存亦可持久化的日志型、NoSQL 开源内存数据库，其提供多种语言的 API。从 2010 年 3 月 15 日起，Redis 的开发工作由 VMware 主持。从2013 年 5 月开始，Redis 的开发由 Pivotal 赞助。Redis 之所以称之为字典服务，是因为 Redis 是一个 key-value 存储系统。支持存储的 value类型很多，包括 String(字符串)、List(链表)、Set(集合)、Zset(sorted set --有序集合)和 Hash（哈希类型）等。

二、Redis 的用途

2.1 Redis 可以做什么？

1. 分布式缓存

Redis 在生产中使用最多的场景就是做数据缓存 。即客户端从 DBMS（数据库）中查询出的数据首先写入到 Redis 中，后续无论哪个客户端再需要访问该数据，直接读取 Redis 中的即可，不仅减小了 RT（响应时间），而且降低了 DBMS 的压力。

2. 内存存储和持久化（RDB+AOF）：Redis支持异步将内存中的数据写到硬盘上，同时不影响继续服务。

3. 高可用架构搭配：单机、主从、哨兵、集群

4. 分布式锁

5. 队列：消息队列系统可以说是一个大型网站的必备基础组件，因为其具有业务解耦、非实时业务削峰等特性。Redis提供了发布订阅功能和阻塞队列的功能，虽然和专业的消息队列比还不够足够强大，但是对于一般的消息队列功能基本可以满足。

6. 排行榜+点赞：排行榜系统几乎存在于所有的网站，例如按照热度排名的排行榜，按照发布时间的排行榜，按照各种复杂维度计算出的排行榜，Redis提供了列表和有序集合数据结构，合理地使用这些数据结构可以很方便地构建各种排行榜系统。

7. 计数器应用：计数器在网站中的作用至关重要，例如视频网站有播放数、电商网站有浏览数，为了保证数据的实时性，每一次播放和浏览都要做加1的操作，如果并发量很大对于传统关系型数据的性能是一种挑战。Redis天然支持计数功能而且计数的性能也非常好，可以说是计数器系统的重要选择。

8. 社交网络：赞/踩、粉丝、共同好友/喜好、推送、下拉刷新等是社交网站的必备功能，由于社交网站访问量通常比较大，而且传统的关系型数据不太适合保存这种类型的数据，Redis提供的数据结构可以相对比较容易地实现这些功能。

2.2 Redis 不可以做什么？

不建议大数据量的存储：站在数据规模的角度看，数据可以分为大规模数据和小规模数据，我们知道Redis的数据是存放在内存中的，虽然现在内存已经足够便宜，但是如果数据量非常大，例如每天有几亿的用户行为数据，使用Redis来存储的话，基本上是个无底洞，经济成本相当的高。
冷数据存储的浪费：站在数据冷热的角度看，数据分为热数据和冷数据，热数据通常是指需要频繁操作的数据，反之为冷数据，例如对于视频网站来说，视频基本信息基本上在各个业务线都是经常要操作的数据，而用户的观看记录不一定是经常需要访问的数据，这里暂且不讨论两者数据规模的差异，单纯站在数据冷热的角度上看，视频信息属于热数据，用户观看记录属于冷数据。如果将这些冷数据放在Redis中，基本上是对于内存的一种浪费，但是对于一些热数据可以放在Redis中加速读写，也可以减轻后端存储的负载，可以说是事半功倍。

2.3 用好 Redis 的建议

切勿当作黑盒使用，深入理解原理：开发与运维同样重要很多使用Redis的开发者认为只要会用API开发相应的功能就可以，更有甚者认为Redis就是get、set、del，不需要知道Redis的原理。但是在我们实际运维和使用Redis的过程中发现，很多线上的故障和问题都是由于完全把Redis当做黑盒造成的，如果不了解Redis的单线程模型，有些开发者会在有上千万个键的Redis上执行keys*操作，如果不了解持久化的相关原理，会在一个写操作量很大的Redis上配置自动保存RDB。而且在很多公司内只有专职的关系型数据库DBA，并没有NoSQL的相关运维人员，也就是说开发者很有可能会自己运维Redis，对于Redis的开发者来说既是好事又是坏事。站在好的方面看，开发人员可以通过运维Redis真正了解Redis的一些原理，不单纯停留在开发上。站在坏的方面看，Redis的开发人员不仅要支持开发，还要承担运维的责任，而且由于运维经验不足可能会造成线上故障。但是从实际经验来看，运维足够规模的Redis会对用好Redis更加有帮助。
阅读源码，便于定制化：我们在前面提到过，Redis是开源项目，由于作者对Redis代码的极致追求，Redis的代码量相对于许多NoSQL数据库来说是非常小的，也就意味着作为普通的开发和运维人员也是可以“吃透”Redis的。通过阅读优秀的源码，不仅能够加深我们对于Redis的理解，而且还能提高自身的编码水平，甚至可以对Redis做定制化，也就是说可以修改Redis的源码来满足自身的需求