中小型项目使用Redis，服务器内存分配多少合适？

对于中小型项目，Redis 服务器的内存分配并没有一个“万能”的固定数值，核心原则是：预留足够的安全缓冲（Headroom），避免触发 OOM Killer（系统强制杀进程）。

以下是针对中小型项目的具体建议和计算逻辑：

1. 核心结论：推荐配置比例

在大多数中小型场景下，建议将 Redis 的最大内存限制（maxmemory）设置为物理内存总量的 60% ~ 75%。

• 如果服务器仅运行 Redis：建议设置 maxmemory 为物理内存的 80%。
  • 剩余 20% 留给操作系统内核、文件系统缓存以及应对突发流量时的临时开销。
• 如果服务器还运行其他服务（如 Nginx, App Server, MySQL 等）：必须根据其他服务的预估内存占用进行扣除。
  • 公式：Redis MaxMemory = (总物理内存 - 其他服务预估内存) × 0.8

注意：千万不要设置 maxmemory 等于或超过物理内存总量。一旦达到上限且没有配置淘汰策略，Redis 会报错；如果操作系统层面内存耗尽，Linux 的 OOM Killer 可能会直接杀掉 Redis 进程，导致数据丢失或服务中断。

2. 具体场景估算参考

假设你的项目属于“中小型”范畴（例如日活用户数万至数十万，QPS 在几千以内），以下是几种常见配置的参考：

3. 关键配置与最佳实践

除了分配多少内存，如何管理这些内存同样重要：

A. 必须配置淘汰策略 (maxmemory-policy)

当内存达到 maxmemory 限制时，Redis 不能直接崩溃，必须配置合理的淘汰策略。

• 推荐策略：allkeys-lru 或 volatile-lru
  • allkeys-lru：从所有键中移除最近最少使用的键（适用于纯缓存场景，如商品详情、会话）。
  • volatile-lru：仅从设置了过期时间的键中移除（适用于需要保留某些关键数据的场景）。
• 不推荐：noeviction（默认值）。这会导致写入报错，不适合生产环境。

B. 监控内存碎片率

Redis 在频繁更新和删除键值对时，会产生内存碎片。

• 使用 INFO memory 命令查看 mem_fragmentation_ratio。
• 如果该值长期大于 1.5，说明碎片严重，可能需要重启 Redis 或调整 maxmemory-samples。
• 如果该值小于 1.0，说明内存不足，可能正在被交换（Swap），这会极大降低性能。

C. 持久化带来的额外开销

如果你开启了 AOF (Append Only File)，请注意：

• AOF 重写过程中，Redis 会复制一份内存数据到磁盘，这会瞬间消耗 双倍内存。
• 如果是中小项目且对数据实时性要求不是极致高，可以考虑关闭 AOF 或仅使用 RDB，或者确保物理内存有更大的余量（例如只占 60%）。

D. 小内存优化技巧

如果服务器内存非常紧张（如 2GB 以下）：

1. 压缩对象：Redis 会自动压缩短字符串和小整数，但要注意不要存储过大的 Value。
2. Hash 编码：尽量使用 Hash 结构存储对象（如用户信息），因为 Hash 结构在元素较少时会采用 ziplist（压缩列表）编码，比普通的 String 节省大量内存。
3. 避免 BigKey：单个 Key 过大不仅占用内存，还会阻塞主线程，造成读写卡顿。

4. 总结建议

对于中小型项目，最稳妥的操作步骤如下：

1. 评估需求：统计当前热数据的体积（通常通过测试环境压测得出）。
2. 预留空间：在预估体积基础上乘以 1.5 倍 作为理论最大值。
3. 硬件匹配：选择一台内存充足的服务器，确保 理论最大值 < 物理内存 × 0.7。
4. 配置参数：

   # 示例：8GB 机器，预留 2GB 给系统和其他服务，Redis 最大用 5GB
   maxmemory 5gb
   maxmemory-policy allkeys-lru

5. 持续监控：上线后观察 used_memory_human 和 evicted_keys，根据实际情况微调。

一句话建议：宁可让 Redis 提前开始淘汰旧数据（Lru），也不要让它撑爆内存导致进程被系统杀死。留足 20%-30% 的物理内存给操作系统是安全底线。