Redis 在 HomeLab 里可以做缓存或队列，但不要把它当主数据库。

\n
Redis 很容易被低估，因为它启动快、配置少、很多应用文档里只把它写成一个依赖服务。可在家庭服务器里，它到底只是缓存，还是承载队列、会话、限流状态，会直接决定持久化、内存上限和备份策略。我的原则很简单：Redis 可以提升速度，也可以承担短周期任务状态，但不要把唯一数据放进去。

先定义缓存和队列边界

纯缓存的特点是可以重建。比如页面缓存、热点查询结果、临时验证码计数，这些数据丢了会让服务短暂变慢，但不会丢业务事实。这样的 Redis 可以降低备份优先级，重启后自动回暖即可。队列和会话就不同了，任务正在执行、用户正在登录、后台流程依赖它们，突然丢失会造成状态错乱。

我会在维护记录里写明每个应用怎么使用 Redis：缓存、队列、会话、锁，还是混合使用。只写“依赖 Redis”没有排障价值。应用出问题时，如果知道 Redis 只做缓存，可以大胆重启；如果知道里面有队列，就要先看队列长度、消费者状态和持久化策略。

如果多个应用共用同一个 Redis，我会至少用不同数据库编号或 key 前缀区分，并把对应关系写下来。更稳的做法是核心服务单独实例，普通缓存共用实例，避免一个应用写爆内存影响全部服务。

连接权限也要收紧。Redis 不应该对浏览器或普通局域网设备开放，最好只在后端网络内被应用访问。

持久化不是默认越强越好

Redis 常见持久化有 RDB 和 AOF。RDB 像定期快照，恢复快，对磁盘写入相对克制，但可能丢掉最近一段时间的数据。AOF 记录写命令，恢复更细，但会增加磁盘写入和文件增长。家用 NAS 上跑 Redis，要结合磁盘类型、写入频率和数据价值选择。

如果 Redis 只做缓存，我可能不开 AOF，只保留必要的配置和重启策略。如果承载队列，我会倾向开启 AOF，并设置合理的 fsync 策略，避免每次写入都把低功耗设备拖慢。无论选哪种，都要理解它是在降低损失，不是在替代主数据库。

services:
  redis:
    image: redis:7
    command: ["redis-server", "--appendonly", "yes", "--maxmemory", "512mb", "--maxmemory-policy", "allkeys-lru"]
    volumes:
      - ./data:/data
    networks:
      - backend

内存限制必须显式写

Redis 最大的问题之一是“能吃多少吃多少”。HomeLab 上同一台机器可能还跑数据库、相册、自动化和反代，如果不给 Redis 设置 maxmemory，某个应用突发写入可能挤压其他服务。内存上限不需要很大，关键是要和实际用途匹配。

淘汰策略也要写清楚。纯缓存可以用 LRU 类策略，旧数据被挤掉没关系；队列和会话不适合随便淘汰，否则应用会出现很难解释的丢任务、掉登录。看到 Redis 内存上升时，我会先看 key 分布和过期时间，而不是第一反应加大内存。

不把 Redis 当主数据库

Redis 很快，但快不等于适合作为唯一事实来源。家庭服务里的账号、配置、文档、照片索引、账本记录，都应该落在数据库或文件系统里，并有明确备份。Redis 可以保存派生状态、临时状态和可恢复队列，但不能成为“只有这里有”的数据仓库。

排障时我会准备几条命令：redis-cli ping 确认可达，redis-cli info memory 看内存，redis-cli info persistence 看持久化，redis-cli dbsize 粗略看 key 数量。真正清理前先确认用途，FLUSHALL 这类命令在生产环境里要当高危操作处理。

备份和恢复按用途决定

Redis 的 ./data:/data 目录是否进入备份，要看里面是什么。如果只是缓存，备份价值不高；如果有 AOF 和队列状态，升级前至少要停服务复制一份，并记录当时应用任务是否清空。恢复以后也不是只看 Redis 能启动，而要看依赖它的应用是否能继续处理任务。

我希望 Redis 在家里保持小而清楚：内部网络访问、显式内存限制、持久化策略有理由、应用用途有记录。它是很好的加速层和队列组件，但主数据库的责任应该交给真正的数据库。边界清楚，Redis 才不会从“轻量依赖”变成最难解释的故障点。