【Redis初阶】(篇二）《一文吃透 Redis：特性、应用场景、版本演进与安装配置全解析》

一.了解 Redis

Redis 官网：Redis - Real-time data for agents & apps

Redis（Remote Dictionary Server）是一个开源的、基于内存的键值对（Key-Value）NoSQL 数据库。

在数据结构上，Redis 的 key 永远是 String 类型，而 value 支持极其丰富的数据结构，包括 String（字符串）、Hash（哈希）、List（列表）、Set（集合）、ZSet（有序集合），以及 Bitmaps（位图）、HyperLogLog（基数统计）、GEO（地理信息定位）和 Stream（消息流）。由于数据主要存储在内存中，Redis 的读写性能非常惊人，常被用作缓存、消息队列、分布式锁等。

在持久化方面，Redis 提供了 RDB（快照）和 AOF（日志）两种机制，将内存数据保存到硬盘上，从而在断电或故障时尽可能减少数据丢失（注意：无法保证 100% 不丢）。此外，Redis 还提供了键过期、发布订阅、事务、流水线（Pipeline）、Lua 脚本等附加功能，使其能适应非常广泛的业务场景。

小结：Redis 不仅是一个极快的 Key-Value 内存数据库，更是一个支持多种数据结构、具备持久化能力、附带丰富高级功能的全能型数据中间件。

【了解】

2008 年，Redis 的作者 Salvatore Sanfilippo（List of posts - <antirez>） 在开发⼀个叫 LLOOGG 的网站时，需要实现⼀个高性能的队列功能，最开始是使用 MySQL 来实现的，但后来发现无论怎么优化 SQL 语句等都不能使网站的性能提高上去，再加上自己囊中羞涩，于是他决定自己做⼀个专属于 LLOOGG 的数据库，这个就是 Redis 的前身。后来，Salvatore Sanfilippo 将 Redis 1.0 的源码发布到 Github 上，可能连他自己都没想到，Redis 后来如此受欢迎。

假如现在有人问 Redis 的作者都有谁在使用 Redis，我想他可以开句玩笑的回答：还有谁不使用 Redis，当然这只是开玩笑，但是从 Redis 的官方公司统计来看，有很多重量级的公司都在使用 Redis，如国外的 Twitter、Instagram、Stack Overflow、Github 等，国内就更多了，如果单单从体量来统计，新浪微博可以说是全球最大的 Redis 使用者，除了新浪微博，还有像阿里巴巴、腾讯、搜狐、优酷土豆、美团、小米、唯品会等公司都是 Redis 的使用者。除此之外，许多开源技术像 ELK 等已经把 Redis 作为它们组件中的重要一环，而且 Redis 还提供了模块系统让第三方人员实现功能扩展，让 Redis 发

二.Redis 的特性

1.速度快

正常情况下，Redis 执行命令的速度非常快（相较于 MySQL 这样的关系型数据库），官方给出的数字是读写性能可以达到 10 万/秒，当然这也取决于机器的性能。这里先不讨论机器性能上的差异，只分析是什么造就了 Redis 如此之快，可以归纳为以下四点：

（1）所有数据都在内存中。Redis 的数据通过键值对等数据结构存储在内存中。内存的访问速度是纳秒级（ns），而机械硬盘是毫秒级（ms），两者相差 10 万倍以上。这是 Redis 速度快的最主要原因。

（2）C 语言实现。Redis 是用 C 语言写的，C 语言让程序能够更精细地控制内存和系统调用。但需要纠正的是，C 语言并不是 Redis 快的根本原因——MySQL 也是 C/C++ 写的。C 语言只是提供了写出高性能代码的“基础”，而不是“原因”。

（3）单线程模型（核心命令执行）。Redis 使用单线程执行命令，避免了多线程的竞争开销和线程安全问题（加锁、阻塞、唤醒等）。多线程提高效率的前提是任务存在可并行处理的空间，且并行收益大于切换和锁的开销。而 Redis 的瓶颈不在 CPU，而在网络 I/O 和内存带宽，单核处理内存操作已经足够快，加多核反而会因为锁竞争而降低性能。（注：Redis 6.0 引入了多线程 I/O 处理网络读写，但核心命令执行仍是单线程。）

（4）精雕细琢的源码。Redis 的作者 Salvatore Sanfilippo 对源代码精打细磨，代码极简、高效、可读性强，曾被评价为“少有的集性能和优雅于一身的开源代码”。这也是很多开发者喜欢读 Redis 源码来学习系统编程的原因。

从网络的角度上，Redis 使用了 IO 多路复用的方式（epoll），也就是使用一个线程管理多个 socket。

谷歌公司给出的各层级硬件执行速度：

2.基于键值对的数据结构服务器

几乎所有的编程语言都提供了类似字典的功能，例如 C++ 里的map、Java 里的Map、Python 里的dict等。类似于这种组织数据的方式叫做基于键值对的方式。

与很多键值对数据库不同的是，Redis 中的值不仅可以是字符串，而且还可以是具体的数据结构，这样不仅能便于在许多应用场景的开发，同时也能提高开发效率。

Redis 的全称是REmote Dictionary Server（远程字典服务），它主要提供了5 种基础数据结构：

1. 字符串（string）

2. 哈希（hash）

3. 列表（list）

4. 集合（set）

5. 有序集合（ordered set / zset）

同时，在字符串的基础上还演变出了位图（Bitmaps）和HyperLogLog两种神奇的“数据结构”。随着 LBS（Location Based Service，基于位置服务）的不断发展，Redis 3.2 版本中加入了GEO（地理信息定位）的功能。Redis 5.0 更是引入了Stream（消息流），用于支持消息队列。总之，在这些数据结构的帮助下，开发者可以开发出各种“有意思”的应用。

3. 丰富的功能

Redis 除了核心的数据结构和高速读写外，还提供了以下五大附加功能，使其能适应更广泛的业务场景：

1. 键过期功能：可以为键设置 TTL（生存时间），到期自动删除。配合内存淘汰策略（如 LRU、LFU），这是实现缓存场景的基础。

2. 发布订阅（Pub/Sub）功能：支持消息的发布与订阅，可用于实现实时通知系统（如聊天室、配置推送）。但注意，Pub/Sub 消息不持久化，客户端断线会丢失消息，不适合做可靠消息队列。

3. Lua 脚本支持：允许在服务端执行 Lua 脚本，不仅能创造新的复合命令，更重要的是能保证多个命令的原子性执行，是实现分布式锁、库存扣减等复杂逻辑的关键。

4. 简单的事务功能：通过MULTI、EXEC等命令将一组命令打包执行。但需注意，Redis 事务不支持回滚，某条命令失败后其他命令仍会执行，它只保证“隔离性”（不被其他命令打断），不保证原子性。

5. 流水线（Pipeline）功能：客户端可以将一批命令一次性发送给 Redis，再一次性读取所有响应。这极大地减少了网络往返时间（RTT），提升了吞吐量。但 Pipeline 中的命令不保证原子性，中间可能插入其他客户端的命令。

4. 简单稳定

Redis 的简单主要表现在三个⽅⾯。

• ⾸先，Redis 的源码很少，早期版本的代码只有 2 万⾏左右，3.0 版本以后由于添加了集群特性，代码增⾄ 5 万⾏左右，相对于很多 NoSQL 数据库来说代码量相对要少很多，也就意味着普通的开发和运维⼈员完全可以 “吃透” 它。
• 其次，Redis 使⽤单线程模型，这样不仅使得 Redis 服务端处理模型变得简单，⽽且也使得客⼾端开发变得简单。
• 最后，Redis 不需要依赖于操作系统中的类库（例如 Memcache 需要依赖 libevent 这样的系统类库），Redis ⾃⼰实现了事件处理的相关功能。

但与简单相对的是 Redis 具备相当的稳定性，在⼤量使⽤过程中，很少出现因为 Redis ⾃⾝ BUG
⽽导致宕掉的情况。

5. 客户端语言多（扩展能力，Extensibility）

Redis 提供了简单的 TCP 通信协议，很多编程语⾔可以很⽅便地接⼊到 Redis，并且由于 Redis 受到社区和各⼤公司的⼴泛认可，所以⽀持 Redis 的客⼾端语⾔也⾮常多，⼏乎涵盖了主流的编程语⾔，例如 C、C++、Java、PHP、Python、NodeJS 等，后续我们会对 Redis 的客⼾端使⽤做详细说明。

可以在 Redis 原有的功能基础上再进行扩展，Redis 提供了一组 API。通过 C，C++，Rust 这几个语言编写 Redis 扩展（本质上就是一个动态链接库），让 Redis 支持更多的数据结构，以及支持更多的命令。

6.持久化（Persistence）

为了更快速地访问，Redis 把数据存储在内存上。通常来看，将数据放在内存中是不安全的（易失），一旦发生断电或者机器故障，重要的数据可能就会丢失。因此 Redis 提供了两种持久化方式：

1. RDB（Redis DataBase）：周期性将内存中的数据快照写入硬盘，生成一个二进制文件（dump.rdb）。

2. AOF（Append Only File）：以日志的形式记录每次写命令，重启时通过重放日志来恢复数据。

即我们可以用两种策略将内存的数据保存到硬盘中（内存为主、硬盘为辅，硬盘相当于对内存中的数据进行了备份），这样就尽可能地减少了数据丢失，提升了数据的持久性。

如果 Redis 重启，会在启动时加载硬盘中的备份数据：

• 如果同时开启了 RDB 和 AOF，优先加载 AOF（因为 AOF 通常更完整）。

• 如果只开启了 RDB，则加载 RDB 文件。

• 如果都关闭，则重启后数据为空。

注意：恢复的是最近一次持久化时的状态，而不是“重启前”的状态。重启前未持久化的数据会丢失。

此外，RDB 和 AOF可以同时开启。Redis 4.0 之后还引入了混合持久化（RDB + AOF 混合），兼顾了恢复速度和数据完整性。但持久化本身也有代价——RDB 的fork操作会短暂阻塞主线程，AOF 的刷盘会带来 I/O 压力，因此持久化策略需要根据业务场景权衡。

Redis 内存到硬盘的持久化：

7. 主从复制（Replication）

Redis 提供了复制功能，实现了多个相同数据的 Redis 副本（Replica），复制功能是分布式 Redis 的基础。

Redis 主从复制架构：

8. ⾼可⽤（High Availability）和分布式（Distributed）

Redis 的高可用和分布式能力是逐步演进的：

• 主从（Master-Replica）：基础的数据冗余机制。从节点是主节点的备份，但本身不提供高可用——主节点挂了，从节点不会自动顶上，需要人工介入。

• 哨兵（Redis Sentinel）：解决高可用问题。它监控主从节点，当主节点故障时自动进行故障转移，选举一个从节点升级为新主节点。

• 集群（Redis Cluster）：解决分布式问题。它把数据分片存储在多个节点上，每个节点只存一部分数据。集群本身内置了高可用能力（每个分片可以有从节点），所以集群 = 分布式 + 高可用。

9.可编程的 / 编程能力（Programmability）

针对 Redis 的操作，可以直接通过简单的交互式命令进行操作，也可以通过脚本的方式批量执行操作（可以带有逻辑）。这里的“脚本”主要指Lua 脚本（Redis 2.6 引入，核心价值是原子性和减少网络往返）和Redis Functions（Redis 7.0 引入，更现代的、可持久化的脚本管理方式）。此外，Redis 还支持通过模块（Modules）扩展底层功能，如 RedisSearch、RedisJSON 等。

10.集群（Clustering）

Redis 作为一个分布式系统的中间件，能够支持集群是非常关键的。

这个水平扩展类似于“分库分表”的思想，但 Redis Cluster 是通过哈希槽（Hash Slot）来实现的——一共 16384 个槽，每个节点负责一部分槽位。一个 Redis 能够存储的数据是有限的（内存空间有限），如果想存储更多的数据，就需要引入多个主机，部署多个 Redis 节点，每个 Redis 存储数据的一部分。

补充：Redis Cluster 不仅解决了容量扩展问题，还提供了高可用（每个分片可以有从节点，主节点故障时自动切换）和读写扩展（读请求可以分散到从节点）。但客户端的用法也不同——需要使用支持集群协议的客户端（如 JedisCluster、Lettuce）。

三.Redis 的主要应用场景

要充分理解 Redis 的作⽤，需要读者对⽹站的架构有⼀定的基础理解，考虑到部分读者缺少这⽅
⾯的背景知识，建议先移步为⼤家准备的 【Redis】服务端高并发分布式结构演进之路-CSDN博客篇对该领域的基础知识做⼀定学习后，再度继续本篇的学习。

1.Redis 可以做什么

（1）缓存（Cache）& 会话（Session）

缓存机制⼏乎在所有⼤型⽹站都有使⽤，合理地使⽤缓存不仅可以加速数据的访问速度，⽽且能
够有效地降低后端数据源的压⼒。Redis 提供了键值过期时间设置，并且也提供了灵活控制最⼤内存和内存溢出后的淘汰策略。可以这么说，⼀个合理的缓存设计能够为⼀个⽹站的稳定保驾护航。

我们在 Linux 的学习中，我们了解了cookie 可以实现用户身份信息的保存（只是在浏览器这边存储了用户的身份标识 sessionId），但同时这是需要 session 配合（服务器这时才真正的存储了用户数据）。

之前 session 是存储在应用服务器上的，现在变成了分布式系统，引入了负载均衡：

如何解决上述问题？

1. 我们想办法让负载均衡器把同一个用户的请求始终打到同一个机器上（不再采用轮询了，而是要通过userId 之类的方式来分配机器）。
2. 我们把会话数据单独拎出来，放到一组独立的机器上进行存储（Redis，把应用程序重启了，会话也不会丢失，就算丢失了大不了让用户重新进行登录）。

（2）排行榜系统

排⾏榜系统⼏乎存在于所有的⽹站，例如按照热度排名的排⾏榜，按照发布时间的排⾏榜，按照
各种复杂维度计算出的排⾏榜，Redis 提供了列表和有序集合的结构，合理地使⽤这些数据结构可以很⽅便地构建各种排⾏榜系统。

（3） 计数器应用

计数器在⽹站中的作⽤⾄关重要，例如视频⽹站有播放数、电商⽹站有浏览数，为了保证数据的
实时性，每⼀次播放和浏览都要做加 1 的操作，如果并发量很⼤对于传统关系型数据的性能是⼀种挑战。Redis 天然⽀持计数功能⽽且计数的性能也⾮常好，可以说是计数器系统的重要选择。

（4）社交网络

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

（5)消息队列系统

消息队列系统可以说是一个大型网站的必备基础组件，因为其具有业务解耦、非实时业务削峰等特性。基于这个可以实现一个网络版本的生产者消费者模型。对于分布式系统来说，服务器和服务器之间有时候也需要使用到生产者消费者模型。

核心优势：

• 解耦合：生产者和消费者不直接依赖，通过 MQ 通信。

• 削峰填谷：流量突增时，MQ 作为缓冲池，保护下游系统。

• 异步处理：非核心链路异步化，缩短主流程响应时间。

• 广播：一条消息可以被多个消费者订阅。

• 最终一致性：配合事务消息，实现分布式系统的最终一致性。

业界也有很多知名的消息队列，例如：RabbitMQ、Kafka、RocketMQ等。

Redis 提供了发布订阅（Pub/Sub）功能和阻塞队列（List）的功能，虽然和专业消息队列比还不够足够强大，但是对于一般的消息队列功能基本可以满足。

2. Redis 不可以做什么

实际上和任何⼀⻔技术⼀样，每个技术都有⾃⼰的应⽤场景和边界，也就是说 Redis 并不是万⾦
油，有很多合适它解决的问题，但是也有很多不合适它解决的问题。我们可以站在数据规模和数据冷热的⻆度来进⾏分析。

站在数据规模的⻆度看，数据可以分为⼤规模数据和⼩规模数据，我们知道 Redis 的数据是存放
在内存中的，虽然现在内存已经⾜够便宜，但是如果数据量⾮常⼤，例如每天有⼏亿的⽤⼾⾏为数
据，使⽤ Redis 来存储的话，基本上是个⽆底洞，经济成本相当⾼。

站在数据冷热的⻆度，数据分为热数据和冷数据，热数据通常是指需要频繁操作的数据，反之为
冷数据，例如对于视频⽹站来说，视频基本信息基本上在各个业务线都是经常要操作的数据，⽽⽤⼾的观看记录不⼀定是经常需要访问的数据，这⾥暂且不讨论两者数据规模的差异，单纯站在数据冷热的⻆度上看，视频信息属于热数据，⽤⼾观看记录属于冷数据。如果将这些冷数据放在 Redis 上，基本上是对于内存的⼀种浪费，但是对于⼀些热数据可以放在 Redis 中加速读写，也可以减轻后端存储的负载，可以说是事半功倍。所以，Redis 并不是万⾦油，相信随着我们对 Redis 的逐步学习，能够清楚 Redis 真正的使⽤场景。

四.Redis 重大版本

Redis 借鉴了 Linux 操作系统对于版本号的命名规则：版本号第⼆位如果是奇数，则为⾮稳定版本（例如 2.7、2.9、3.1），如果是偶数，则为稳定版本（例如 2.6、2.8、3.0、3.2）。当前奇数版本就是下⼀个稳定版本的开发版本，例如 2.9 版本是 3.0 版本的开发版本。所以我们⽣产环境通常选取偶数版本的 Redis，如果对于某些新的特性想提前了解和使⽤，可以选择最新的奇数版本。⽬前最新的版本是 7.0 版本。本⼩节将对 Redis 发展过程中的⼀些重要版本及特性进⾏说明。

1.Redis 2.6

Redis 2.6 在 2012 年正式发布，相比于 Redis 2.4，主要特性如下：

• 服务端支持 Lua 脚本。
• 去掉虚拟内存相关功能。
• 放开对客户端连接数的硬编码限制。
• 键的过期时间支持毫秒。
• 从节点提供只读功能。
• 两个新的位图命令：bitcount和bitop。
• 增强了redis-benchmark的功能：支持定制化的压测、CSV 格式输出等功能。
• 基于浮点数的自增命令：incrbyfloat和hincrbyfloat。
• redis-cli可以使用--eval参数执行 Lua 脚本。
• shutdown命令增强。
• info可以按照 section 输出，并且添加了一些统计项。
• 重构了大量核心代码；当时所有集群相关的代码都被移除，Cluster 功能改由 3.0 支持。

• sort命令优化。

2.Redis 2.8

Redis 2.8 在 2013 年正式发布，相比于 Redis 2.6，主要特性如下：

• 引入部分重同步（PSYNC）功能，在一定程度上降低了因网络问题频繁触发全量复制、生成 RDB 而对系统造成的压力。
• 尝试性地支持 IPv6。
• 可以通过config set命令设置maxclients。
• 可以用bind命令绑定多个 IP 地址。
• Redis 设置了明显的进程名，方便使用ps命令查看系统进程。
• config rewrite命令可以将config set的修改持久化到 Redis 配置文件中。
• 发布订阅添加了pubsub命令。
• Redis Sentinel 第二版：相比于 Redis 2.6 的 Sentinel，此版本已经达到生产可用。

3.Redis 3.0

Redis 3.0 在 2015 年正式发布，相比于 Redis 2.8，主要特性如下：

• Redis Cluster：Redis 提供的官方分布式实现。
• 全新的 embedded string 对象编码结构，优化了小对象的内存访问，在特定工作负载下访问速度大幅提高。
• 优化了 LRU 算法，性能大幅提升。
• migrate连接缓存，大幅提升键迁移的速度。
• migrate命令新增两个参数：copy和replace。
• client pause命令，可在指定时间内暂停处理客户端请求。
• bitcount命令性能提升。
• config set设置maxmemory时能够使用不同的单位（以前只能是字节）。
• Redis 日志小做调整：日志中会反映当前实例的角色（master 或 slave）。
• incr命令性能提升。

4.Redis 3.2

Redis 3.2 在 2016 年正式发布，相比于 Redis 3.0，主要特性如下：

• 添加 GEO 相关功能。
• SDS 在速度和节省空间上都做了优化。
• 支持用 upstart 或 systemd 管理 Redis 进程。
• 新的 List 编码类型：quicklist。
• 从节点读取过期数据，保证一致性。
• 添加了hstrlen命令。
• 加强了debug命令，支持了更多的参数。
• Lua 脚本功能加强。
• 添加了 Lua Debugger。
• config set支持更多的配置参数。
• 优化了 Redis 崩溃后的相关报告。
• 新的 RDB 格式，但仍然兼容旧的 RDB。
• 加速 RDB 的加载速度。
• spop命令支持个数参数。
• cluster nodes命令获得加速。
• Jemalloc 更新到 4.0.3 版本。

5.edis 4.0

Redis 4.0 在 2017 年正式发布，相比于 Redis 3.2，主要特性如下：

• 提供了模块系统（module），方便第三方开发者扩展 Redis 的功能。
• PSYNC 2.0：优化了以前版本中，主从故障切换（failover）时必然引发全量复制的问题。
• 提供了新的缓存淘汰算法 LFU（Least Frequently Used，最不经常使用）。注意 LFU 和 LRU 的不同：LRU 基于访问时间淘汰，LFU 基于访问次数淘汰，并对已有算法进行了优化。
• 提供了非阻塞的del和flushall/flushdb功能，新增了unlink命令——它是del命令的异步版本，可将删除指定键的操作放到后台线程中执行。
• 提供了memory命令，实现对内存更全面的监控统计。
• 提供了交换数据库功能（SWAPDB），实现 Redis 内部两个数据库的数据互换。
• 提供了 RDB-AOF 混合持久化格式，充分利用了 AOF 和 RDB 各自的优点。
• Redis Cluster 兼容 NAT 和 Docker。

6.Redis 5.0

Redis 5.0 在 2018 年正式发布，相比于 Redis 4.0，主要特性如下：

• 新的流数据类型 stream。
• 新的 Redis 模块 API：定时器、集群和字典 API。
• RDB 现在可存储 LFU 和 LRU 信息。
• redis-cli中的集群管理器从 Ruby（redis-trib.rb）移植到了 C 语言实现。执行redis-cli --cluster help命令可了解更多信息。
• 新的有序集合（sorted set）命令：zpopmin/zpopmax及其阻塞变体（blocking variants）。
• 将 Active defragmentation 升级至 v2 版本。
• 增强 HyperLogLog 的实现。
• 更好的内存统计报告。
• 许多包含子命令的命令现在都有一个help子命令。
• 客户端频繁连接和断开连接时，性能表现更好。
• 许多错误修复和其他方面的改进。
• 升级 Jemalloc 至 5.1 版本。
• 引入client unblock和client id。
• 新增lolwut命令。
• 在不存在需要保持向后兼容性的地方，弃用 "slave" 术语。
• 网络层中的差异优化。
• 增强对 Lua 的支持：将 Lua 脚本更好地传播到 replicas / AOF；Lua 脚本现在可以超时，并在副本中进入-BUSY状态。
• 引入动态的 HZ（Dynamic HZ）以平衡空闲 CPU 使用率和响应性。
• 对 Redis 核心代码进行了重构，并在许多方面进行了改进。

7.Redis 6.0

Redis 6.0 在 2020 年正式发布，相比于 Redis 5.0，主要特性如下：

• 引入多线程 IO，但多线程部分只用于处理网络数据的读写和协议解析，执行命令仍然是单线程。
• 实现了 client-side-caching（客户端缓存）功能：放弃了 caching slot，而只使用 key names。
• 开始在兼容 RESP 2 的基础上，支持 RESP 3（RESP，Redis Serialization Protocol，是 Redis 服务端与客户端之间的通信协议）。
• 连接支持 SSL，更加安全。
• 增强 ACL 权限控制：支持对客户端的权限控制，可对不同 key 授予不同操作权限；新增 ACL 日志命令，允许查看所有违反 ACL 的客户端、访问不应访问的命令、访问不应访问的 key，或验证尝试失败的记录——这对调试 ACL 问题非常有用。
• 提升了 RDB 日志加载速度。
• 发布官方的 Redis 集群代理模块 Redis Cluster Proxy。
• 提供了众多新的模块（modules）API。

8.Redis 7.0

Redis 7.0 在 2022 年正式发布，相比于 Redis 6.0，主要特性如下：

• 将 AOF 文件的存储方式改为在一个文件夹下存储多个文件（multi-part AOF）。
• 将持久化文件 RDB 的版本升级为 10，与之前的 RDB 文件版本不再兼容。
• 在读取旧的 RDB 文件格式时，会将 ziplist 转换为 listpack；这种转换发生在两种情况：从磁盘读取文件，或从主节点复制文件时。
• 在redis.conf配置文件中，protected-mode默认改为 yes；只有当你希望客户端在无授权的情况下也能连接 Redis server 时，才将protected-mode设置为 no。
• 在 ACL 中，pub / sub channel 默认是被阻塞的。
• 在从节点中，TTL 的时间标识的是绝对时间，不再是相对时间，从而保证过期数据被及时删除。
• 不再支持 gopher 协议。
• 当在配置文件中设置replica-serve-stale-data=no时，若主节点不再提供服务，副本会拒绝包括ping在内的所有命令，以避免返回过期数据。

五.安装并启动 Redis

上面，我们⼤致了解了 Redis 的⼏个重⼤版本，我们在本教程中选择 5.0 版本，原因是 5.0 已经
⽀持了⼤部分的功能特性，⽽且相⽐较于 7.0 版本，更容易进⾏安装使⽤。

Redis 的官⽅并不⽀持微软的 Windows 操作系统，因为 Redis 的许多特性都是和操作系统相
关的，所以⽀持 Windows 会增加维护成本，⽽且更重要的是⼤部分公司都在使⽤ Linux 操作
系统，⽽ Redis 在 Linux 操作系统上的表现已经得到实践的证明。当然 Redis 作为⼀款优秀
的开源技术，还是吸引到微软公司的注意，微软公司的开源技术组在 Github 上维护了⼀个
Redis 分⽀：https://github.com/MSOpenTech/redis不过我们还是强烈建议⼤家在 Linux
上使⽤ Redis。

可参考：【Redis初阶】(篇一）《小白也能轻松上手，用ubuntu22.04搭建redis环境》---详解-CSDN博客

六.Redis 重要文件及作用

1.启动/停⽌命令或脚本

/usr/bin/redis-benchmark /usr/bin/redis-check-aof -> /usr/bin/redis-server /usr/bin/redis-check-rdb -> /usr/bin/redis-server /usr/bin/redis-cli /usr/bin/redis-sentinel -> /usr/bin/redis-server /usr/bin/redis-server /usr/libexec/redis-shutdown

redis-server 是 Redis 服务器程序，其余的⼏个例如：redis-check-aof、redis-check-rdb、redis-
sentinel 也都是 redis-server 的软链接。redis-check-aof 是修复 AOF ⽂件⽤的⼯具，同理 redis-
check-rdb 是修复 RDB ⽂件的⼯具，redis-sentinel 是 Redis 哨兵程序。
redis-cli 是在我们学习阶段需要频繁⽤到的⼀个命令⾏客⼾端程序，随后做介绍。
redis-benchmark ⽤于对 Redis 做性能基准测试的⼯具。
redis-shutdown 是⽤于停⽌ Redis 的专⽤脚本。

其实相比较直接使用这些命令，更建议使用前面讲过的，systemd 托管的方式来进行 Redis 的启动 / 停止。

2.配置⽂件

/etc/redis-sentinel.conf /etc/redis.conf

/etc/redis.conf 是 Redis 服务器的配置⽂件。

/etc/redis-sentinel.conf 是 Redis Sentinel 的配置⽂
件。

3.持久化文件存储目录

/var/lib/redis/

Redis 持久化⽣产的 RDB 和 AOF ⽂件都默认⽣成于该⽬录下。后边章节我们讲到持久化时会观察
这边持久化的⼀些现象。

4.日志文件目录

/var/log/redis/

/var/log/redis/ ⽬录下会保存 Redis 运⾏期间⽣产的⽇志⽂件，默认按照天进⾏分割，并且会将
⼀定⽇期的⽇⼦⽂件使⽤ gzip 格式压缩保存。可以使⽤任意⽂本编辑器打开，后边章节我们会通过⽇志来观察⼀些现象。

5.Redis 命令行客户端

现在已经启动了 Redis 服务，下面将介绍如何使用 redis-cli 连接、操作 Redis 服务。客户端和服务端的交互过程如下图所示。

redis-cli 可以使用以下两种方式连接 Redis 服务器。

第⼀种是交互式⽅式：

通过redis-cli -h { host } -p { port }的⽅式连接到 Redis 服务，后续所有的操作都是通过交互式的⽅式实现，不需要再执⾏ redis-cli 了，例如

第⼆种是命令⽅式：

⽤redis-cli -h { host } -p { port } { command } 就可以直接得到命令的返回结果，例如：

这⾥有两点要注意：

• (1）由于我们连接的 Redis 服务位于 127.0.0.1，端⼝也使⽤的是默认的 6379端⼝，所以可以省略 -h { host } -p { port }。
• (2）Redis 是学习 Redis 的重要⼯具，后续的⼤量章节都是⽤它来做讲解。

有关 redis-cli 提供的更为强⼤的功能将在后续章节做详细介绍。

Redis 客⼾端与服务端的交互过程