大讲堂
一、热度是什么？不是你数数就行
二、把数据迁移看成一种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%，就经常超时。 第三，**分层不能只看数据访问，还要看数据生命周期**。比如日志数据，写入后几乎不会变，但近期可能需要经常读取，过了几天就再也不读。这个“时间演替”特性必须被模型捕捉。我们用了一个基于时间轮的热度衰减，每个数据块有个“日历”，记录了未来的可能访问窗口。简单说，历史数据在“注定变冷”之前，先预降级，而不是等它凉透了再搬。 最后说一句，存储分层不是目的，而是手段。检验你的分层做得好不好，就看用户能不能感觉到。要是哪天运维来报“我们迁移任务又跑挂了”，那你的分层一定有问题。
作者|大讲堂
排版|大讲堂
审核|见微