283 lines
10 KiB
Markdown
283 lines
10 KiB
Markdown
---
|
||
tags: [Redis, 缓存, 运维, 部署]
|
||
create time: 2026-05-15 18:10
|
||
---
|
||
|
||
# Redis 安装与部署
|
||
|
||
## 概述
|
||
|
||
本节介绍 Redis 的安装方式、关键配置和安全加固。无论使用官方二进制还是容器化方案，核心目标一致：**安全启动、合理分配内存、设置持久化策略**。
|
||
|
||
> [!QUESTION] 为什么安装步骤简单，生产部署却容易出问题？
|
||
>
|
||
> Redis 本质是一个单进程内存服务，安装只需几行命令。但一旦上线，内存超限导致 OOM Killer 介入、未设密码被外网扫描器写入大量脏数据、或 AOF/RDB 同时触发 fork 导致内存翻倍——这些才是真正需要关注的问题。
|
||
|
||
## 选择安装方式
|
||
|
||
先根据场景确定合适的部署路径：
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
A[开始：选择安装方式] --> B{运行环境?}
|
||
B -->|macOS 本地开发| C[brew install redis]
|
||
B -->|Ubuntu/Debian 服务器| D[apt install redis-server]
|
||
B -->|需要指定特定版本| E[源码编译]
|
||
B -->|本地开发 / 微服务| F[Docker Compose 推荐]
|
||
B -->|高可用集群| G[[hhs/Redis/07-集群方案]]
|
||
|
||
C --> Z[进入配置阶段 →]
|
||
D --> Z
|
||
E --> Z
|
||
F --> Z
|
||
```
|
||
|
||
### macOS — Homebrew
|
||
|
||
```bash
|
||
brew install redis # 安装最新稳定版
|
||
brew services start redis # 注册为后台服务
|
||
redis-cli ping # 验证：应返回 PONG
|
||
```
|
||
|
||
> [!TIP] 安装后配置文件位于 `/opt/homebrew/etc/redis.conf`（Apple Silicon）或 `/usr/local/etc/redis.conf`（Intel）。
|
||
|
||
### Linux — 包管理器
|
||
|
||
```bash
|
||
sudo apt update && sudo apt install redis-server
|
||
sudo systemctl enable --now redis-server
|
||
```
|
||
|
||
发行版默认安装的 Redis 版本可能落后于上游最新版。如果需要跟进特性或安全补丁，考虑源码编译或 Docker。
|
||
|
||
### 源码编译（指定版本）
|
||
|
||
```bash
|
||
wget https://download.redis.io/releases/redis-7.2.4.tar.gz
|
||
tar xzf redis-7.2.4.tar.gz
|
||
cd redis-7.2.4
|
||
make -j$(nproc) # 利用多核并行编译
|
||
sudo make install # 安装到 /usr/local/bin
|
||
redis-server --version # 确认版本
|
||
```
|
||
|
||
> [!NOTE] Redis 基于 C 开发，编译时无外部依赖（新版内置 jemalloc）。如果你的系统缺少 gcc/make，需提前安装构建工具链。
|
||
|
||
### Docker（推荐本地开发）
|
||
|
||
将以下内容保存为 `docker-compose.yml`：
|
||
|
||
```yaml
|
||
version: "3.9"
|
||
services:
|
||
redis:
|
||
image: redis:7-alpine # Alpine 镜像仅 ~30MB，适合开发环境
|
||
container_name: redis-dev
|
||
ports:
|
||
- "6379:6379"
|
||
volumes:
|
||
- redis-data:/data
|
||
command: >
|
||
redis-server
|
||
--requirepass ${REDIS_PASSWORD:-changeme}
|
||
--appendonly yes
|
||
--maxmemory 512mb
|
||
--maxmemory-policy allkeys-lru
|
||
restart: unless-stopped
|
||
|
||
volumes:
|
||
redis-data:
|
||
```
|
||
|
||
**启动、验证、连接一气呵成：**
|
||
|
||
```bash
|
||
# 1. 在 docker-compose.yml 同目录下启动（-d 后台运行）
|
||
docker compose up -d
|
||
|
||
# 2. 查看容器状态和端口映射
|
||
docker compose ps
|
||
# NAME STATUS PORTS
|
||
# redis-dev Up 30s 0.0.0.0:6379->6379/tcp
|
||
|
||
# 3. 通过容器内 redis-cli 验证连通性
|
||
docker exec redis-dev redis-cli -a changeme ping
|
||
# 输出: PONG
|
||
|
||
# 4. 本地 redis-cli 连接（如果本机已安装）
|
||
redis-cli -h 127.0.0.1 -p 6379 -a changeme
|
||
```
|
||
|
||
> [!TIP]
|
||
> - 通过 `${REDIS_PASSWORD:-changeme}` 引用环境变量，避免在仓库中硬编码真实密码。启动时可 `REDIS_PASSWORD=my-secret docker compose up -d` 覆盖默认值。
|
||
> - 开发环境建议限制 `maxmemory`，防止占满本机内存。
|
||
> - 生产环境不要使用 `redis:latest` 标签，锁定具体版本号以避免未知变更。
|
||
|
||
> [!QUESTION] 为什么用 `docker exec` 而不是直接 `redis-cli`？
|
||
>
|
||
> `docker exec` 不依赖本机是否安装了 redis-cli，任何装了 Docker 的机器都能直接执行——在 CI/CD 或同事的机器上尤其方便。而本机 `redis-cli` 的好处是支持命令历史补全和更丰富的交互体验。
|
||
|
||
> [!EXAMPLE] 常用运维命令速查
|
||
> ```bash
|
||
> docker compose logs -f redis # 实时查看日志
|
||
> docker compose stop redis # 停止容器（保留数据卷）
|
||
> docker compose down -v # 停止并删除数据卷（慎用，清空数据）
|
||
> docker exec redis-dev redis-cli -a changeme INFO memory # 查看内存使用
|
||
> ```
|
||
|
||
## 关键配置项
|
||
|
||
编辑 `redis.conf`（Docker 用命令行参数覆盖），以下是生产环境必看的核心选项：
|
||
|
||
| 配置项 | 推荐值 | 说明 |
|
||
|--------|--------|------|
|
||
| `bind 127.0.0.1` | 内网 IP 或注释 | 限制监听地址；生产环境需配合防火墙规则 |
|
||
| `protected-mode yes` | 保持默认 | 无密码时自动拒绝外部连接 |
|
||
| `port 6379` | — | 自定义端口，但不要指望这算安全措施 |
|
||
| `requirepass your-strong-pass` | 强密码 | **必须设置**，尤其对外暴露时 |
|
||
| `maxmemory 2gb` | 物理内存的 60%~70% | 防止 OOM Killer 接管，给 OS 和子进程留余地 |
|
||
| `maxmemory-policy allkeys-lru` | — | 内存满时的淘汰策略，见下方说明 |
|
||
| `tcp-backlog 511` | 511~1024 | 三次握手已完成但未被 accept 的队列深度 |
|
||
| `timeout 300` | 300 | 客户端空闲超时断开（秒），释放无效连接 |
|
||
| `loglevel notice` | — | debug 级别会产生海量日志，影响性能 |
|
||
| `databases 16` | — | 逻辑数据库数量，通常不改 |
|
||
|
||
> [!IMPORTANT] maxmemory-policy 的选择直接影响业务语义
|
||
>
|
||
> - `allkeys-lru`：对所有键做 LRU 淘汰。**通用场景首选**。
|
||
> - `volatile-lru`：仅对设置了过期时间的键做 LRU 淘汰。适合缓存+热数据混合的场景。
|
||
> - `noeviction`：不淘汰，空间不足时直接报错。适合纯缓存，应用层自行控制生命周期。
|
||
>
|
||
> **选错策略的代价是什么？** 如果用 `noeviction` 而忘了设置过期时间，Redis 会在写操作时报 `OOM` 错误，而非优雅降级。
|
||
|
||
启动并验证配置：
|
||
|
||
```bash
|
||
# 以自定义配置启动
|
||
redis-server /etc/redis/redis.conf
|
||
|
||
# 逐项检查是否生效
|
||
redis-cli CONFIG GET maxmemory
|
||
redis-cli CONFIG GET maxmemory-policy
|
||
redis-cli CONFIG GET requirepass
|
||
```
|
||
|
||
> [!NOTE] 线上修改无需重启：大部分配置可以通过 `CONFIG SET key value` 动态调整，但退出后失效。持久化需在配置文件中修改。
|
||
|
||
## Systemd 服务管理（Linux）
|
||
|
||
使用 systemd 管理能确保开机自启、崩溃自动恢复：
|
||
|
||
```ini
|
||
[Unit]
|
||
Description=Redis In-Memory Data Store
|
||
After=network.target # 网络就绪后再启动 Redis
|
||
|
||
[Service]
|
||
Type=simple
|
||
ExecStart=/usr/local/bin/redis-server /etc/redis/redis.conf
|
||
ExecReload=/bin/kill -USR2 $MAINPID # USR2 触发配置重载（Redis 6.2+）
|
||
Restart=on-failure # 崩溃后自动拉起
|
||
RestartSec=5 # 间隔 5 秒重试，避免频繁闪退
|
||
LimitNOFILE=65535 # 文件描述符上限，支持大量并发连接
|
||
|
||
[Install]
|
||
WantedBy=multi-user.target # 多用户模式下的标准服务
|
||
```
|
||
|
||
```bash
|
||
sudo systemctl daemon-reload # 读取新增/修改的服务文件
|
||
sudo systemctl enable --now redis # 启动 + 开机自启
|
||
sudo journalctl -u redis -f # 实时查看日志
|
||
```
|
||
|
||
> [!QUESTION] 为什么 `Restart=on-failure` 还不够？
|
||
>
|
||
> 如果 Redis 因为配置错误（如 bind 地址不可达）反复崩溃，`on-failure` 会无限重试。配合日志告警或健康检查才能真正发现问题。
|
||
|
||
## 内核级调优
|
||
|
||
Redis 是 IO 密集型单进程服务，操作系统层面的参数会直接影响吞吐量上限：
|
||
|
||
```bash
|
||
echo "vm.overcommit_memory = 1" >> /etc/sysctl.conf
|
||
echo "net.core.somaxconn = 1024" >> /etc/sysctl.conf
|
||
echo "vm.max_map_count = 262144" >> /etc/sysctl.conf
|
||
sysctl -p # 立即生效
|
||
```
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
A[客户端连接请求] -->|SYN| B["TCP 半连接队列<br>somaxconn"]
|
||
B -->|三次握手完成| C["TCP 全连接队列<br>tcp-backlog"]
|
||
C --> D[Redis accept]
|
||
D --> E["分叉持久化<br>overcommit_memory"]
|
||
|
||
style A fill:#e1f5fe
|
||
style C fill:#fff3e0
|
||
style E fill:#f3e5f5
|
||
```
|
||
|
||
| sysctl 参数 | 作用 | 为什么需要 |
|
||
|-------------|------|-----------|
|
||
| `vm.overcommit_memory = 1` | 允许 fork() 时内存过度分配 | RDB 和 AOF rewrite 都通过 fork 创建子进程，父子进程共享物理页；若无此设置，大内存实例 fork 可能被内核拒绝 |
|
||
| `net.core.somaxconn = 1024` | TCP 全连接队列长度 | 高并发下队列满了会导致客户端 connect 超时，表现为"Redis 连不上" |
|
||
| `vm.max_map_count = 262144` | mmap 区域上限 | Redis 在开启 LFU 等特性时会使用 mmap，默认值过小会被限制 |
|
||
|
||
## 部署架构演进
|
||
|
||
单机 → Sentinel → Cluster，不同阶段的架构差异：
|
||
|
||
```mermaid
|
||
flowchart TB
|
||
subgraph S1[阶段一：单机]
|
||
C1[Client] --> M1[(Master)]
|
||
end
|
||
|
||
subgraph S2[阶段二：主从 + Sentinel]
|
||
C2[Client] --> M2[(Master)]
|
||
C2 -.-> S2a[Sentinel]
|
||
M2 --> S2b[(Slave 1)]
|
||
M2 --> S2c[(Slave 2)]
|
||
end
|
||
|
||
subgraph S3[阶段三：Cluster]
|
||
C3[Client] --> P[Hash Slot 路由]
|
||
P --> N1[Node 1: Slots 0-5460]
|
||
P --> N2[Node 2: Slots 5461-10922]
|
||
P --> N3[Node 3: Slots 10923-16383]
|
||
end
|
||
|
||
S1 ===>|数据量增长，需要高可用| S2
|
||
S2 ===>|单机内存瓶颈，需要水平扩展| S3
|
||
|
||
style S1 fill:#e8f5e9
|
||
style S2 fill:#fff3e0
|
||
style S3 fill:#fce4ec
|
||
```
|
||
|
||
> [!INFO] 本系列后续文档将深入每个阶段：
|
||
> - [[hhs/Redis/04-RDB持久化]] — RDB 快照机制
|
||
> - [[hhs/Redis/05-AOF持久化]] — 追加日志机制
|
||
> - [[hhs/Redis/07-集群方案]] — Cluster 分片原理与部署
|
||
|
||
## 快速检查清单
|
||
|
||
> [!CHECKLIST] 部署前核对
|
||
> - [ ] 已设置 `requirepass`（非默认或测试密码）
|
||
> - [ ] `maxmemory` 不超过物理内存的 70%，预留 OS 和 fork 空间
|
||
> - [ ] 已启用持久化（至少 AOF `appendonly yes`）
|
||
> - [ ] `bind` 指向内网地址，或通过防火墙限制访问来源 IP
|
||
> - [ ] `vm.overcommit_memory` 已设为 1
|
||
> - [ ] 已配置合理的 `timeout` 和 `tcp-keepalive`，清理僵尸连接
|
||
> - [ ] 确认 `maxmemory-policy` 符合业务语义（推荐 `allkeys-lru`）
|
||
> - [ ] Docker 部署时密码通过环境变量注入，未硬编码在 compose 文件中
|
||
|
||
## 关联笔记
|
||
|
||
- [[hhs/Redis/02-核心数据类型]] — String / Hash / List / Set / ZSet 的使用场景
|
||
- [[hhs/Redis/04-RDB持久化]] — RDB 快照原理与配置
|
||
- [[hhs/Redis/05-AOF持久化]] — AOF 重写机制与 fsync 策略
|
||
- [[hhs/Redis/07-集群方案]] — Cluster 部署与迁移策略
|
||
- [[hhs/Redis/11-运维与性能调优]] — OOM、延迟 spike、连接数爆满的诊断思路 |