环境搭建，Ubuntu 安装、客户端使用与性能认知
文章目录
- 1.引言
- 2.Ubuntu 系统 Redis 安装
- 2.1 切换 root 用户
- 2.2 搜索 Redis 软件包
- 2.3 执行安装命令
- 2.4 修改配置文件（允许远程访问）
- 2.5 重启 Redis 并验证状态
- 2.6 用自带客户端连接验证
- 3. Redis 客户端
- 3.1 自带命令行客户端（redis-cli）
- 3.2 图形化界面客户端（可视化工具）
- 3.3 基于 API 自行开发客户端
- 4.redis性能认知
- 4.1 Redis 的 “快”：对比数据库的优势
- 4.2 Redis 的 “慢”：对比内存变量的短板
- 4.3 选择逻辑
1.引言
对于刚接触 Redis 的开发者来说，第一步往往是 “让 Redis 跑起来”—— 从系统安装到客户端连接，再到理解它的性能边界，这些基础操作直接决定了后续实战的效率。本文基于 Ubuntu 系统，手把手带你完成 Redis 的安装与验证，同时拆解客户端的多种形态，并澄清一个关键认知：Redis 的 “快”，到底快在哪里？
2.Ubuntu 系统 Redis 安装
2.1 切换 root 用户
Redis 的安装与配置需要管理员权限，首先通过以下命令切换到 root 用户（输入当前用户密码即可）：
sudo su
2.2 搜索 Redis 软件包
为确认系统仓库中是否存在 Redis 包，可先执行搜索命令（非必需，但能避免安装包名称混淆）：
apt search redis
2.3 执行安装命令
直接通过apt工具安装 Redis，系统会自动处理依赖关系：
apt install redis
2.4 修改配置文件（允许远程访问）
默认情况下，Redis 仅允许本机（127.0.0.1）访问，若需其他主机通过客户端连接，必须修改配置文件：
- 打开配置文件：通过vim或nano编辑/etc/redis/redis.conf（以 vim 为例）：
vim /etc/redis/redis.conf
- 查找并修改绑定地址：在文件中搜索bind 127.0.0.1（ESC模式下输入：/bind 127…），将其改为：
bind 0.0.0.0
- 保存退出：vim 中按ESC，输入:wq并回车。
2.5 重启 Redis 并验证状态
配置修改后需重启服务才能生效，同时可查看启动状态确认是否正常运行：
- 重启服务：
service redis-server restart
- 查看状态：
service redis-server status
2.6 用自带客户端连接验证
Redis 安装后自带命令行客户端redis-cli，可直接用于测试连接：
- 连接 Redis 服务器（默认连接本机 6379 端口）：
redis-cli
- 验证连接：输入ping命令，若返回PONG，则表示客户端与服务器连接成功：
127.0.0.1:6379> ping
PONG
- 退出客户端：输入exit或按Ctrl+D即可退出。
3. Redis 客户端
redis也是一个 客户端-服务器 结构的程序
redis客户端 和 服务器可用在同一台主机上，也可以在不同主机上。
3.1 自带命令行客户端（redis-cli）
这是最基础也最常用的客户端，随 Redis 安装自动附带，无需额外配置：
3.2 图形化界面客户端（可视化工具）
对于不熟悉命令行的开发者，图形化客户端能通过界面直观操作数据，常见工具多支持 Windows、macOS 系统：
- 桌面客户端：如Redis Desktop Manager（RDM）、Another Redis Desktop Manager，支持数据可视化、批量操作、集群管理；
- Web 客户端：如Redis Commander，通过浏览器访问，适合服务器端无图形界面的场景。
3.3 基于 API 自行开发客户端
在实际项目中，我们更多通过编程语言调用 Redis API 来实现客户端逻辑，类似操作 MySQL 的 JDBC 或 C 语言 API：
- 主流语言均有成熟的 Redis 客户端库：
- Java：Jedis、Redisson；
- Python：redis-py；
- Go：go-redis；
- C++：redis-plus-plus;
4.redis性能认知
提到 Redis，“快” 是绕不开的标签，但很多人会陷入 “Redis 比所有存储都快” 的误区。事实上，Redis 的 “快” 是相对的，其局限性也同样明确。
4.1 Redis 的 “快”：对比数据库的优势
Redis 的 “快” 是针对 MySQL 等磁盘关系型数据库而言的，核心原因在于 “内存存储 + 精简流程”（前文已详细拆解），但本质是 “用空间换时间”—— 用内存的高成本换取磁盘 IO 的低延迟。对于需要高频读写的热点数据，Redis 的响应速度能达到 MySQL 的几十倍甚至上百倍，这也是它成为缓存核心的根本原因。
4.2 Redis 的 “慢”：对比内存变量的短板
如果将 Redis 与程序中的内存变量（如 Java 的HashMap、Python 的dict）对比，Redis 反而 “变慢了”。根本原因在于：
- 内存变量：程序直接操作进程内的内存，无额外开销；
- Redis：需要通过网络传输请求（即使客户端与服务器同机，也需走本地网络协议），再由 Redis 服务器处理请求，多了 “网络通信 +服务器解析” 两层开销。
4.3 选择逻辑
| 特性 | redis | 内存变量（如hash map） |
|---|---|---|
| 数据持久化 | 支持（RDB/AOF），重启不丢失 | 不支持，进程重启数据即清空 |
| 跨进程 / 跨主机共享 | 支持，分布式系统核心能力 | 不支持，进程隔离无法共享 |
| 适用场景 | 分布式缓存、会话存储、实时计数 | 单机程序临时数据存储 |
结论：不要无脑使用 Redis—— 单机程序的临时数据用内存变量即可；分布式场景下，需持久化、可共享的数据，再用 Redis 解决。