2026-08-12 18:45:59 分类：科技
说实话，存储分层这词儿，搁十年前还是极客圈的黑话，现在呢，每家云厂商都在喊……但喊得多不等于懂的多。
先别急着上架构图。懂行的都知道，分层这事儿玩的是延迟差。DDR4内存延迟80纳秒，NVMe固态盘呢，80微秒，再往下，SATA机械盘——哎呀，12毫秒。你掰着指头算算，差了三个数量级还多。所以聪明人把数据分层放，理论上是完美解。
但完美解为什么总是输给现实？因为……热度预测是个骗局。
一、热度是什么？不是你数数就行
一、热度是什么？不是你数数就行
我见过太多系统，统计一下访问次数，然后把次数多的放SSD，少的放HDD。然后就被打脸了。
为什么？假设有个数据块，今天被访问了10000次——但是是某个定时任务凌晨3点全量扫描扫到的。你把它搬到SSD，第二天那任务又不跑了，这块数据就变成了“伪热点”。更操蛋的是，搬移过程中，那10000次访问还在产生锁等待，整个系统的性能曲线像过山车。
所以，真正要用的热度算法不该是简单计数。我们后来用了一种**指数衰减加权**。每访问一次，热度加1，但每隔一段时间就乘以一个衰减因子，比如0.99。这样，峰值访问会因为时间指数级消退。对于持续稳定访问的数据，热度才会上涨。就这么一个公式，伪热点直接减少了60%以上。
总结成一句话：热度是趋势，不是快照。
二、把数据迁移看成一种IO调度
别把分层迁移当成背景任务。实际上，每次迁移都是一次额外的读写，如果处理不好，它比业务IO本身还伤。
专门给个数据对比。我们在80台机器上压测。传统分层方案（周期性扫描全量数据，抽取冷热块）：每次周期耗时45分钟，期间业务IOPS下降28%。而改进后的方案（基于概率的分桶迁移，把数据按大小和访问模式分成12个桶，分别独立迁移）：单次迁移耗时压到9分钟，业务IOPS波动只有5%。差距大吧？本质就是从“全部排队”变成了“错峰并发”。
还有一个技巧，迁移时**先写日志后搬数据**。就像你搬家，先列个清单，再动家具。我们用类似Write-ahead logging的机制，先记下“要从A搬到B”，然后批量拷贝，最后更新映射。万一中途崩了，重启后扫日志，接着搬，不用回滚。工程上这叫“可断点续传”。
存储分层热冷数据迁移日志流程图
三、三个值得记下来的坑
第一，**别让元数据成为瓶颈**。分层系统里，元数据要记录每个块的层级和迁移状态。如果元数据都放内存，那内存不够用；放磁盘，查询又太慢。我们的解法是两级元数据——热块元数据放内存，冷块元数据压缩后存SSD，并做缓存。这样90%的元数据查询落在内存，剩下的才走SSD。
第二，**数据迁移要留出“喘息带宽”**。如果你把整个系统跑满，再迁移数据，那IO都会堵死。我们设定，迁移IO不得超过总IO预算的15%，并且可以根据时段的业务负载自动调整。比如白天压到5%，凌晨放到25%。这个比例怎么定？我是靠踩坑踩出来的：超过20%，就经常超时。
第三，**分层不能只看数据访问，还要看数据生命周期**。比如日志数据，写入后几乎不会变，但近期可能需要经常读取，过了几天就再也不读。这个“时间演替”特性必须被模型捕捉。我们用了一个基于时间轮的热度衰减，每个数据块有个“日历”，记录了未来的可能访问窗口。简单说，历史数据在“注定变冷”之前，先预降级，而不是等它凉透了再搬。
最后说一句，存储分层不是目的，而是手段。检验你的分层做得好不好，就看用户能不能感觉到。要是哪天运维来报“我们迁移任务又跑挂了”，那你的分层一定有问题。
存储架构分层示意图高清
免责声明：市场有风险，选择需谨慎！此文仅供参考，不作买卖依据。如有侵权请联系删除。
文章名称：存储分层：从缓存到QLC，那些你以为的“热”往往不是真的热
文章链接：https://www.lfdjt.com/info_23_8420.html
