RustFS分层存储：我是如何把成本砍掉70%还没被业务骂的

老板最近找我谈话，说存储预算又超了。我盯着账单一看，好家伙，几TB的半年前的日志文件，居然全躺在昂贵的NVMe盘上睡觉。

这不就是典型的“开着奔驰去买菜”吗？

很多团队都有这个毛病：为了那一点点所谓的“性能”，全上NVMe，反正钱是公司的。但作为技术负责人，心里得有本账。我们在RustFS的生产环境里折腾了一套分层机制，最后把成本干掉了70%，关键是业务方居然没察觉到。

今天就把这套“骚操作”摊开来聊聊。

一、不做分层的存储，都是把钱往水里扔

先看一眼我们某条生产线的真实数据，这很有代表性：

看到了吗？​60%的预算养着只有2%访问量的垃圾数据​。这谁顶得住？

以前用Ceph也搞过分层，那个配置复杂得像天书，而且一迁移数据，IO就打满，搞得业务投诉连连。RustFS在这方面确实有点东西，它搞数据的动静特别小。

二、RustFS这玩意儿是怎么干的？

RustFS的逻辑很直接：数据自己长腿，往便宜的地方跑。

它内部维护了一张“热力图”。只要符合两个条件——比如文件超过7天没动过，或者体积大于10MB，后台那个基于tokio​的协程就会悄悄把数据搬到HDD这种慢盘上，只在元数据里留个“小票”。

这事儿做得特平滑，就像你半夜偷偷把书房里的旧书搬到地下室，第二天早上起来，你觉得书房还是那个书房，只是地儿大了。

实测：省了钱，性能也没崩

我们对比了“全NVMe豪宅”和“RustFS混搭风”的表现：

​结论很明显​：除了极偶尔的P99长尾请求（通常是去读冷数据那一下），业务方根本不知道底层已经换成拖拉机盘了。

三、别整那些虚的，直接上配置

RustFS的配置风格我很喜欢，简洁、直接，不像某些项目配个文件要写半部小说。

编辑 config.toml​，我们定义两层：hot​（跑车）和 cold​（卡车）。

[tiers.hot]
path = "/data/nvme"
max_capacity = "10TB"
media_type = "nvme"

[tiers.cold]
path = "/data/hdd"
max_capacity = "100TB"
media_type = "hdd"

# 分层策略：让数据动起来
[policy.tiering]
enabled = true

# 热 -> 冷：打包带走
[[policy.rules]]
source = "hot"
target = "cold"
# 7天没理我，且个头够大，就滚去冷层
condition = "age > 7d && last_access > 7d && size > 10MB"

# 冷 -> 热：既然来了就别走了
[[policy.rules]]
source = "cold"
target = "hot"
# 只要被读一次，立马搬回来，别慢待了客人
condition = "access_count > 0"
priority = "high" 

这套逻辑很符合人的直觉：常用的供着，不用的扔库房，只要你喊一声，立马请回来。

四、别高兴太早，坑也是有的

虽然这招很香，但我们踩过的坑也不少，你们照着配的时候避一避。

坑1：小文件搬家也是灾难

刚开始我们没设大小阈值，结果几百万个几KB的小碎文件在NVMe和HDD之间来回倒腾，Inode直接爆炸，元数据服务器差点跪了。

​避坑指南​：千万别动小文件！size > 10MB​ 这个阈值是底线。小文件占点SSD空间就占了吧，搬运它的代价比空间本身贵多了。

坑2：别瞎压缩

为了省空间，我们在HDD层开了LZ4压缩。结果发现，对于jpg、mp4这种本来就已经压过的文件，CPU飙得老高，空间一点没少。

​避坑指南​：RustFS支持智能过滤，只对文本、日志压。别像个莽夫一样什么都压。

坑3：回滚风暴

有一次运营搞了个“历史数据全量回刷”，触发了几十TB的冷数据瞬间回流，热盘直接写爆，新来的热数据写不进去了。

​避坑指南​：一定要限流！把回流速度锁死。

[policy.bandwidth]
promote_rate_limit = "500MB/s" # 别把路堵死了，留点道给别人

五、最后说句实在话

做技术选型，不能光看“快不快”，还得看“贵不贵”。

RustFS这套分层方案，说白了就是用​便宜的大容量介质解决“放得下”的问题，用智能缓存解决“跑得快”的问题​。Rust语言这块的优势就体现出来了——底层控制力强，能把每一个字节的I/O都算计得清清楚楚。

如果你的集群数据量上了PB级，且冷热数据像我和老板的关系一样分明，别犹豫，赶紧上。省下来的钱，足够给团队每个人换把HHKB了，这难道不香吗？

以下是深入学习 RustFS 的推荐资源：RustFS

官方文档： RustFS 官方文档- 提供架构、安装指南和 API 参考。

GitHub 仓库： GitHub 仓库 - 获取源代码、提交问题或贡献代码。

社区支持： GitHub Discussions- 与开发者交流经验和解决方案。