Redis 5分钟快速部署：四大主流方式实操指南

1. 项目概述：为什么“5分钟快速部署Redis”不是营销话术，而是可落地的工程现实

Redis不是那种需要你啃三天文档、配半天环境、最后还卡在某个报错上反复Google的工具。它本质是个单进程、零依赖、开箱即用的内存数据结构服务器——核心二进制文件就一个redis-server，连glibc都不用额外装。我第一次在Ubuntu 22.04上跑起来，从curl -O下载到redis-cli ping返回PONG，实际耗时3分47秒。后来在Mac M1上用Homebrew，敲完brew install redis回车，等咖啡凉透，服务已经监听6379端口了。这背后不是玄学，是Redis团队十年如一日对“最小化部署摩擦”的极致坚持：不强制要求systemd、不绑定特定日志系统、不硬编码路径、甚至默认配置里连密码都设为空——它默认就是为你“先跑起来，再优化”的场景设计的。所以标题里说“5分钟”，不是取整凑数，而是基于真实操作链路的保守估算：下载（30秒）、解压/安装（60秒）、启动（10秒）、验证（20秒），剩下3分40秒全是给你倒水、看文档、改配置的缓冲时间。适合谁？刚接触后端开发的应届生、需要临时搭个缓存做Demo的前端、运维新手练手容器化部署、甚至产品经理想本地验证下接口性能——只要你不是在金融级高可用集群里做灰度发布，这个“5分钟”就成立。关键词里反复出现的Docker、Homebrew、Windows，恰恰说明Redis的部署路径早已不是单一命令行的事，而是横跨三大主流开发环境的标准化动作。接下来我会把这5分钟拆成可计时、可复现、可纠错的完整链条，不讲虚的，只告诉你每一步敲什么、为什么这么敲、卡住了怎么一眼定位。

2. 部署方式全景图：为什么只推4种方案，而不是罗列10种冷门方法

2.1 四条主干路径的选型逻辑：效率、可控性、复用性三角平衡

很多人一上来就问“哪种安装方式最好”，这个问题本身就有陷阱。没有“最好”，只有“最适合当前场景”。我过去三年给27个不同团队做过Redis部署咨询，最终沉淀出四条主干路径，每条都对应明确的决策树：

• Homebrew（Mac）：适合个人开发机、CI/CD流水线中的Mac构建节点。优势是版本管理干净（brew upgrade redis一键升级）、依赖自动解析（比如自动装好OpenSSL）、卸载无残留（brew uninstall redis彻底清除）。劣势是无法自定义编译参数（比如禁用jemalloc），且国内源偶尔同步延迟。这不是“Mac用户专属”，而是“追求开发体验一致性”的选择。

• Docker（全平台）：适合需要环境隔离的场景——比如你同时跑Redis 6.2和7.0做兼容性测试，或者在Windows上不想装WSL。它的核心价值不是“省事”，而是“确定性”：docker run -p 6379:6379 redis:7.2-alpine这条命令，在任何有Docker的机器上，拉取的镜像、启动的进程、暴露的端口，100%一致。我见过最典型的误用是：把Docker当安装器，在生产环境直接docker run裸跑，结果容器重启后数据全丢。所以Docker方案必须配套卷挂载或配置持久化，这点后面会细说。

• 官方二进制包（Linux/Windows）：适合生产环境首次部署、离线环境、或需要精确控制二进制行为的场景。比如你要用--enable-debug编译调试版，或者必须链接特定版本的tcmalloc。下载地址https://redis.io/downloads/提供的tar.gz包，解压即用，连make都不用——因为Redis官方已为你编译好所有主流架构的静态二进制。注意：这里说的“官方包”特指redis.io发布的，不是EPEL或apt仓库里的，后者版本滞后严重（Ubuntu 22.04 apt源还是6.0，而当前稳定版是7.2）。

• Windows Subsystem for Linux（WSL）+ Linux原生方式：这是Windows用户的最优解，而非“Windows原生安装”。Redis官方早就不维护Windows版（2016年已停止），现在网上流传的Windows安装包，要么是第三方移植（如MicrosoftArchive/redis），要么是WSL层套壳。实测下来，WSL2 + Ubuntu 22.04 +apt install redis-server的组合，性能、稳定性、配置习惯完全对标Linux服务器，且能直接复用所有Linux教程。强行用Windows服务方式跑，你会遇到信号处理异常、AOF重写失败、RDB保存超时等一系列“非标准问题”。

提示：为什么没提“源码编译”？因为它不是部署方式，而是定制方式。除非你要打patch修复特定bug，或者必须启用某个实验性模块（如RedisJSON），否则make && make install纯属增加故障点。我统计过，83%的编译失败源于本地gcc版本不匹配或缺少libssl-dev，而这些在二进制包里早已解决。

2.2 被淘汰的路径：那些看似方便实则埋雷的“快捷方式”

有些方案在搜索热词里高频出现，但必须明确告知风险：

• npm install redis：这是Redis客户端库（Node.js版），不是服务端！装完你会发现redis-server命令不存在。很多初学者被“redis”这个包名误导，浪费半小时查PATH问题。

• Chocolatey（Windows）：虽然choco install redis-64能装，但它调用的是已废弃的MSOpenTech版本，不支持Redis 7.x的新特性（如Redis Functions），且服务管理脚本有权限漏洞（以LocalSystem身份运行，存在提权风险）。

• 云服务商一键部署：阿里云、腾讯云控制台点几下就能起Redis实例，但这属于“托管服务”，不是“部署”。你无法登录服务器看/proc/sys/vm/overcommit_memory，不能调优tcp-backlog，更不能执行redis-cli --cluster create。它解决的是“有没有”，不是“好不好”。

• Homebrew Cask（macOS）：brew install --cask redis安装的是GUI客户端（如Another Redis Desktop Manager），不是服务端。这是Homebrew生态里最经典的命名混淆陷阱。

选型的本质是权衡。如果你今天要交一个毕业设计Demo，用Docker；如果明天要上线电商秒杀系统，用官方二进制包+systemd；如果后天要给实习生配开发环境，用Homebrew。没有银弹，只有上下文。

3. 四大方案实操详解：每一步命令背后的原理与避坑点

3.1 Homebrew 方式（macOS）：从安装到开机自启的完整闭环

Homebrew不是简单的包管理器，它是macOS上“Unix哲学”的具象化——用shell脚本封装复杂操作，但把控制权交还给用户。执行brew install redis时，它实际做了五件事：下载预编译二进制、校验SHA256签名、解压到/opt/homebrew/Cellar/redis/7.2.5、创建符号链接到/opt/homebrew/bin/redis-server、写入plist服务配置。关键细节在于plist文件：/opt/homebrew/opt/redis/homebrew.mxcl.redis.plist，它定义了Redis作为macOS LaunchDaemon的启动行为。

实操步骤与原理注释：

1. 安装Homebrew（若未安装）

   /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

   这条命令的核心是curl拉取install.sh脚本并用bash执行。注意-f参数：如果GitHub响应404（比如国内网络波动），curl会立即失败，避免卡死。国内用户常被“连接超时”劝退，其实只需加-x指定代理（如公司内网代理），或改用清华源镜像：

   export HOMEBREW_BOTTLE_DOMAIN=https://mirrors.tuna.tsinghua.edu.cn/homebrew-bottles /bin/bash -c "$(curl -fsSL https://mirrors.tuna.tsinghua.edu.cn/git/homebrew/install.sh)"

2. 安装Redis

   brew install redis

   安装完成后，redis-server可执行文件位于/opt/homebrew/bin/（Apple Silicon）或/usr/local/bin/（Intel）。此时不要急着启动，先检查配置：brew --prefix redis输出/opt/homebrew/opt/redis，其下的/etc/redis.conf是默认配置模板。重点修改三处：

   • bind 127.0.0.1 ::1→ 保留，禁止外网访问（安全基线）
   • protected-mode yes→ 必须为yes，防止未授权访问
   • dir /opt/homebrew/var/db/redis→ 指定数据目录，Homebrew已为你创建好该路径

3. 启动服务（两种模式）

   • 临时启动（调试用）：redis-server /opt/homebrew/etc/redis.conf
     此时终端会阻塞，Ctrl+C可停止。日志直接输出到控制台，方便实时看DB loaded from disk这类关键信息。
   • 后台服务（生产用）：brew services start redis
     这会加载plist文件，让Redis随系统启动。验证是否成功：brew services list | grep redis，状态应为started。此时日志写入/opt/homebrew/var/log/redis.log，用tail -f可追踪。

注意：brew services start本质是launchctl load -w /opt/homebrew/opt/redis/homebrew.mxcl.redis.plist。如果某天发现服务启动失败，直接运行launchctl bootstrap gui/$(id -u) /opt/homebrew/opt/redis/homebrew.mxcl.redis.plist可绕过brew层诊断问题。

避坑心得：

• 常见错误Could not create server TCP listening socket *:6379: bind: Address already in use，90%是因为之前用redis-server前台启动后没Ctrl+C，进程还在后台占着端口。用lsof -i :6379查PID，kill -9干掉。
• 如果brew services start后redis-cli ping返回(error) NOAUTH Authentication required，说明配置里设置了requirepass但没在cli里认证。临时解决：redis-cli -a yourpassword ping，长期方案是删掉配置里的requirepass行（开发环境无需密码）。
• Homebrew升级Redis后，旧配置不会自动迁移。brew upgrade redis后，新配置在/opt/homebrew/etc/redis.conf，但服务仍读取旧路径。必须手动brew services stop redis && brew services start redis重载。

3.2 Docker 方式（全平台）：不只是docker run，而是可复用的部署单元

Docker部署Redis的误区是把它当成“图形化安装向导”。实际上，docker run redis:7.2只是最小可行集，离生产可用差三个关键环节：数据持久化、配置注入、网络策略。下面给出工业级部署方案。

实操步骤与原理注释：

1. 基础运行（验证环境）

   docker run -d --name my-redis -p 6379:6379 redis:7.2-alpine

   参数解析：

   • -d：后台守护模式，符合生产习惯（前台模式仅用于调试）
   • --name my-redis：指定容器名，避免redis:7.2-alpine这种随机ID（如eloquent_mccarthy），便于后续docker exec -it my-redis redis-cli进入
   • -p 6379:6379：宿主机6379映射容器6379。注意：如果宿主机已有Redis，需换端口如-p 6380:6379
   • redis:7.2-alpine：选用alpine镜像（约5MB），比redis:7.2（110MB）更轻量，且同样稳定（Alpine的musl libc与Redis兼容性已验证多年）

2. 生产级部署（带持久化与配置）
   创建docker-compose.yml文件（这才是可复用的部署单元）：

   version: '3.8' services: redis: image: redis:7.2-alpine container_name: redis-prod restart: unless-stopped # 容器崩溃自动重启，但手动stop不重启 ports: - "6379:6379" volumes: - ./redis-data:/data # 将宿主机./redis-data挂载为容器/data - ./redis.conf:/usr/local/etc/redis/redis.conf # 挂载自定义配置 command: ["redis-server", "/usr/local/etc/redis/redis.conf"] sysctls: - net.core.somaxconn=1024 # 调优TCP连接队列，避免"Connection refused"

   关键点解析：

   • volumes双挂载：/data是Redis默认工作目录，AOF和RDB文件全存这里；redis.conf必须绝对路径挂载，否则command参数无效
   • command覆盖默认启动命令，强制用你的配置文件（否则容器用内置默认配置，requirepass等设置不生效）
   • sysctls是必须项！Linux默认net.core.somaxconn=128，高并发时新连接被丢弃，现象是redis-cli报Connection refused。设为1024是保守值，生产环境建议2048+

3. 启动与验证

   docker-compose up -d # 后台启动 docker-compose logs -f redis # 实时看日志，直到出现"Ready to accept connections" redis-cli ping # 返回PONG即成功

提示：Docker镜像源加速是刚需。国内用户务必配置镜像加速器，否则docker pull redis可能卡住。在/etc/docker/daemon.json中添加：

{ "registry-mirrors": ["https://docker.mirrors.ustc.edu.cn"] }

然后sudo systemctl restart docker。USTC镜像站同步频率<5分钟，比DaoCloud等更可靠。

避坑心得：

• 挂载redis.conf后仍不生效？检查文件权限：chmod 644 redis.conf，Docker容器内redis用户（UID 999）需有读权限。
• docker-compose up报ERROR: for redis Cannot create container for service redis: invalid mount config for type "bind"，大概率是./redis-data路径不存在。先mkdir -p ./redis-data再启动。
• Windows用户用Docker Desktop，挂载路径要写成C:/path/to/redis-data（正斜杠），不能用C:\path\to\redis-data（反斜杠会被当作转义符）。

3.3 官方二进制包方式（Linux/Windows WSL）：从下载到systemd的全链路

这是最接近“传统Linux运维”的方式，也是生产环境首选。它不隐藏任何细节，让你直面Redis的每个配置项。

实操步骤与原理注释：

1. 下载与校验（安全第一）

   # 创建工作目录 mkdir -p /opt/redis && cd /opt/redis # 下载最新稳定版（以7.2.5为例） curl -O https://download.redis.io/releases/redis-7.2.5.tar.gz # 校验SHA256（官网提供，必须做！） curl -O https://download.redis.io/releases/redis-7.2.5.tar.gz.sha256 sha256sum -c redis-7.2.5.tar.gz.sha256 # 输出"redis-7.2.5.tar.gz: OK"表示校验通过

   为什么必须校验？因为curl -O可能被中间人劫持，下载到恶意篡改的二进制。SHA256校验是唯一可信验证手段。如果校验失败，立即删除文件，重新下载。

2. 解压与安装（零编译）

   tar -xzf redis-7.2.5.tar.gz cd redis-7.2.5 # 官方已编译好二进制，直接复制到/usr/local/bin sudo cp src/redis-server src/redis-cli /usr/local/bin/ # 创建配置和数据目录 sudo mkdir -p /etc/redis /var/lib/redis sudo cp redis.conf /etc/redis/6379.conf

   注意：src/redis-server是动态链接二进制，依赖系统glibc。如果ldd src/redis-server显示not found，说明glibc版本太低，此时必须用make编译（需装build-essential），而非直接复制。

3. 配置调优（生产必备）
   编辑/etc/redis/6379.conf，重点修改：

   bind 127.0.0.1 ::1 # 只监听本地，禁用0.0.0.0 protected-mode yes # 开启保护模式 port 6379 # 端口，可改但需同步更新客户端 tcp-backlog 511 # TCP连接队列长度，内核net.core.somaxconn需>=此值 timeout 0 # 客户端空闲超时，0表示永不超时（开发环境） loglevel notice # 日志级别，production用notice，debug用verbose logfile /var/log/redis_6379.log # 日志路径，需提前创建目录 dir /var/lib/redis # 数据目录，AOF/RDB存这里 dbfilename dump.rdb # RDB文件名 appendfilename "appendonly.aof" # AOF文件名 appendonly yes # 强烈建议开启AOF，数据更安全 appendfsync everysec # AOF刷盘策略，折中性能与安全性 requirepass your_strong_password # 生产必须设密码！ maxmemory 2gb # 内存上限，防OOM maxmemory-policy allkeys-lru # 内存满时LRU淘汰

4. systemd服务配置（自动化管理）
   创建/etc/systemd/system/redis.service：

   [Unit] Description=Redis In-Memory Data Store After=network.target [Service] Type=notify User=redis Group=redis ExecStart=/usr/local/bin/redis-server /etc/redis/6379.conf ExecStop=/usr/local/bin/redis-cli -h 127.0.0.1 -p 6379 shutdown Restart=always RestartSec=10 UMask=007 PrivateTmp=yes LimitNOFILE=65535 LimitNPROC=65535 NoNewPrivileges=yes [Install] WantedBy=multi-user.target

   关键参数说明：

   • Type=notify：Redis支持通知systemd启动完成，比simple更精准
   • User=redis：必须创建专用用户，禁止root运行（安全基线）
   • LimitNOFILE：提高文件描述符限制，应对高并发连接

   启动服务：

   sudo adduser --system --group --no-create-home redis sudo chown -R redis:redis /var/lib/redis /var/log/redis_6379.log sudo systemctl daemon-reload sudo systemctl enable redis sudo systemctl start redis sudo systemctl status redis # 验证状态

注意：systemctl start redis失败时，用journalctl -u redis -f看实时日志。常见错误Failed at step USER spawning，是因为/etc/passwd里redis用户shell被设为/usr/sbin/nologin，但systemd要求有效shell。解决方案：sudo usermod -s /bin/bash redis。

避坑心得：

• maxmemory设太小会导致频繁淘汰，设太大可能OOM。计算公式：maxmemory = 总内存 × 0.75（留25%给系统和其他进程）。
• AOF开启后，appendonly.aof文件会持续增长。Redis 7.2自动触发AOF重写（bgrewriteaof），但需确保dir目录有足够空间。监控命令：redis-cli info persistence | grep aof_current_size。
• 如果redis-cli -a password ping报错，检查requirepass是否在配置文件里，且redis-server进程是否用该配置启动（ps aux | grep redis看启动命令）。

3.4 WSL 方式（Windows）：用Linux原生体验终结Windows兼容性噩梦

Windows用户最大的认知误区是：“我得找Windows版Redis”。真相是：微软官方推荐WSL运行Redis，且WSL2的性能已接近原生Linux（网络延迟<1ms，磁盘IO差异<5%）。

实操步骤与原理注释：

1. 启用WSL2（Windows 10/11）
   以管理员身份运行PowerShell：

   dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart # 重启电脑 wsl --install # 自动安装Ubuntu 22.04 wsl --set-default-version 2

   关键点：VirtualMachinePlatform是WSL2必需，wsl --install会自动配置内核更新。如果wsl -l -v显示VERSION为1，执行wsl --set-version Ubuntu-22.04 2升级。

2. 在WSL中部署（复用Linux方案）
   进入Ubuntu终端，执行Linux二进制包方案的全部步骤（3.3节）。唯一区别是路径：

   • WSL的/home/username映射到Windows的C:\Users\username\AppData\Local\Packages\...
   • 但Redis数据目录建议放在WSL内部（如/var/lib/redis），避免Windows文件系统（NTFS）的inode和权限问题

3. Windows端访问（无缝集成）
   WSL2的IP是动态的，但localhost在Windows端自动映射到WSL2。所以：

   • Windows上的Python程序：redis.Redis(host='localhost', port=6379)直接连通
   • Windows上的Redis Desktop Manager：Host填localhost，Port填6379
   • 不需要netsh interface portproxy等复杂端口转发！

提示：WSL2默认内存限制为50%，可能导致Redis OOM。在C:\Users\username\wsl.conf中添加：

[wsl2] memory=4GB swap=2GB

然后wsl --shutdown重启生效。

避坑心得：

• redis-cli在Windows Terminal里中文乱码？执行chcp 65001切换UTF-8编码。
• WSL2启动慢？关闭Windows Defender实时防护（对/home目录），或在wsl.conf中添加[automount] enabled = false禁用自动挂载Windows盘。
• 如果systemctl不可用（WSL默认无systemd），用sudo service redis-server start替代，或安装genie（sudo apt install genie && genie -s）启用完整systemd。

4. 部署后必做的5项验证与调优：让Redis真正“可用”而非“能跑”

部署完成≠可用。我见过太多团队redis-cli ping返回PONG就以为万事大吉，结果上线后出现连接超时、内存暴涨、数据丢失。以下是上线前必须完成的5项验证，每项都有具体命令和预期结果。

4.1 连接性与基础功能验证

这是最易忽略却最关键的一环。很多问题源于网络或配置，而非Redis本身。

• 本地连接测试：

  redis-cli -h 127.0.0.1 -p 6379 ping # 预期：PONG redis-cli -h 127.0.0.1 -p 6379 set test "hello" redis-cli -h 127.0.0.1 -p 6379 get test # 预期："hello"

• 远程连接测试（如需）：
  在另一台机器执行：

  redis-cli -h your_server_ip -p 6379 ping # 若失败，检查：1) 服务器防火墙（ufw allow 6379） 2) Redis配置bind是否包含该IP 3) 云服务器安全组

• 密码验证（生产环境）：

  redis-cli -h 127.0.0.1 -p 6379 auth your_password # 预期：OK redis-cli -h 127.0.0.1 -p 6379 get test # 预期："hello"

注意：redis-cli默认尝试连接127.0.0.1:6379，如果配置了bind 127.0.0.1但没设密码，redis-cli ping会成功；但如果配置了requirepass，redis-cli ping会报错，必须显式auth。

4.2 内存与持久化验证

Redis内存管理是核心，持久化是生命线。

• 内存使用检查：

  redis-cli info memory | grep -E "(used_memory_human|maxmemory_human|mem_allocator)" # used_memory_human 应远小于 maxmemory_human（如有设置） # mem_allocator 应为jemalloc（Linux）或libc（macOS），jemalloc更优

• RDB快照验证：

  redis-cli bgsave # 手动触发RDB保存 # 等待几秒，检查dump.rdb文件是否生成且大小>0 ls -lh /var/lib/redis/dump.rdb

• AOF重写验证：

  redis-cli bgrewriteaof # 手动触发AOF重写 # 查看日志：tail -f /var/log/redis_6379.log | grep "Background append only file rewriting" # 成功后，appendonly.aof文件大小应显著减小

4.3 性能基准测试

用官方工具redis-benchmark做压力测试，不是为了追求TPS数字，而是验证配置合理性。

• 基础测试（100并发，10000请求）：

  redis-benchmark -h 127.0.0.1 -p 6379 -c 100 -n 10000 -q # -q 表示quiet模式，只输出结果 # 预期：SET: 12000.00 requests per second, GET: 13000.00 requests per second # 如果<5000，检查CPU是否瓶颈（top看%us）、磁盘是否慢（iostat -x 1）

• 混合操作测试（模拟真实场景）：

  redis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 10000 -t set,get,incr,lpush -q # 测试多种命令混合性能，更贴近业务

4.4 高可用与故障转移验证（如部署集群）

单机Redis满足不了生产，但集群部署前必须验证基础能力。

• 主从复制验证：
  启动两个Redis实例（端口6379主，6380从），在从节点执行：

  redis-cli -p 6380 slaveof 127.0.0.1 6379 redis-cli -p 6380 info replication | grep role # 预期：role:slave redis-cli -p 6379 set master_key "value" sleep 1 redis-cli -p 6380 get master_key # 预期："value"

• 故障转移模拟：

  # 杀掉主节点 redis-cli -p 6379 shutdown # 等待10秒，检查从节点是否升主 redis-cli -p 6380 info replication | grep role # 预期：role:master

4.5 安全加固验证

安全不是附加项，而是部署的起点。

• 未授权访问检测：

  # 用nmap扫描6379端口 nmap -p 6379 your_server_ip # 如果STATE为open，且没设密码，立即失败！ # 用redis-cli尝试无密码连接 redis-cli -h your_server_ip -p 6379 CONFIG GET requirepass # 如果返回空，说明没设密码，高危！

• 敏感信息泄露检查：

  # 检查配置文件是否包含密码明文（开发环境允许，生产环境禁止） grep "requirepass" /etc/redis/6379.conf # 如果存在，必须用环境变量或外部密钥管理服务替代

提示：生产环境密码不应写在配置文件里。推荐方案：启动时用--requirepass $(cat /run/secrets/redis_password)，配合Docker secrets或Kubernetes secrets。

5. 常见问题与排查技巧实录：那些文档里不会写的实战经验

5.1 “Connection refused” 的7种可能及速查表

这是部署时最高频的报错，原因千奇百怪。我整理了7种典型场景，按排查顺序排列：

独家技巧：当所有命令都显示正常，但就是连不上，执行strace -e trace=connect,bind,listen redis-server /etc/redis.conf 2>&1 \| head -50。strace会显示Redis启动时调用的系统调用，如果bind(6379)返回EADDRINUSE，说明端口被占；如果listen()后无accept()，说明没收到连接请求——这能精准定位是网络层还是应用层问题。

5.2 内存爆满的3个隐性原因与对策

used_memory_human接近maxmemory时，Redis会开始淘汰key，但很多情况是内存“虚高”。

• 原因1：客户端缓冲区堆积
  redis-cli info clients \| grep client_longest_output_list，如果>1000，说明某个客户端（如订阅者）接收消息太慢，缓冲区积压。对策：CLIENT LIST找出omem>0的客户端，CLIENT KILL干掉。

• 原因2：AOF rewrite期间内存翻倍
  AOF重写时，Redis会fork子进程，子进程共享父进程内存页（Copy-on-Write），但重写过程中父进程新写入的数据会触发页复制，导致内存瞬时翻倍。对策：监控info persistence \| grep aof_rewrite_in_progress，重写期间避免大