目录
[一、Redis 重要文件及作用](#一、Redis 重要文件及作用)
[二、Redis 命令行客户端（redis-cli）](#二、Redis 命令行客户端（redis-cli）)
[连接 Redis 服务器](#连接 Redis 服务器)
[三、Redis 客户端形态全景](#三、Redis 客户端形态全景)
1、命令行客户端（redis-cli）【教学核心工具】（上面第二点这种）
[四、Redis vs 内存HashMap的性能权衡](#四、Redis vs 内存HashMap的性能权衡)
[1. Redis适用场景检查表](#1. Redis适用场景检查表)
[2. 反模式警示](#2. 反模式警示)
[1、Redis 的 8 大特性](#1、Redis 的 8 大特性)
[2、Redis 的适用场景](#2、Redis 的适用场景)
一、Redis 重要文件及作用
1、启动/停止命令与脚本
以下是 Redis 安装后常见的可执行文件，它们大多位于 /usr/bin 目录下：
/usr/bin/redis-benchmark：用于对 Redis 进行性能基准测试的工具。通过模拟多个客户端并发访问，可评估 Redis 在不同配置下的吞吐量和响应时间。
/usr/bin/redis-check-aof → /usr/bin/redis-server：修复 AOF（Append-Only File）持久化文件的工具。AOF 文件记录了所有写操作命令，若文件损坏，可通过此工具修复。
/usr/bin/redis-check-rdb → /usr/bin/redis-server：修复 RDB（Redis Database）持久化文件的工具。RDB 是 Redis 的快照文件，此工具可修复损坏的快照。
/usr/bin/redis-cli：Redis 命令行客户端程序，是学习阶段最常用的工具。通过它可与 Redis 服务器交互，执行命令、调试问题。
/usr/bin/redis-sentinel → /usr/bin/redis-server：Redis 哨兵程序，用于监控 Redis 主从集群，实现故障自动转移（Failover）和高可用性。
/usr/bin/redis-server：Redis 服务器程序，是核心服务进程。其他工具（如 redis-check-aof、redis-sentinel）均为其软链接，通过不同参数启动不同功能。
/usr/libexec/redis-shutdown：专用脚本，用于安全停止 Redis 服务。它会执行保存数据、清理资源等操作，避免直接使用 kill 命令导致数据丢失。
建议 ：相比直接运行上述命令，推荐使用 systemd 托管 Redis 服务（如 systemctl start/stop redis），以实现更可靠的进程管理和日志记录。
bash
systemctl start/stop redis
systemctl restart redis
2、配置文件
/etc/redis.conf：Redis 服务器的主配置文件，包含监听端口、持久化方式、内存限制、安全设置等关键参数。修改后需重启 Redis 生效。
/etc/redis-sentinel.conf：Redis Sentinel 的配置文件，用于定义哨兵监控的主节点、故障判断阈值、通知方式等。
3、持久化文件存储目录
/var/lib/redis/：Redis 默认将 RDB 快照和 AOF 文件存储在此目录。后续章节会详细分析持久化机制及其现象。
4、日志文件目录
/var/log/redis/：Redis 运行日志默认存储在此目录，按天分割并压缩存储（gzip格式）。可通过日志排查问题，例如命令错误、连接异常等。这些文件可用任意文本编辑器打开。后续章节中，我们将通过分析这些日志来观察特定现象。
二、Redis 命令行客户端（redis-cli）
连接 Redis 服务器
启动 Redis 服务后，使用 redis-cli 连接并操作数据（Redis服务）。
bash
redis-cli
Redis 采用典型的客户端-服务器（C/S）架构，其核心交互模式遵循以下流程：
客户端 → 发送请求 → 网络传输 → 服务端处理 → 返回响应 → 客户端
关键特性：
-
跨主机部署：客户端与服务器可分离部署（生产环境常见）
-
同机部署：开发阶段通常在同一主机运行（通过127.0.0.1通信）
-
网络中间件：实际生产中可能经过跳板机、堡垒机等安全设备
-
**Redis 服务器（核心服务）：**负责数据的存储与管理
Redis 客户端和服务器可以部署在同一主机上，也可以分布在不同的主机上。（在当前学习阶段，由于通常只有一台机器可用，客户端和服务器往往会运行在同一台机器上）
Redis-cli 提供两种连接 Redis 服务器的方式，如下：
方式一：交互式模式
bash
redis-cli -h {host，即IP地址} -p {port，即端口号}通过 redis-cli -h {host，即IP地址} -p {port，即端口号} 进入交互式终端，后续命令直接输入（后续操作均为交互式进行，无需再执行redis-cli命令）：
使用本地回环IP地址登录Redis客户端：
bash
#如使用本地回环IP地址登录Redis客户端
redis-cli -h 127.0.0.1 -p 6379
使用自己云服务器的公网IP地址登录Redis客户端：
bash
#如使用自己云服务器的公网IP地址登录Redis客户端
redis-cli -h 113.45.79.2 -p 6379
重点：但是我们发现此时并不能如愿登录，即使我们已经将配置文件中的127.0.0.1修改为0.0.0.0也还是不行，我们回顾一下当时学习MySQL也是遇到了相同的问题，简直一模一样，所以我们这时恍然大悟，首先我们要在云服务器的控制台中配置安全组规则，如下：
优先级设置为1，添加Redis的默认协议端口号6379，和源地址0.0.0.0，这样就可以在任意一台主机上连接登录我们云服务器上的Redis客户端了（同之前设置MySQL安全组规则一模一样）：
添加安全组规则之后，然后再尝试回到终端使用公网IP登录Redis客户端，如下成功登陆连接：
方式二：命令模式
bash
redis-cli -h {host，即IP地址} -p {port，即端口号} {command}直接通过 redis-cli -h {host，即IP地址} -p {port，即端口号} {command} 执行命令并获取结果，这种方法是登录Redis客户端之后，执行了command得到输出结果然后退出Redis客户端，再返回输出结果给Shell输出设备。如下：
使用本地回环IP地址登录Redis客户端：
bash
#如使用本地回环IP地址登录Redis客户端
redis-cli -h 127.0.0.1 -p 6379 ping
redis-cli -h 127.0.0.1 -p 6379 set key hello
redis-cli -h 127.0.0.1 -p 6379 get key
使用自己云服务器的公网IP地址登录Redis客户端：
bash
#如使用自己云服务器的公网IP地址登录Redis客户端
redis-cli -h 113.45.79.2 -p 6379 ping
redis-cli -h 113.45.79.2 -p 6379 set key hello
redis-cli -h 113.45.79.2 -p 6379 get key
注意事项：
-
若 Redis 运行在本地且使用默认端口 6379，可省略
-h和-p参数。如下：bash#如使用本地回环IP地址登录Redis客户端，可省略 -h 和 -p 参数 redis-cli ping redis-cli set key hello redis-cli get key
-
redis-cli是学习 Redis 的核心工具，后续章节将深入介绍其高级功能（如管道、事务、Lua 脚本等）。
三、Redis 客户端形态全景
1、命令行客户端（redis-cli）【教学核心工具】（上面第二点这种）
基础用法：
bash
# 默认连接（127.0.0.1:6379）
root@hcss-ecs-1c15:/etc/redis# redis-cli
127.0.0.1:6379> quit
# 指定主机端口
root@hcss-ecs-1c15:/etc/redis# redis-cli -h 113.45.79.2 -p 6379
113.45.79.2:6379>
生产环境注意事项：
-
需通过SSH隧道或VPN访问
-
可能涉及权限认证（
-a参数或AUTH命令） -
建议使用配置文件管理连接参数
2、图形化客户端【生产环境谨慎使用】
常见类型：
-
**桌面应用：**Redis Desktop Manager、Another Redis Desktop Manager
-
**Web应用：**phpRedisAdmin、FastoRedis
使用限制：
-
Windows系统依赖问题
-
企业网络防火墙限制
-
性能监控功能有限
-
教学建议：仅用于可视化演示，不推荐生产环境使用
一句话来说：这类图形化程序通常依赖 Windows 系统运行。但在实际工作环境中，由于办公 Windows 系统与服务器之间的连接可能存在多种限制，你的图形化界面客户端能否成功连接服务器端的 Redis 服务存在很大不确定性（MySQL 同理）。此外，连接过程中往往需要经过多重跳板机、堡垒机，以及复杂的权限验证流程。
3、编程语言API客户端【生产环境主流方案】
典型实现：
-
Java：Jedis、Lettuce（Spring Data Redis集成）
-
Python：redis-py（支持异步）
-
Go：go-redis
-
Node.js：ioredis
性能对比：
| 客户端类型 | 延迟（μs） | 吞吐量（ops） | 适用场景 |
|---|---|---|---|
| 同步客户端 | 150-300 | 8,000-12,000 | 简单CRUD操作 |
| 异步客户端 | 80-120 | 25,000-40,000 | 高并发管道操作 |
| 连接池客户端 | 60-100 | 50,000+ | 微服务架构 |
四、Redis vs 内存HashMap的性能权衡
问题引入：Redis的速度优势是相对于MySQL这类关系型数据库而言的。但如果直接与内存中的变量操作相比，Redis就没有优势了，甚至会更慢。那么，是该用Redis存储数据，还是直接在内存中使用HashMap呢？
关键区别在于：HashMap是直接操作内存，而Redis需要先经过网络传输，再操作内存。
方案对比 ：各有各的优势和劣势，主要看业务的应用方面（具体问题具体分析）
| 方案 | 实现方式 | 优势 | 劣势 |
|---|---|---|---|
| 本地HashMap | Map<String, Integer> |
零网络延迟 | 进程重启数据丢失 |
| 本地HashMap | Map<String, Integer> |
内存访问速度最快（~50ns） | 无法共享数据 |
| Redis集群 | SET video:123:likes 42 |
数据持久化 | 网络延迟（~200-500μs） |
| Redis集群 | SET video:123:likes 42 |
多进程/服务共享 | 需要序列化开销 |
| Redis集群 | SET video:123:likes 42 |
支持分布式扩展 | 运维复杂度增加 |
决策树：
-
是否需要持久化？→ 是 → Redis；→ 否 → 继续
-
是否需要多进程访问？→ 是 → Redis；→ 否 → 本地HashMap
-
是否可能扩展为分布式？→ 是 → Redis；→ 否 → 本地HashMap
关键结论 ：
-
本地HashMap比Redis快约20,000倍（单次操作）
-
但Redis提供： 数据持久化、 跨进程共享、 水平扩展能力、 丰富的数据结构
技术选型方法论
1. Redis适用场景检查表
| 需求维度 | Redis适配度 |
|---|---|
| 数据持久化 | ★★★★★ |
| 高并发读写 | ★★★★☆ |
| 复杂查询 | ★☆☆☆☆ |
| 跨服务共享 | ★★★★★ |
| 简单键值存储 | ★★★☆☆ |
| 大容量存储 | ★☆☆☆☆ |
2. 反模式警示
在决定引入某项技术时，必须全面考量其来龙去脉，明确它能解决哪些问题，同时也要预判可能带来的新问题。切忌盲目跟风，陷入"手里有锤子，看什么都像钉子"的思维误区。
"锤子思维"典型表现：
-
用Redis存储所有会话数据（应考虑内存成本）
-
用Redis实现复杂关系查询（应使用关系型数据库）
-
用Redis作为主要存储而忽略备份策略
核心原则：技术选型应遵循"合适优于先进"，Redis是强大的工具但非银弹，需根据具体业务场景权衡决策。
五、本章重点回顾
1、Redis 的 8 大特性
-
速度快（基于内存、单线程模型）
-
键值对数据结构服务器
-
功能丰富（支持字符串、哈希、列表、集合等）
-
简单稳定（代码精简、依赖少）
-
多语言客户端支持
-
持久化（RDB/AOF）
-
主从复制与高可用
-
分布式支持（集群模式）
2、Redis 的适用场景
Redis 并非万能，不适合存储大量非热点数据或需要复杂查询的场景（如关系型数据库的联表操作）。
3、开发运维结合
-
开发人员需理解 Redis 的数据结构与命令。
-
运维人员需掌握监控、调优和故障排查。
-
阅读源码可深入理解实现原理。
4、安装与版本选择
-
根据需求选择稳定版本（如 LTS 版本）。
-
推荐使用包管理器（如
yum/apt）或官方源码编译安装。
5、服务管理
- 优先使用
systemd托管 Redis，实现自动启动、日志管理和资源限制。
通过掌握上述内容，我们已具备 Redis 的基础运维能力，后续章节将深入讲解数据结构、集群、性能优化等高级主题。