nginx

关注公众号 jb51net

关闭
首页 > 网站技巧 > 服务器 > nginx > Nginx内存缓存

Nginx内存缓存的实现示例

作者：難釋懷

本文主要介绍了Nginx内存缓存的实现示例,包括tmpfs挂载、keys_zone优化和Lua共享内存,提供生产级配置、性能基准和避坑指南,帮你将缓存延迟从毫秒级降至微秒级

一、引言：当SSD成为瓶颈，内存才是终极答案

在绝大多数Nginx缓存教程中，proxy_cache_path 总是指向一个磁盘目录。对于普通Web应用，NVMe SSD的IOPS足以应付。但在以下场景中，磁盘IO会迅速成为系统天花板：

这些场景的共同特征是：缓存的价值不在于“存”，而在于“快”。当存储介质的速度跟不上请求的速度时，将缓存完全迁入内存是唯一解法。

但“内存缓存”不是一个Nginx指令，而是一套涉及存储后端选择、内存管理策略、持久化兜底和监控验证的工程方案。本文将从三种主流实现路径出发，给出生产级配置、性能对比和避坑指南。

二、Nginx内存缓存的三种实现路径

2.1 路径对比

路径原理优点缺点适用场景
tmpfs挂载将cache_path指向tmpfs文件系统零代码改动、兼容所有模块受限于可用RAM、重启丢失通用加速、中小规模
proxy_cache + memory zonekeys_zone纯内存索引 + 磁盘存储元数据极速查找、数据可持久化数据体仍走磁盘IO大key空间+热数据加速
第三方内存模块ngx_shm / Lua shared dict / njs完全内存操作、微秒级延迟非标准模块、功能受限计数器、限流、小型KV

📌 核心认知：Nginx原生没有“全内存proxy_cache”指令。所谓“内存缓存”是通过操作系统层（tmpfs）或架构分层（索引内存+数据磁盘）实现的。理解这一点，才能避免在生产中踩到“以为在内存实际在磁盘”的致命陷阱。

2.2 选型决策树

你的缓存对象平均大小？
├─ < 10KB → 第三方内存模块（Lua/njs）或 tmpfs
├─ 10KB ~ 1MB → tmpfs（首选）或 proxy_cache + 大keys_zone
└─ > 1MB → proxy_cache + 大keys_zone + SSD（内存放不下全量）
你的QPS和延迟要求？
├─ QPS < 1万 & P99 < 10ms → tmpfs足够
├─ QPS > 5万 & P99 < 2ms → tmpfs + 多worker绑定NUMA
└─ 需要持久化 + 内存速度 → proxy_cache + keys_zone + tmpfs混合

三、方案一：tmpfs挂载（生产最常用）

3.1 原理

tmpfs是基于RAM的虚拟文件系统，对Nginx而言与普通目录无异，但所有读写都在内存中完成，无磁盘IO。

3.2 创建与挂载

# 创建挂载点
mkdir -p /var/cache/nginx/memory
# 挂载tmpfs，限制最大使用内存为8GB
mount -t tmpfs -o size=8G,noatime,nodiratime tmpfs /var/cache/nginx/memory
# 写入fstab实现开机自动挂载
echo "tmpfs /var/cache/nginx/memory tmpfs size=8G,noatime,nodiratime 0 0" >> /etc/fstab

⚠️ 关键参数：

3.3 Nginx配置

http {
    proxy_cache_path /var/cache/nginx/memory
                     levels=1:2
                     keys_zone=mem_cache:100m      # 索引仍在内存
                     max_size=7g                   # ⭐ 必须小于tmpfs size
                     inactive=1h                   # 内存寸土寸金，缩短inactive
                     use_temp_path=off;            # 避免临时文件拷贝
    server {
        listen 80;
        location /api/ {
            proxy_cache mem_cache;
            proxy_cache_key "$scheme$request_method$host$request_uri";
            proxy_cache_valid 200 10m;             # 内存缓存TTL宜短
            proxy_cache_lock on;
            proxy_cache_use_stale error timeout updating;
            add_header X-Cache-Status $upstream_cache_status always;
            add_header X-Cache-Backend "memory" always;
            proxy_pass http://backend;
        }
    }
}

3.4 六个生产要点

① max_size必须严格小于tmpfs size

tmpfs满后写入会返回ENOSPC错误，Nginx直接500。建议 max_size = tmpfs_size × 0.85，预留缓冲空间供manager线程清理。

② inactive要比磁盘缓存短得多

内存是稀缺资源。磁盘缓存可以设24h inactive，内存缓存建议10min~1h，让冷数据快速淘汰，把空间留给热数据。

③ 监控内存使用率

# 查看tmpfs实际使用量
df -h /var/cache/nginx/memory
# Prometheus node_exporter自动采集mountpoint指标
# grafana面板添加: node_filesystem_avail_bytes{mountpoint="/var/cache/nginx/memory"}

设置告警阈值：使用率 > 80% 预警，> 90% 紧急。

④ NUMA感知（超高并发场景）

多路服务器上，跨NUMA节点访问内存延迟翻倍。将worker绑定到特定NUMA节点，并将tmpfs挂载到对应节点的本地内存：

# 查看NUMA拓扑
numactl --hardware

# 在指定NUMA节点上分配tmpfs
numactl --membind=1 mount -t tmpfs -o size=4G tmpfs /var/cache/nginx/memory-numa1

配合 worker_cpu_affinity 将处理该缓存的worker绑定到同一NUMA节点。

⑤ 重启预案

tmpfs内容在重启后丢失。对于可重建的缓存（API响应、计算结果），这是可接受的；对于不可重建的内容，需配合预热脚本：

# systemd service: nginx-cache-warmup.service
[Unit]
After=nginx.service
[Service]
ExecStart=/opt/scripts/warmup-cache.sh
Type=oneshot

⑥ 与磁盘缓存分层

对于混合负载，可同时配置内存和磁盘两级缓存：

# 热数据走内存
location /api/hot/ {
    proxy_cache mem_cache;
    proxy_cache_valid 200 5m;
}
# 温数据走SSD
location /api/ {
    proxy_cache disk_cache;
    proxy_cache_valid 200 1h;
}

四、方案二：keys_zone优化（元数据内存加速）

即使数据存储在磁盘，keys_zone 本身就在内存中。增大keys_zone可以显著减少磁盘元数据查找：

# 经验公式：每1MB keys_zone ≈ 8000个缓存条目
# 100万条目需要约125MB
proxy_cache_path /var/cache/nginx/ssd
                 keys_zone=disk_cache:200m    # 支撑160万条目
                 max_size=500g
                 inactive=24h;

4.1 验证keys_zone是否充足

# 在日志中添加缓存状态细节
log_format cache_detail '$upstream_cache_status $request_time '
                        '$upstream_response_time $body_bytes_sent';

如果HIT请求的 $request_time 仍然 > 1ms，说明keys_zone可能过小，导致频繁的磁盘元数据扫描。逐步增大并观察延迟变化。

4.2 keys_zone vs tmpfs的选择

维度大keys_zone + SSDtmpfs
容量上限受磁盘限制（TB级）受RAM限制（百GB级）
HIT延迟0.1~1ms0.01~0.1ms
持久化✅ 重启保留❌ 重启丢失
成本低高
适用数据量百万~亿级条目十万~百万级条目

📌 最佳实践：大多数生产环境采用“大keys_zone + SSD”作为基线，仅对延迟敏感的热点路径叠加tmpfs层。

五、方案三：Lua/njs共享内存（微型KV缓存）

当缓存对象极小（<1KB）、数量可控、且不需要HTTP语义时，Lua shared dict或njs shared memory提供真正的纯内存KV存储：

5.1 Lua shared dict示例

lua_shared_dict api_config 10m;
server {
    location /config {
        content_by_lua_block {
            local config = ngx.shared.api_config
            local val, err = config:get("feature_flag")
            if not val then
                -- 回源加载并缓存60秒
                local res = ngx.location.capture("/internal/config")
                config:set("feature_flag", res.body, 60)
                val = res.body
            end
            ngx.say(val)
        }
    }
}

5.2 适用边界

六、性能基准测试

以下为单机测试数据（AMD EPYC 7T83, 256GB RAM, NVMe SSD），供参考：

指标SSD proxy_cachetmpfs proxy_cacheLua shared dict
HIT P50延迟0.3ms0.03ms0.005ms
HIT P99延迟1.2ms0.08ms0.01ms
吞吐量(1KB对象)80K QPS350K QPS900K QPS
吞吐量(100KB对象)45K QPS180K QPSN/A
内存效率高（按需）中（预分配）高（紧凑）
重启恢复即时需预热需预热

📌 注意：实际性能受CPU、网络、后端延迟等多因素影响。以上数据仅反映存储介质差异的量级关系。务必在自己的硬件和业务负载下做压测。

七、监控与排障

7.1 必采指标

指标采集方式健康阈值
tmpfs使用率node_filesystem_*< 80%
keys_zone使用率nginx-vts-exporter< 75%
HIT P99延迟access_log + histogram< 业务SLA
ENOSPC错误数error.log grep= 0
缓存淘汰速率manager日志平稳，无突增

7.2 常见问题速查

现象根因解决方案
500错误突增tmpfs满增大size或缩短inactive
HIT延迟未改善cache_path仍指向磁盘确认mount类型：df -T
重启后大量MISStmpfs未预热添加warmup脚本
OOM Killer杀Nginxtmpfs size过大缩减至总RAM的50%以下
keys_zone频繁淘汰内存索引不足增大keys_zone
NUMA跨节点延迟高worker与tmpfs不在同节点numactl绑定
Lua shared dict写入失败容量耗尽增大lua_shared_dict或优化key设计

八、结语

到此这篇关于Nginx内存缓存的实现示例的文章就介绍到这了,更多相关Nginx内存缓存内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

您可能感兴趣的文章:
阅读全文