在将Redis迁移到容器环境时，许多团队只关注能否快速启动服务，却忽视了容器本身的无状态特性与Redis有状态需求之间的冲突。Redis依赖内存存储数据，同时可通过RDB或AOF方式将内容落盘，而Docker容器一旦被删除，其内部可读写层的数据将随之消失。因此部署方案必须从存储、资源、网络三个维度重新设计，才能保证服务既弹性又可靠。
数据持久化与存储卷挂载
Redis在容器中运行时，若直接使用容器默认存储层保存appendonly.aof或dump.rdb文件，当容器因版本升级、节点漂移或异常退出被重建，这些文件将不可恢复。正确做法是在启动容器时通过-v参数将宿主机目录或命名卷挂载到Redis的工作目录，例如/data。这样即使容器生命周期结束，持久化文件依然保留在宿主机上，下次启动重新挂载即可恢复数据。
除了简单的目录挂载，还需要关注文件系统权限与SELinux限制。在某些Linux发行版中，宿主机目录若未放开容器内redis用户的读写权限，会导致AOF写入失败并频繁报错。建议在挂载前用chown调整目录归属，或在docker run时指定--user参数。另外，命名卷（named volume）由Docker统一管理，避免了路径依赖，更适合跨主机编排场景，但仍需定期备份卷内容以防底层磁盘故障。
下面给出一个基础的docker run示例，演示如何挂载卷并开启AOF持久化：
docker run -d --name redis1 -v redis_data:/data -p 6379:6379 redis:7.0 redis-server --appendonly yes --dir /data
上述命令中redis_data为命名卷，容器退出后数据不丢。若使用docker-compose，可将卷声明写在volumes段，配合restart: unless-stopped策略，实现故障自恢复。需要强调的是，持久化只能降低丢失概率，不能替代异地备份，重要业务仍需定时将AOF文件同步到对象存储。
内存限制与最大使用量配置
容器平台通常会对单个容器设置内存上限，而Redis在设计时默认不会感知cgroup限制，它只看自身配置或宿主机物理内存。若未显式设置maxmemory，Redis可能持续分配内存直至超过容器限制，被Docker daemon以OOM方式强制杀死。为避免这一问题，必须在redis.conf或启动参数中明确maxmemory值，且应小于容器内存限制的百分之八十，预留给客户端缓冲与系统开销。
仅仅限制最大内存还不够，还需配套设置淘汰策略maxmemory-policy。常用策略包括allkeys-lru、volatile-lru和noeviction。若业务允许丢失部分缓存，可选LRU相关策略；若所有键都必须手动过期，则应选noeviction并在应用层控制写入量。以下片段展示在容器中通过环境变量覆盖配置的方式：
docker run -d --name redis2 -m 1g -v redis_conf:/usr/local/etc/redis redis:7.0 redis-server /usr/local/etc/redis/redis.conf --maxmemory 800mb --maxmemory-policy allkeys-lru
同时，Docker的-m参数设定了硬上限，当Redis逼近该值时内核会触发回收，若此时没有合理策略就会写入失败。因此资源限制与Redis内部策略必须协同。对于使用Kubernetes的场景，应配置requests与limits一致，防止节点超卖导致Redis被驱逐。监控方面，可借助redis-cli info memory定期采集used_memory指标，配合告警规则提前扩容。
网络暴露与安全访问管控
Redis默认监听6379端口且无需密码即可连接，这在容器桥接网络直接映射宿主机端口时极为危险。许多入侵事件源于开发者为方便调试将-p 6379:6379绑定到0.0.0.0，外部扫描器就能轻易写入恶意键值或执行FLUSHALL。部署时必须通过requirepass指令设置强密码，或仅将端口暴露在内部网络，借助Docker自定义网络实现服务间互访而无需开放宿主机端口。
除了密码保护，还可使用Docker的网络安全组与iptables规则限制源IP。例如创建专属bridge网络，仅允许应用容器接入，Redis容器不发布端口到宿主机。若必须对外提供，前置一个支持ACL的代理如Twemproxy或Redis Sentinel管理入口。以下代码展示如何建立隔离网络并限制发布：
docker network create redis_net docker run -d --name redis3 --network redis_net -v redis_data3:/data redis:7.0 redis-server --requirepass 'C7m9#pQ2' --appendonly yes
在该模式下，同一网络内的应用容器可通过服务名redis3访问，宿主机外部无法直接连接。若业务合规要求审计，可开启Redis的慢日志与命令审计，结合集中式日志收集。另外，应避免在容器中以root用户运行Redis，利用官方镜像内置的redis用户降低提权风险。综合来看，网络与安全配置是容器化Redis不可省略的一环，忽视它将使前面所有持久化与资源优化失去意义。