【Redis篇】初识 Redis：特性、应用场景与版本演进

文章目录

- [初识 Redis：特性、应用场景与版本演进](#初识 Redis：特性、应用场景与版本演进)
- 一、前言
- [二、Redis 是什么](#二、Redis 是什么)
- - [2.1 一定义](#2.1 一定义)
  - [2.2 Redis 和普通键值数据库的区别](#2.2 Redis 和普通键值数据库的区别)
  - [2.3 Redis 的诞生故事](#2.3 Redis 的诞生故事)
- [三、Redis 的 8 大核心特性](#三、Redis 的 8 大核心特性)
- - [3.1 速度快](#3.1 速度快)
  - [3.2 丰富的数据结构](#3.2 丰富的数据结构)
  - [3.3 丰富的附加功能](#3.3 丰富的附加功能)
  - [3.4 简单稳定](#3.4 简单稳定)
  - [3.5 客户端语言多](#3.5 客户端语言多)
  - [3.6 持久化（Persistence）](#3.6 持久化（Persistence）)
  - [3.7 主从复制（Replication）](#3.7 主从复制（Replication）)
  - [3.8 高可用与分布式](#3.8 高可用与分布式)
- [四、Redis 的应用场景](#四、Redis 的应用场景)
- - [4.1 Redis 适合做什么](#4.1 Redis 适合做什么)
  - [4.2 Redis 不适合做什么](#4.2 Redis 不适合做什么)
- [五、Redis 的重大版本演进](#五、Redis 的重大版本演进)
- - [5.1 Redis 2.6（2012年）](#5.1 Redis 2.6（2012年）)
  - [5.2 Redis 2.8（2013年）](#5.2 Redis 2.8（2013年）)
  - [5.3 Redis 3.0（2015年）](#5.3 Redis 3.0（2015年）)
  - [5.4 Redis 3.2（2016年）](#5.4 Redis 3.2（2016年）)
  - [5.5 Redis 4.0（2017年）](#5.5 Redis 4.0（2017年）)
  - [5.6 Redis 5.0（2018年）](#5.6 Redis 5.0（2018年）)
  - [5.7 Redis 6.0（2020年）](#5.7 Redis 6.0（2020年）)
  - [5.8 Redis 7.0（2022年）](#5.8 Redis 7.0（2022年）)
- 六、总结
- - [6.1 快速记忆表](#6.1 快速记忆表)

初识 Redis：特性、应用场景与版本演进

一、前言

💬 这一篇讲什么：正式认识 Redis，搞清楚它是什么、能做什么、不能做什么

🚀 核心内容：

Redis 是什么？它和普通数据库有什么区别？

Redis 的 8 大核心特性是什么？

Redis 适合哪些应用场景？哪些场景不适合用它？

Redis 从 2.6 到 7.0 经历了哪些重要版本？

上一篇我们讲了分布式架构的演进之路，知道了 Redis 是在"热点数据反复查数据库"这个瓶颈下被引入的。这一篇正式认识 Redis 本身：它到底是什么，凭什么能做到这些，以及它的边界在哪里。

二、Redis 是什么

2.1 一定义

Redis 全称 REmote Dictionary Server，直译过来是"远程字典服务器"。它是一种基于**键值对（key-value）**的 NoSQL 数据库。

如果你用过 C++ 里的 map、Python 里的 dict，就已经理解了键值对的核心思想：通过一个 key 快速找到对应的 value。Redis 做的事情本质上和这些数据结构一样，只不过它运行在独立的服务器进程上，可以被多个程序通过网络共享访问。

2.2 Redis 和普通键值数据库的区别

很多数据库也支持键值对，但 Redis 特别的地方在于：value 不只是简单的字符串，而是可以是多种丰富的数据结构。

Redis 原生支持以下数据类型：

类型	说明	类比
string（字符串）	最基础的类型，可以存文本、数字、二进制	C++ 的 `string`
hash（哈希）	键值对的集合，适合存对象	C++ 的 `unordered_map`
list（列表）	有序的字符串列表，支持两端操作	C++ 的 `deque`
set（集合）	无序、不重复的字符串集合	C++ 的 `unordered_set`
zset（有序集合）	每个元素关联一个分数，按分数排序	C++ 中没有直接对应

除了这五种核心类型，Redis 还在字符串基础上衍生出了 Bitmaps（位图） 和 HyperLogLog 两种特殊结构，以及 Redis 3.2 之后加入的 GEO（地理信息定位） 功能。

正是这些丰富的数据结构，让 Redis 能够应对远比"存个字符串"复杂得多的业务场景。

2.3 Redis 的诞生故事

2008 年，Redis 的作者 Salvatore Sanfilippo 在开发一个叫 LLOOGG 的网站时，需要实现一个高性能的队列功能。他最开始用 MySQL 来做，但无论怎么优化 SQL 都达不到性能要求。囊中羞涩又不甘心放弃，他干脆自己写了一个专属的数据库，这就是 Redis 的前身。

后来他将 Redis 1.0 的源码发布到 GitHub 上，可能连他自己都没料到，Redis 后来会成为全球使用最广泛的中间件之一。Twitter、Instagram、Stack Overflow、GitHub，国内的新浪微博、阿里巴巴、腾讯、美团、小米......可以说，几乎所有的互联网公司都在用 Redis。新浪微博更是被称为全球最大的 Redis 使用者。

三、Redis 的 8 大核心特性

3.1 速度快

Redis 官方给出的读写性能数据是 10 万次/秒，这个数字是怎么来的？主要有四个原因：

原因一：数据全部存在内存中。 这是最根本的原因。内存的读写速度比磁盘快几个数量级，下面这张谷歌给出的硬件速度对比表能直观感受到差距：

把数据放在内存里，就是 Redis 快的核心原因。

原因二：用 C 语言实现。 C 语言离操作系统更近，执行效率天然更高。

原因三：单线程模型处理命令。 不需要处理多线程的锁竞争和上下文切换开销，逻辑简洁，命令执行串行化，也避免了并发带来的数据安全问题。

注意：Redis 6.0 之后引入了多线程，但多线程只用于处理网络 IO 和协议解析，命令的实际执行依然是单线程。所以说 Redis 是单线程模型，本质上是正确的。

原因四：代码极度精简优雅。 Redis 早期版本只有约 2 万行代码，作者对每一行代码都做了极致优化，曾被评价为"少有的集性能和优雅于一身的开源代码"。

3.2 丰富的数据结构

如 2.2 节所述，Redis 支持 string、hash、list、set、zset 五种核心数据结构，以及 Bitmaps、HyperLogLog、GEO 等扩展类型。不同的数据结构对应不同的业务场景，这是 Redis 能覆盖如此多应用场景的根本原因。后续的文章会对每种数据类型做深度讲解。

3.3 丰富的附加功能

除了数据结构本身，Redis 还提供了一批非常实用的附加功能：

键过期（TTL）：可以给 key 设置过期时间，过期后自动删除，非常适合实现缓存。
发布订阅（Pub/Sub）：可以用来构建简单的消息系统。
Lua 脚本：支持在服务端执行 Lua 脚本，可以原子化地执行一批复杂操作，甚至可以创造出新的 Redis 命令。
事务：提供了基本的事务功能，能在一定程度上保证操作的原子性。
流水线（Pipeline）：客户端可以把一批命令打包一次性发给 Redis，减少网络往返开销，大幅提升批量操作的吞吐量。

3.4 简单稳定

Redis 的简单体现在三个方面：

代码量少：早期版本只有约 2 万行代码，3.0 之后加入集群特性增至约 5 万行，相比其他 NoSQL 数据库仍然非常精简，普通开发者完全可以啃透源码。

单线程模型：服务端处理逻辑清晰，客户端开发也变得简单，不需要考虑复杂的并发问题。

无外部依赖：Redis 自己实现了事件处理相关功能，不依赖 libevent 等系统类库（Memcached 就依赖 libevent），安装部署非常简洁。

与此同时，Redis 具备相当高的稳定性，在大量生产实践中，很少出现因 Redis 自身 bug 导致宕机的情况。

3.5 客户端语言多

Redis 使用简单的 TCP 通信协议，几乎所有主流编程语言都有对应的客户端库，包括 C、C++、Java、Python、Go、PHP、NodeJS 等。这意味着无论你用什么技术栈，都可以很方便地接入 Redis。

3.6 持久化（Persistence）

把数据放在内存里速度很快，但内存有一个致命缺点：断电即失。一旦服务器重启或发生故障，内存中的数据就会全部消失。

为了解决这个问题，Redis 提供了两种持久化方式：

RDB（快照） ：按照一定的时间间隔，把内存中的数据以快照形式保存到磁盘上的 .rdb 文件。

AOF（追加日志） ：把每一条写命令追加记录到 .aof 日志文件中。发生故障时，通过重放日志文件中的命令来恢复数据。

这两种方式各有优缺点，可以单独使用，也可以结合使用。后续会有专门一篇文章深入讲解持久化机制。

3.7 主从复制（Replication）

Redis 提供了主从复制功能：一台主节点（Master）可以同步数据到多台从节点（Slave），形成多个相同数据的副本。

text 复制代码

[主节点 Master]
      │
      ├──复制──→ [从节点 Slave 1]
      ├──复制──→ [从节点 Slave 2]
      └──复制──→ [从节点 Slave 3]

主从复制是 Redis 实现读写分离和高可用的基础，后续讲主从复制和哨兵时会详细展开。

3.8 高可用与分布式

Redis Sentinel（哨兵）：监控主从节点的运行状态，当主节点发生故障时，自动将某台从节点提升为新的主节点，实现故障的自动检测和转移，保证系统的高可用。

Redis Cluster（集群）：Redis 官方提供的分布式实现方案，支持数据分片存储在多台节点上，同时提供高可用、读写扩展和容量扩展能力，是真正意义上的分布式 Redis。

这两块内容后续都有专篇讲解，这里先有个印象。

四、Redis 的应用场景

4.1 Redis 适合做什么

缓存（Cache）

这是 Redis 最核心、最广泛的使用场景。把频繁访问但不常变化的数据存入 Redis，请求优先从 Redis 读取，命中则直接返回，不命中再去数据库查并回填缓存。

合理的缓存设计能让系统的响应速度提升数十倍，同时大幅降低数据库的压力。几乎所有的大型网站都在用 Redis 做缓存。

排行榜系统

排行榜是互联网产品的标配功能------热度排行、销量排行、积分排行......Redis 的有序集合（zset）天然支持按分数排序，插入、删除、查询指定排名都是 O(log N) 的时间复杂度，用来实现各种维度的排行榜非常方便。

计数器应用

视频播放量、文章阅读数、商品浏览次数------这些计数场景要求每次操作都能实时更新，并发量大时对关系型数据库的写入性能是很大的挑战。Redis 的 INCR 命令原子化地对数字执行加一操作，既快又安全，是计数场景的最佳选择。

社交网络

点赞/踩、关注/粉丝、共同好友、推送、下拉刷新......社交网站的这些功能访问量大、数据关系复杂，传统关系型数据库不太适合存储这类数据，而 Redis 的 set、zset、hash 等数据结构可以相对优雅地实现这些功能。

消息队列系统

消息队列是大型系统的必备组件，用于业务解耦和流量削峰。Redis 提供了 list 的阻塞弹出命令（BLPOP/BRPOP）和发布订阅（Pub/Sub）功能，可以实现简单的消息队列。虽然和 Kafka、RabbitMQ 这类专业消息队列相比还有差距，但对于轻量级场景已经完全够用。

4.2 Redis 不适合做什么

Redis 不是万能的，理解它的边界同样重要。

不适合存储大规模冷数据。 Redis 的数据存储在内存中，内存成本远高于磁盘。如果把海量冷数据（比如每天几亿条用户行为日志）都放进 Redis，成本是个无底洞。冷数据应该存在磁盘型数据库（MySQL、MongoDB 等）中。

不适合存储结构极其复杂的关系型数据。 如果业务涉及大量复杂的多表 JOIN、事务要求严格，还是老老实实用 MySQL 等关系型数据库。Redis 的事务功能相对简单，不支持回滚。

一句话总结：Redis 是热数据的加速器，不是数据的终极存储地。 用对了场景，它就是把瑞士军刀；用错了场景，它只是在浪费昂贵的内存资源。

五、Redis 的重大版本演进

Redis 的版本命名借鉴了 Linux 的规则：版本号第二位是偶数为稳定版 （如 2.6、2.8、3.0），奇数为开发版（如 2.7、2.9、3.1）。生产环境应始终选择偶数版本。

5.1 Redis 2.6（2012年）

Redis 正式走向成熟的起点，主要带来了：

服务端支持 Lua 脚本执行，可以把一批操作原子化。
键的过期时间精度支持到毫秒级。
从节点提供只读功能。
新增位图命令 BITCOUNT 和 BITOP。
新增浮点数自增命令 INCRBYFLOAT / HINCRBYFLOAT。

5.2 Redis 2.8（2013年）

主要改进了主从复制的稳定性：

引入部分主从复制，网络短暂断开后无需全量重新同步，大幅降低了全量复制对系统的冲击。
Redis Sentinel 第二版正式可用于生产环境，实现了主节点的故障自动转移。

5.3 Redis 3.0（2015年）

Redis 历史上最重要的版本，核心亮点只有一个：

Redis Cluster 正式发布，Redis 终于有了官方的分布式实现，可以将数据自动分片存储在多台节点上，支持水平扩展。

5.4 Redis 3.2（2016年）

新增 GEO 地理信息相关命令，可以存储经纬度坐标、计算两点距离、查找附近的元素。
新增 List 的 quicklist 编码类型，同时优化了内存和性能。

5.5 Redis 4.0（2017年）

引入模块系统（Module），允许第三方开发者用 C 语言编写扩展模块，极大地扩展了 Redis 的能力边界。
新增 LFU（Least Frequently Used） 淘汰算法，在 LRU 基础上，改用访问频率来判断数据冷热，淘汰决策更精准。
新增 UNLINK 命令，异步删除 key，避免大 key 删除时阻塞主线程。
提供 RDB-AOF 混合持久化格式，兼顾了两种方式各自的优点。

5.6 Redis 5.0（2018年）

新增 Stream 流数据类型，支持消息持久化和消费者组，Redis 的消息队列能力大幅增强，是一个类似 Kafka 的轻量级消息流解决方案。
ZPOPMIN / ZPOPMAX 命令及其阻塞变体正式加入有序集合命令家族。

5.7 Redis 6.0（2020年）

引入多线程 IO处理网络读写和协议解析，显著提升了高并发下的吞吐量（命令执行仍为单线程）。
支持 SSL 加密连接，生产环境安全性大幅提升。
增强 ACL 权限控制，可以对不同客户端授予不同 key 的操作权限。
推出官方 Redis Cluster Proxy，简化了客户端接入集群的方式。

5.8 Redis 7.0（2022年）

AOF 存储方式改为在一个文件夹下存储多个子文件，避免单个 AOF 文件过大的问题。
RDB 版本升级至 10，与旧版本 RDB 文件不再兼容。
从节点的 TTL 时间标识改为绝对时间（而非相对时间），保证过期数据能被及时清理，数据一致性更好。
protected-mode 默认改为 yes，安全性更强。

六、总结

现在你已经掌握了：

✅ Redis 是什么：基于键值对的内存数据库，value 支持丰富的数据结构

✅ Redis 为什么快：内存存储 + C 语言实现 + 单线程命令执行 + 精简代码

✅ 8 大核心特性：速度快、丰富数据结构、丰富功能、简单稳定、多语言客户端、持久化、主从复制、高可用与分布式

✅ 适合的场景：缓存、排行榜、计数器、社交网络、消息队列

✅ 不适合的场景：大规模冷数据存储、复杂关系型数据

✅ 版本演进脉络：2.6稳定 → 2.8主从优化 → 3.0集群 → 4.0模块化 → 5.0 Stream → 6.0多线程IO → 7.0

6.1 快速记忆表

版本	最重要的事
2.6	Lua 脚本、毫秒过期
2.8	部分复制、Sentinel 生产可用
3.0	Redis Cluster 发布
3.2	GEO 地理信息
4.0	模块系统、LFU、混合持久化
5.0	Stream 流数据类型
6.0	多线程 IO、SSL、ACL
7.0	AOF 多文件、TTL 绝对时间

下一篇预告：Redis 的安装与启动 ------ 在 Ubuntu 和 CentOS 上安装 Redis，了解重要的配置文件和目录，并用 redis-cli 发出第一条命令。