怎么在tmpfs中运行高频交易缓存应用以获取极致零延迟IO-Docker-PHP中文网

tmpfs通过将高频交易应用的热数据读写路径（如行情快照、订单簿状态）全部落于纯内存挂载点，彻底消除磁盘i/o等待，实现微秒级确定性低延迟；落地需四点强约束：精准对齐应用目录挂载、显式限定size并留15%~20%余量、禁用swap、配合mmap+大页降低页表开销。

高频交易缓存应用对 io 延迟极度敏感，微秒级抖动都可能影响成交优先级。tmpfs 本身不能直接“运行应用”，但它能为应用提供零磁盘路径、纯内存的临时数据落点——这才是实现极致低延迟 io 的关键支点。核心不是把应用塞进 tmpfs，而是让应用所有热数据读写路径（如行情快照缓存、订单簿中间状态、预计算索引）全部落在 tmpfs 挂载点上，绕过页缓存外的文件系统栈与块设备调度。

必须明确：tmpfs 不降低 CPU 指令延迟，也不加速网络收发；它只消除「磁盘 I/O 等待」这一确定性高延迟环节。

以下四点是实际落地中不可妥协的操作重点：

挂载路径需与应用逻辑强对齐
不要笼统挂载 /tmp。应识别应用真实高频写入目录，例如：
--tmpfs /app/cache:rw,noexec,nosuid,size=2g,mode=0750（对应行情缓存根目录）
--tmpfs /app/ob-state:rw,noexec,nosuid,size=512m,mode=0700（对应订单簿内存映射区）
避免挂载点被其他低频或调试日志误用，防止 inode 或内存碎片干扰。
size 必须显式限定，且留 15%~20% 余量
高频交易场景下，缓存增长具备突发性（如开盘瞬间行情洪峰）。若未设 size=，内核默认上限为 min(50% RAM, 无硬限)，极易触发 OOM Killer 杀死整个容器（注意：不是仅 kill 进程，是整个 cgroup 内存子系统崩溃）。
实测建议：按历史峰值用量 × 1.3 设置，并通过 docker stats --no-stream --format "{{.Name}}\t{{.MemUsage}}" 持续验证。
禁用 swap 对高频交易是必要选择
虽然 tmpfs 支持交换，但 swap I/O 会引入毫秒级不可预测延迟，彻底违背“零延迟”目标。必须确保：
宿主机 swap 已关闭（swapoff -a），或在挂载时强制禁止换出：
--tmpfs /app/cache:rw,noexec,nosuid,size=2g,mode=0750,mpol=prefer:0（绑定到 NUMA node 0 并禁 swap）
配合 mmap + MAP_HUGETLB 使用，消除页表遍历开销
应用代码中，对 tmpfs 文件应使用大页内存映射：
```
int fd = open("/app/cache/tickbuf", O_RDWR | O_CREAT, 0600);
madvise(addr, size, MADV_HUGEPAGE); // 建议启用
void *addr = mmap(NULL, size, PROT_READ|PROT_WRITE,
                   MAP_SHARED | MAP_HUGETLB, fd, 0);
```
此方式跳过标准 read/write 系统调用路径，实现用户态直写页缓存，实测可再降 300–800 ns 延迟。

最后提醒：tmpfs 只解决存储侧延迟。真正端到端零延迟还需配套——CPU 绑核（--cpuset-cpus）、中断亲和（IRQ balance 调优）、禁用 CPU 频率调节（performance governor）、内核旁路（如 DPDK 或 AF_XDP 处理行情网络包）。tmpfs 是其中确定性最强、见效最快的一环，但绝非孤岛。