亚马逊AWS官方博客
Amazon FSx for OpenZFS 存储方案深度解析：邮件系统优化实践
 |
引言：传统架构的挑战与云原生方案转型
在移动游戏行业，玩家互动系统是用户留存的核心要素。其中经典场景之一是平台部门每日需处理数千万封包含游戏道具、社交通知等内容的玩家邮件。然而，基于 RDS MySQL 的传统解决方案在业务快速增长中显现出以下关键瓶颈：
- 容量瓶颈：邮件附件大小差异显著（10KB-150KB），采用关系型数据库 BLOB 存储模式导致空间碎片化严重，存储利用率不足 50%；
- 性能波动：节假日活动期间瞬时高峰并发邮件量可能突增 20 倍，数分钟需要落地上百万封邮件，数据库 IOPS 峰值突破 20,000，P99 响应延迟由平均 50ms 攀升至 5000ms 以上；
- 成本失控：为应对峰值配置的高端实例（如 db.r5.4xlarge）在非高峰时段资源闲置率超过 70%。
针对以上痛点，AWS 技术团队协助某大型游戏客户启动存储架构改造项目，旨在通过 AWS 云原生存储服务实现弹性扩展、成本优化与毫秒级延迟。本文将深入解析 S3、EFS 及 FSx for OpenZFS 三大存储方案的技术选型逻辑，并通过真实压测数据和落地效果分享实战经验。
第一部分：场景分析与候选方案评估
1.1 生产环境特征拆解
数据特征
- 文件规模：日均处理 1,000 万封以上邮件，高峰时段需要有短时间处理 100 万封以上的能力。
- 文件大小：10KB（文本通知）至 300KB（含缩略图的奖励邮件）。
- 生命周期：热点数据集中于最近 3 天（访问占比 85%），90 天后进行过期清理。
访问模式
- 写密集型：玩家行为触发实时邮件生成（如战斗奖励）。
- 读密集型：90% 的读取动作集中于邮件到达后 24 小时内。
- 元数据操作：每秒 200 至 800 次文件状态更新（已读/领取）。
1.2 候选方案技术对比
从协议支持、性能指标、扩展模式三个维度进行初筛：
| 特性 | S3 | EFS | FSx for OpenZFS |
| 存储类型 | 对象存储 | 共享文件系统 | 高性能文件系统 |
| 访问协议 | REST API/SDK | NFS v4.0, v4.1 | NFS v3, v4.0, v4.1, v4.2 |
| 数据一致性 | 最终一致性 | 强一致性 | 强一致性 |
| 最大IOPS | 写入 3,500/前缀，读取 5,500/前缀 | 读取 55,000，写入 25,000 | 1+ million IOPS |
| 平均延迟 | 100-200ms | 3-10ms | 1-3ms |
| 参考文档 | S3 Performance Guide | EFS Performance Guide | FSx for OpenZFS Performance Guide |
初步结论
- S3 适用于冷数据归档，但其高延迟特性难以满足实时读写需求；
- EFS 的动态吞吐量特性适用于中等负载场景；
- FSx 在低延迟场景优势显著，但需审慎评估成本效益。
第二部分：成本与性能深度测试
2.1 成本建模（us-west-2 区域 / 月）
基准参数
- 存储数据量：1TB（保留 30 天）
- 日均处理数据量：4TB
- 平均文件大小：20KB
- 日均文件访问次数：4 亿次
| 收费项 | S3 | EFS | FSx for OpenZFS |
| 存储费用 | 1,024 GB x 0.023 USD = 23.55 USD | 1,024.00 GB per month (Standard storage) x 0.30 USD = 307.20 USD | 1,024.00 GB per month x 0.09 USD per month = 92.16 USD |
| 请求费用 | 200,000,000 PUT requests for S3 Standard Storage x 0.000005 USD per request = 1,000.00 USD (S3 Standard PUT requests cost) 200,000,000 GET requests in a month x 0.0000004 USD per request = 80.00 USD (S3 Standard GET requests cost) |
无 | 无 |
| 吞吐费用 | 无 | 100 MB/s per month = 292.80 USD | 320.00 Mbps x 0.52 USD per Month = 166.40 USD |
| 预估总成本 | 1,103.55 USD / month | 600.00 USD / month | 258.56 USD / month |
鉴于生产环境后期可能面临更高的并发需求，技术团队综合成本与性能指标，决定优先评估 EFS 与 FSx for OpenZFS 方案。
2.2 本地性能压测
使用 https://github.com/IAmSomeoneLikeYou/bmark_write 的 Rust 压测工具进行验证：
EFS 测试流程
1. 创建并挂载 EFS 文件系统，采用弹性吞吐模式
2. 在 2xlarge 实例上启动 4 线程写入 4 万个文件
FSx for OpenZFS 测试配置
1. 创建单可用区高可用模式实例，预置 10,000 IOPS 与 160MB/s 吞吐量
 |
2. 执行同规模压测
通过 CloudWatch 我们可以看到，Openzfs DiskWriteOperations Sum/Second 能够达到 15w IOPS。
 |
结论：在 NFS v4 协议下并发写入 4 万个文件时，FSx for OpenZFS 性能显著优于 EFS。
2.3 生产场景模拟测试
在测试环境中同步部署 EFS 与 FSx for OpenZFS，通过流量复现真实业务场景：
特征
- 高峰期队列积压约 100 万封邮件，单文件大小 10-50KB；
- 目录结构采用四级哈希分割：file_id % 8192 / 13 bits / 13 bits / 13 bits / file_id；
- 客户端分布式部署于 EKS 集群节点。
性能瓶颈发现
| 服务 | EFS | FSx for OpenZFS |
| 性能瓶颈 | 在弹性吞吐量模式下，随着 pod 数量的增加，文件的写入延迟也会增加，从 3 个 pod 提升为 9 个 pod，写入延迟变化为：p99 30ms -> 60ms，p90 20ms -> 30ms, p50 10ms -> 10ms（无变化），无法继续优化。 | 早期测试使用了 NFS v4.2 发现延迟并没有优于 EFS，在调整为 NFS v3 之后发现延迟缩短了一个数量级，控制在了 3ms 之内，确认在大量高并发小文件读写的场景中，使用 NFS v3 协议性能会更优于 v4.2。 |
最终方案：综合压测与场景验证，选定基于 NFS v3 协议的 FSx for OpenZFS 作为核心存储架构。
第三部分：关键经验总结
1. 协议适配性
在应对高并发千万级小文件,尤其是多级目录多次删除多次写入场景时，NFS v3 协议较 v4.2 版本展现出更优的性能表现。
2. 目录结构设计
避免在同一个顶层目录并发创建文件，受目录锁定和元数据开销影响随写入并发度增大写入延迟会大幅上涨，从顶级目录开始将写入分散可以避免此问题。
3. 性价比优化
采用 FSx for OpenZFS 替代原有 RDS MySQL 方案后，在整体性能保持不变的前提下，总成本降低约 70%，实现了综合效益突破。
4. 与 AWS 产品团队的技术协同
在目录层级超过 5000 个的特殊场景中，遭遇类似 openzfs/zfs#16254 的性能问题。通过扩展吞吐量提升内存缓存容量有效缓解 CPU 峰值压力，同时推动产品团队对 FSx 服务进行针对性优化。