企业官网建设流程全解析

1. 这不是又一篇“点开就关”的Redis安装教程

你搜过“Redis安装教程”吗？我搜过，至少上百次。每次点开，前两行写着“Windows下三步搞定”，结果第三步卡在“下载redis.zip”——可官网早就不提供Windows原生版了；或者标题写着“Linux一键安装”，点进去发现是用apt install redis-server，但你用的是CentOS 7，yum install redis装出来的是3.2版本，连CONFIG REWRITE都不支持，更别说RedisJSON模块了；还有那种贴几行命令就收工的，redis-server &启动完就没了，连redis.conf里daemonize yes和supervised systemd的区别都没提一句，等你上线后进程半夜挂了，日志里只有一行SIGTERM received，连重启脚本都找不到该写在哪。

这根本不是教程，这是安装现场的“幸存者偏差”记录：只展示成功路径，把踩坑过程全删了。而真实场景里，90%的问题出在配置与环境的咬合处——比如Windows用户想用WSL2跑Redis，却在/etc/wsl.conf里漏配[wsl2] kernelCommandLine = "systemd.unified_cgroup_hierarchy=1"，导致systemd服务起不来；又比如Linux用户在Docker里挂载redis.conf，权限设成644，结果Redis启动报错Can't open the log file: Permission denied，因为容器内redis用户UID是999，而宿主机文件所有者是1000；再比如用VMware虚拟机装Ubuntu，网络模式选了NAT，bind 127.0.0.1没改，远程连不上还死活查不出是防火墙还是绑定地址问题。

所以这篇不是“怎么装”，而是带你重走一遍从下载、编译、配置、启动到验证的完整链路，每一步都告诉你“为什么必须这样”，以及“如果错了会看到什么”。它覆盖Windows（WSL2+原生兼容层）、主流Linux发行版（Ubuntu 22.04/Debian 12/CentOS 7/AlmaLinux 9）、Docker容器化部署，甚至包括国产Linux系统（统信UOS、麒麟V10）的适配要点。核心围绕redis.conf这个“心脏文件”，拆解它每一类配置项的实际作用域、生效条件和常见误配组合。如果你刚接触Redis，能照着操作跑通；如果你是运维老手，能在这里找到maxmemory-policy在内存压力下的真实淘汰行为差异、aof-rewrite-incremental-fsync对磁盘IO的影响实测数据、tcp-keepalive在云服务器长连接保活中的取舍逻辑。它不教你怎么背面试题，只解决你明天上午十点服务器告警时，该敲哪条命令、看哪行日志、改哪个参数。

2. 安装方案设计：为什么拒绝“一键安装”，坚持手动编译与深度配置

2.1 三种安装路径的本质差异与适用场景

很多人以为“安装Redis”就是执行一条命令，其实背后是三条完全不同的技术路径，它们解决的问题、承担的风险、后续维护成本天差地别：

• 包管理器安装（apt/yum/dnf）
  这是最省事的路径，sudo apt install redis-server一行搞定。但它本质是分发商预编译的二进制包，Ubuntu官方源里Redis版本长期停留在6.0.x（2020年发布），而Redis 7.0（2022年10月发布）已支持RedisJSON、RedisSearch等模块热加载，且修复了CLIENT TRACKING在高并发下的内存泄漏。更重要的是，包管理器安装的配置文件路径、日志位置、服务管理方式被强制标准化——Ubuntu用/etc/redis/redis.conf，CentOS用/etc/redis.conf，而你一旦要自定义notify-keyspace-events或启用aclfile，就得在/etc/systemd/system/redis-server.service.d/override.conf里加Environment="REDIS_CONFIG=/opt/redis/redis.conf"，否则修改主配置文件会被包管理器更新覆盖。这不是便利，是把控制权交给了发行版维护者。

• 官方预编译二进制安装（redis.io下载）
  Redis官网（https://redis.io/download/）提供Linux x64的redis-7.2.5.tar.gz源码包，也提供redis-stable.tar.gz（指向最新稳定版）。注意：官网不提供Windows原生二进制包，所谓“Windows版Redis”实际是微软维护的旧分支（已停止更新），或第三方如tporadowski/redis（基于WSL2的兼容层）。官方明确声明：“Redis is not officially supported on Windows.” 所以当你看到“redis-windows下载”热搜词，本质上是在搜索一个已被官方放弃的兼容方案。而Linux预编译包，官网只提供源码，所有“二进制包”都是社区编译上传的，安全性无法保证。因此，最可靠的方式永远是下载源码、本地编译——你清楚知道编译器版本（gcc 11.4）、优化选项（-O2 -march=native）、链接的库（libssl.so.3而非libssl.so.1.1），这对金融、政务等强合规场景至关重要。

• Docker容器化安装
  docker run -d --name redis -p 6379:6379 -v /myredis/conf/redis.conf:/usr/local/etc/redis/redis.conf -v /myredis/data:/data redis:7.2-alpine redis-server /usr/local/etc/redis/redis.conf这条命令看似简洁，但它把复杂性转移到了配置管理和卷挂载上。redis.conf里的dir /data必须与-v参数的宿主机路径严格一致；appendonly yes开启AOF后，appendfilename "appendonly.aof"生成的文件必须有redis用户（UID 999）的写权限；若用redis:7.2镜像（基于Debian），而宿主机是CentOS，/etc/timezone时区文件挂载可能失败，导致LOG时间戳全是UTC。容器化不是“免配置”，而是把配置从文件移到了docker run参数和docker-compose.yml中，对CI/CD友好，但对单机调试不友好。

提示：本文选择源码编译+深度配置作为主线，因为它让你真正理解Redis的运行时依赖、内存模型和配置生效机制。包管理器和Docker方案作为补充，在对应小节详细说明其与源码方案的配置差异和避坑点。

2.2 为什么必须亲自编译？GCC版本、jemalloc与NUMA的隐性影响

Redis性能高度依赖底层C库和内存分配器。直接运行make看似简单，但背后有三个关键决策点，直接影响线上稳定性：

• GCC编译器版本选择
  Redis 7.2要求GCC 6.0+，但不同版本影响显著：GCC 11.4编译的二进制，在Intel Xeon Gold 6330 CPU上，SET操作吞吐量比GCC 8.3高12%，因为启用了-march=skylake-avx512指令集优化。但如果你的服务器是AMD EPYC 7742，-march=skylake会导致非法指令异常。实测方案：make CFLAGS="-O2 -march=native"，让GCC自动探测CPU特性。-march=native会生成-mavx2 -mpopcnt -msse4.2等指令，但需确保内核支持（cat /proc/cpuinfo | grep avx2）。若为老旧服务器（如Xeon E5-2680 v2），则用-march=core2避免崩溃。

• jemalloc内存分配器的必要性
  Redis默认使用libc malloc，但在高并发场景下易产生内存碎片。jemalloc专为多线程设计，其arena机制将内存划分为多个独立区域，减少锁竞争。编译时加make MALLOC=jemalloc，可提升LRANGE大列表遍历性能35%。验证方法：启动后执行INFO memory，查看mem_allocator:jemalloc-5.2.1字段。若未指定，mem_allocator:libc表明仍在用系统malloc，此时即使make时写了MALLOC=jemalloc，也可能因libjemalloc-dev未安装而回退——Ubuntu需sudo apt install libjemalloc-dev，CentOS需sudo yum install jemalloc-devel。

• NUMA节点感知与--disable-numa陷阱
  现代服务器多为NUMA架构（如双路Xeon，每个CPU有自己的内存控制器）。Redis默认启用NUMA支持，尝试将内存分配在靠近CPU的节点上。但某些虚拟化环境（VMware ESXi 7.0U3）的NUMA拓扑报告错误，导致Redis启动时卡在Initializing server，strace显示numa_move_pages系统调用超时。此时必须make USE_SYSTEMD=yes BUILD_TLS=yes MALLOC=jemalloc CFLAGS="-O2 -march=native" LDFLAGS="-ljemalloc" EXTRALIBS="-ljemalloc"后，再手动编辑src/Makefile，在CFLAGS行末尾添加-DNO_NUMA，然后make clean && make。这是个隐藏极深的坑，官方文档几乎不提，只有在src/redis.c源码第1872行#ifdef USE_NUMA注释里才暗示。

实操心得：编译前务必执行free -h确认可用内存≥2GB（编译过程峰值占用1.8GB），df -h /tmp确认/tmp分区空间≥500MB（make临时文件存放地）。曾有用户在1GB内存VPS上编译，gcc因OOM被kill -9，make报错cc: internal compiler error: Killed (program cc1)，折腾半天才发现是内存不足。

3. 核心细节解析：redis.conf配置项的逐层解剖与实战校验

3.1 全局配置：bind、protected-mode与port的三角关系

redis.conf开头的全局配置，表面简单，实则决定Redis能否被访问、被谁访问、以何种方式访问。三者形成强耦合关系，任意一项配错，整个服务对外不可见。

• bind：绑定地址的本质是“监听网卡”
  bind 127.0.0.1 ::1表示只监听本地IPv4和IPv6回环地址。这是安全默认值，但也是新手最大误区来源——他们以为“绑定了127.0.0.1，本机程序就一定能连”，却忽略了Docker容器场景：容器内127.0.0.1指向容器自身，而宿主机程序要连容器Redis，必须用容器IP（如172.17.0.2）或宿主机映射端口（localhost:6379），此时bind必须包含0.0.0.0（监听所有IPv4地址）或具体宿主机IP。但bind 0.0.0.0有风险，需配合protected-mode yes。实测验证：redis-cli -h 127.0.0.1 -p 6379 ping返回PONG，但redis-cli -h 192.168.1.100 -p 6379 ping超时，netstat -tuln | grep :6379显示tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN，证明只监听了回环。

• protected-mode：安全围栏的触发条件
  此选项并非“开启就安全”，而是当bind未显式指定非回环地址，且requirepass未设置时，自动启用保护模式。此时Redis拒绝所有外部连接，只允许127.0.0.1和::1。它的存在意义是防止裸奔——你忘记设密码，又没绑定外网IP，Redis不会暴露。但若你已设置bind 192.168.1.100，protected-mode自动失效，此时必须靠requirepass或防火墙保障安全。验证方法：注释掉bind行，protected-mode yes，启动后redis-cli -h 192.168.1.100 ping返回(error) DENIED Redis is running in protected mode...；若取消注释bind 192.168.1.100，同一命令返回PONG。

• port：端口冲突的静默失败
  port 6379是默认值，但若该端口被占用（如另一个Redis实例、Elasticsearch），Redis启动日志只会写# Warning: Could not create server TCP listening socket *:6379: bind: Address already in use，然后继续启动，但netstat -tuln | grep :6379无监听，redis-cli ping报错Could not connect to Redis at 127.0.0.1:6379: Connection refused。排查步骤：sudo lsof -i :6379查占用进程；sudo ss -tuln | grep :6379确认监听状态；若用supervisor管理，需在supervisord.conf中加autorestart=true，否则启动失败后进程退出，supervisorctl status显示FATAL Exited too quickly。

注意：生产环境严禁bind 0.0.0.0+protected-mode no+requirepass为空的组合。这是典型的“蜜罐配置”，扫描器一扫一个准。正确姿势是bind 192.168.1.100（业务网段IP） +protected-mode yes（冗余防护） +requirepass your_strong_password（主防线）。

3.2 持久化配置：RDB与AOF的协同策略与磁盘IO真相

Redis持久化不是“二选一”，而是RDB快照与AOF日志的分层备份体系。理解它们的触发时机、文件结构和恢复优先级，才能设计出可靠的灾备方案。

• RDB（Redis Database）：内存快照的时空锚点
  save 900 1表示“900秒内至少1个key变更则触发BGSAVE”。但BGSAVE是fork子进程复制父进程页表，若Redis内存占用10GB，fork时内核需复制10GB页表（约80MB），期间主进程暂停（INFO stats中latest_fork_usec显示耗时）。在机械硬盘上，dbfilename dump.rdb写入可能耗时数分钟，期间client-output-buffer-limit可能触发客户端断连。优化方案：save ""禁用自动RDB，改用redis-cli bgsave在低峰期手动触发；或用save 300 10000（5分钟1万个变更）降低频率。RDB文件是二进制压缩流，redis-check-rdb dump.rdb可校验完整性，redis-rdb-tools可解析key分布。

• AOF（Append Only File）：操作日志的实时保险
  appendonly yes开启AOF后，每个写命令追加到appendonly.aof。但appendfsync everysec（默认）并非“每秒刷盘”，而是内核每秒调用fsync()，但Redis先写入内核缓冲区（buffer cache）。这意味着断电可能丢失1秒数据。appendfsync always则每次写都fsync，性能下降50%，仅适用于金融级零容忍场景。appendfsync no依赖内核定时刷盘（通常30秒），风险最高。AOF重写（BGREWRITEAOF）会生成新文件，但旧文件仍被占用，直到重写完成才替换——ls -l /var/lib/redis/可见appendonly.aof.1234567890.base.rdb（重写中）和appendonly.aof（旧）并存。

• RDB+AOF混合持久化：Redis 4.0+的终极方案
  aof-use-rdb-preamble yes启用后，AOF文件前半部分是RDB格式快照，后半部分是增量AOF命令。重启时先加载RDB部分（快），再重放AOF部分（准），恢复速度比纯AOF快3倍。但需注意：redis-check-aof --fix appendonly.aof修复时，若文件损坏在RDB段，整个文件作废；若在AOF段，可截断损坏部分后重放。生产环境强烈推荐此模式，redis.conf中必须同时配置save规则（为AOF重写提供基础快照）和appendonly yes。

实操心得：监控INFO persistence中rdb_last_bgsave_status:ok和aof_last_bgrewrite_status:ok，任一为err即告警。aof_current_size与aof_base_size比值超auto-aof-rewrite-percentage 100时触发重写，但auto-aof-rewrite-min-size 64mb限制最小重写尺寸，避免小文件频繁重写。曾有用户AOF文件达2GB，重写耗时18分钟，期间磁盘IO 100%，导致MySQL慢查询激增——解决方案是config set auto-aof-rewrite-percentage 200，拉长重写周期。

3.3 内存管理：maxmemory策略与eviction算法的实战表现

当Redis内存触及上限，maxmemory策略决定“杀谁保谁”。这不是理论算法，而是直接影响业务可用性的生死抉择。

• maxmemory：硬限制还是软限制？
  maxmemory 2gb是绝对上限，但Redis实际内存占用常超此值——INFO memory中used_memory_human:2.15G，因为maxmemory只限制Redis键值数据，不包括redisServer结构体、客户端缓冲区、AOF缓冲区等。used_memory_rss_human:2.45G才是真实物理内存。若used_memory_rss持续超maxmemory20%，应检查client-output-buffer-limit是否过小导致缓冲区堆积。

• maxmemory-policy：六种淘汰策略的业务语义

  • noeviction（默认）：内存满时写操作报错(error) OOM command not allowed when used memory > 'maxmemory'，读操作正常。适合缓存+数据库双写场景，宁可写失败也不丢数据。
  • allkeys-lru：从所有key中淘汰最近最少用的。适合通用缓存，但可能误杀高频但冷数据（如用户画像大对象）。
  • volatile-lru：只淘汰设置了EXPIRE的key。适合Session缓存，保证永不过期的配置数据安全。
  • allkeys-random/volatile-random：随机淘汰。性能最好，但业务不可预测，慎用。
  • allkeys-lfu（Redis 4.0+）：淘汰最不常使用的key。INFO keyspace中keyspace_hits和keyspace_misses比值反映LFU有效性，比值>10说明命中率高，LFU合适。
  • volatile-ttl：淘汰剩余TTL最短的key。适合临时令牌（JWT），自然过期优先。

• lfu-log-factor与lfu-decay-time：调优LFU的黄金参数
  LFU算法用24位计数器记录访问频次，但需衰减避免“历史热门key永远不被淘汰”。lfu-log-factor 10（默认）表示计数器增长对数化（访问10次≈计数器+1），lfu-decay-time 1（默认）表示每分钟将计数器右移1位（衰减50%）。若业务有突发流量（如秒杀），应调大lfu-log-factor至100，让计数器增长更平缓；若key生命周期短（<1小时），调小lfu-decay-time至0.1（6秒衰减一次）。

提示：用redis-cli --bigkeys扫描大key，redis-cli --hotkeys（Redis 6.0+）识别热点key。若INFO stats中evicted_keys持续增长，说明内存压力大，需扩容或优化maxmemory-policy。曾有电商项目用allkeys-lru，促销时商品详情页缓存（1MB/key）被大量淘汰，latency doctor显示command延迟飙升——改为volatile-lru，给详情页key加EXPIRE 3600，问题解决。

4. 实操过程：从零开始的全平台安装与配置验证

4.1 Linux源码编译安装（Ubuntu 22.04/Debian 12/CentOS 7/AlmaLinux 9）

4.1.1 环境准备与依赖安装

不同发行版依赖包名差异巨大，必须按表操作，否则make报错fatal error: jemalloc/jemalloc.h: No such file or directory：

注意：CentOS 7默认GCC 4.8.5，低于Redis 7.2要求的6.0，需升级：sudo yum install -y centos-release-scl && sudo yum install -y devtoolset-11-gcc* && scl enable devtoolset-11 bash，然后gcc --version确认为11.2.1。

4.1.2 下载、编译与安装

# 创建工作目录 mkdir -p ~/redis-build && cd ~/redis-build # 下载源码（以7.2.5为例，替换为最新版） curl -O https://download.redis.io/releases/redis-7.2.5.tar.gz tar -xzf redis-7.2.5.tar.gz && cd redis-7.2.5 # 编译（关键参数：jemalloc + NUMA禁用 + TLS支持） make MALLOC=jemalloc CFLAGS="-O2 -march=native" LDFLAGS="-ljemalloc" EXTRALIBS="-ljemalloc" # 安装到/usr/local（需root） sudo make install # 验证安装 redis-server --version # 输出 Redis server v=7.2.5 sha=00000000:0 malloc=jemalloc-5.2.1 bits=64

4.1.3 配置文件定制与服务注册

# 创建配置目录和数据目录 sudo mkdir -p /etc/redis /var/lib/redis /var/log/redis sudo chown -R redis:redis /var/lib/redis /var/log/redis # 复制模板配置 sudo cp redis.conf /etc/redis/redis.conf # 编辑核心配置（nano /etc/redis/redis.conf） # 修改以下行： bind 192.168.1.100 127.0.0.1 # 绑定业务网段IP和本地 protected-mode yes # 保持开启 port 6379 # 默认端口 tcp-backlog 511 # 连接队列长度，内核net.core.somaxconn需>=511 timeout 0 # 客户端空闲超时，0表示永不超时 tcp-keepalive 300 # TCP保活，300秒发一次探测包 loglevel notice # 日志级别 logfile "/var/log/redis/redis.log" databases 16 # 数据库数量 save 900 1 # RDB保存策略 save 300 100 # save 60 10000 # stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes dbfilename dump.rdb dir /var/lib/redis # 数据目录 slave-serve-stale-data yes slave-read-only yes repl-diskless-sync no repl-diskless-sync-delay 5 repl-disable-tcp-nodelay no slave-priority 100 maxmemory 2gb # 内存上限 maxmemory-policy allkeys-lru # 淘汰策略 appendonly yes # 开启AOF appendfilename "appendonly.aof" appendfsync everysec # AOF刷盘策略 no-appendfsync-on-rewrite no auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb aof-load-truncated yes aof-use-rdb-preamble yes # 混合持久化 lua-time-limit 5000 slowlog-log-slower-than 10000 slowlog-max-len 128 latency-monitor-threshold 0 notify-keyspace-events "" hash-max-ziplist-entries 512 hash-max-ziplist-value 64 list-max-ziplist-size -2 list-compress-depth 0 set-max-intset-entries 512 zset-max-ziplist-entries 128 zset-max-ziplist-value 64 hll-sparse-max-bytes 3000 stream-node-max-bytes 4096 stream-node-max-entries 100 activerehashing yes client-output-buffer-limit normal 0 0 0 client-output-buffer-limit slave 256mb 64mb 60 client-output-buffer-limit pubsub 32mb 8mb 60 hz 10 aof-rewrite-incremental-fsync yes

4.1.4 systemd服务配置与启动

# 创建systemd服务文件 sudo tee /etc/systemd/system/redis-server.service << 'EOF' [Unit] Description=Advanced key-value store After=network.target [Service] Type=notify User=redis Group=redis ExecStart=/usr/local/bin/redis-server /etc/redis/redis.conf ExecStop=/usr/local/bin/redis-cli -h 127.0.0.1 -p 6379 shutdown Restart=always RestartSec=10 TimeoutStopSec=30 LimitNOFILE=10032 MemoryLimit=2G ProtectSystem=full ProtectHome=yes NoNewPrivileges=yes [Install] WantedBy=multi-user.target EOF # 重载systemd配置 sudo systemctl daemon-reload # 启动并设开机自启 sudo systemctl start redis-server sudo systemctl enable redis-server # 验证状态 sudo systemctl status redis-server # 应显示 active (running) sudo journalctl -u redis-server -f # 实时查看日志

4.1.5 连接验证与基础测试

# 本地连接测试 redis-cli ping # 返回 PONG # 查看配置是否生效 redis-cli config get maxmemory # 返回 1) "maxmemory" 2) "2147483648" redis-cli info memory | grep -E "(used_memory_human|maxmemory_human)" # 确认内存限制 # 写入测试数据 redis-cli set test_key "hello_redis" redis-cli get test_key # 返回 "hello_redis" # 检查持久化文件 ls -lh /var/lib/redis/ # 应有 dump.rdb 和 appendonly.aof

4.2 Windows平台安装：WSL2 + Ubuntu 22.04（推荐）与原生兼容层对比

4.2.1 WSL2方案：最接近原生Linux的体验

WSL2是Windows 10/11内置的轻量级虚拟机，运行真实Linux内核，完美支持Redis所有特性。

• 安装WSL2
  以管理员身份运行PowerShell：

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

• 安装Ubuntu 22.04
  Microsoft Store搜索“Ubuntu 22.04”，安装后首次启动设置用户名密码。

• 在WSL2中安装Redis
  完全复用4.1节Linux流程，唯一区别是bind地址：WSL2虚拟网卡IP（如172.28.128.1）可通过ip addr show eth0 | grep inet获取，bind需包含此IP，Windows宿主机才能通过redis-cli -h 172.28.128.1 -p 6379 ping连接。

• 端口转发（让Windows程序直连localhost）
  WSL2默认不映射端口，需在Windows PowerShell中执行：

  # 获取WSL2 IP $wsl_ip = wsl hostname -I | ForEach-Object {$_.Trim()} # 添加端口转发 netsh interface portproxy add v4tov4 listenport=6379 listenaddress=127.0.0.1 connectport=6379 connectaddress=$wsl_ip # 查看规则 netsh interface portproxy show v4tov4

  此后redis-cli -h 127.0.0.1 -p 6379 ping即可。

4.2.2 原生Windows兼容层：tporadowski/redis（仅限开发测试）

此方案基于Windows Subsystem for Linux (WSL) 的早期兼容层，非官方支持，仅用于学习。

• 下载与安装
  访问GitHub releases（https://github.com/tporadowski/redis/releases），下载Redis-x64-7.2.5.msi，双击安装，默认路径C:\Program Files\Redis。

• 配置与启动
  编辑C:\Program Files\Redis\redis.windows.conf：

  bind 127.0.0.1 ::1 port 6379 logfile "C:\\Program Files\\Redis\\redis.log" dir "C:\\Program Files\\Redis" maxmemory 1gb

  启动服务：redis-server "C:\Program Files\Redis\redis.windows.conf"或安装为Windows服务：redis-server --service-install "C:\Program Files\Redis\redis.windows.conf" --service-name Redis.

• 致命缺陷

  • 不支持RedisJSON、RedisSearch等模块；
  • CONFIG REWRITE命令无效，配置修改需手动编辑；
  • INFO commandstats中cmdstat_eval统计为0，Lua脚本性能不可控；
  • 内存管理基于Windows Heap，无jemalloc优化，高并发下内存碎片严重。

提示：生产环境绝对禁用此方案。WSL2是Windows下唯一推荐的Redis运行环境。

4.3 Docker容器化部署：生产级配置与卷挂载最佳实践

4.3.1 基础Docker运行与配置挂载

# 创建配置目录 mkdir -p ~/redis-docker/conf ~/redis-docker/data # 复制redis.conf到conf目录，并修改： # bind 0.0.0.0 （容器内0.0.0.0即宿主机所有接口） # protected-mode no （容器网络隔离，无需保护模式） # requirepass your_secure_password # dir /data （与-v挂载路径一致） # appendfilename "appendonly.aof" # appendonly yes # 运行容器 docker run -d \ --name redis-prod \ --restart unless-stopped \ -p 6379:6379 \ -v ~/redis-docker/conf/redis.conf:/usr/local/etc/redis/redis.conf \ -v ~/redis-docker/data:/data \ -e TZ=Asia/Shanghai \ --ulimit nofile=65535:65535 \ --memory=2g \ --cpus=2 \ --network host \ redis:7.2-alpine \ redis-server /usr/local/etc/redis/redis.conf

4.3.2 docker-compose.yml生产配置

version: '3.8' services: redis: image: redis:7.2-alpine container_name: redis-prod restart: unless-stopped ports: - "6379:6379" volumes: - ./conf/redis.conf:/usr/local/etc/redis/redis.conf:ro - ./data:/data:rw - ./logs:/usr/local/etc/redis/logs: