先抛结论：冷热分离没有魔法。它只是承认一个残酷事实——你系统里99%的数据，这辈子可能都不会被访问第二次了。
但承认这个事实，需要勇气。因为做架构设计的本能是“我要把一切数据都放在最好的位置”。这念头会杀了你。
一、揭开伪装：冷热分离的本质是什么？
很多文章讲冷热分离，爱画三层架构图，左边热，右边冷，中间一条箭头。我看着就想笑。真实系统里，数据温度是连续的，不是开关。
真正的引擎是一个调度器。它只做一件事：预测下一次访问。预测准，热数据待内存，冷数据待磁盘。预测不准，就是雪崩。
类比一下。你的微信聊天记录可能几百个G，但你每天点的就那几个置顶对话框。冷热分离就是在系统里建一套自动置顶逻辑。但坑的是，它得自动判断谁会在下周变成你的新任老板，然后被疯狂置顶。这就有意思了。
二、热数据到底在热什么？从物理层看缓存命中
我们压测过一个金融风控系统。数据量100GB，其中热数据占比4.7%，却扛了91.2%的写和96.7%的读。
全量内存方案，需要80GB内存。用冷热分离，只需要18GB。剩下的82GB放在NVMe SSD上。压测结果：热数据内部命中率99.3%，整体请求P99延迟从128ms降到14ms。为什么降这么多？因为NVMe顺序读延迟0.1ms，随机读却是20ms，差了200倍。冷热分离本质上是把SSD的随机读变成顺序读——冷数据永远冷，所以它的随机读被抹平了。
但是，数据不会自己说是热还是冷。你得用数学模型猜。业界有LRU、LFU、LIRS这些算法。我们的经验是：纯LRU在冷热分离场景就是个灾难。它只看最近一次访问，导致周期性扫描任务天天把冷数据踢进内存，再弹出去，缓存全乱套。
后来我们改成基于时间戳衰减的加权频率统计，每个数据项维护一个分数，每次访问加上当前时间权重，定期衰减。这才稳住了。听起来简单，但细节是魔鬼。
三、性能压测：别跟我谈理想，给我数字
测试环境：单机8核16线程，64GB内存，数据总量80GB，读写比例7:3。我们对比三组：全量内存（小数据）、纯SSD、冷热分离。注意全量内存因为内存放不下，只能把数据缩到20GB，但冷热分离组和纯SSD组都用80GB实际数据。
结果如下（已脱敏）：
纯SSD：P99=180ms，吞吐1.2万 TPS。冷热分离：P99=15ms，吞吐4.3万 TPS。全量内存（20GB数据）：P99=12ms，吞吐4.8万 TPS。看到没？冷热分离用了不到全量内存一半的容量，换来了几乎一样的性能。而纯SSD彻底被吊打。
更关键的是成本。80GB内存和18GB内存+80GB NVMe，价格差一个数量级。你愿意为那个P99的3ms差距多付10倍的钱吗？我是不愿意。
四、落地踩坑记：三个坑，每个都能让你周末泡汤
坑一：温度阈值设得太死板。我们最初定了一个静态规则：30天没被访问，就降冷。结果有个统计任务，每天凌晨跑一次，专门访问几十天前的数据，导致每天凌晨缓存击穿，P99飙到3秒。怎么办？把阈值从时间改成速度。用指数衰减计算访问间隔的滑动平均，如果某数据最近两次访问间隔越来越短，就保持热状态。实质是：温度是频率的导数，而不是颜色。
坑二：冷数据突然回温。你以为冷数据永远冷？不。一旦发生热点事件，陈年数据被狂扫，缓存全空，请求全部砸到SSD上，系统直接跪了。我们一开始用互斥锁避免击穿，结果锁粒度过大，死锁。最终方案：分布式限流 + 异步预取。当检测到某个冷分区访问量在短时间内翻倍，就提前把该分区的前N条数据加载进热区，而不是等请求失败再补救。
坑三：迁移过程中的一致性。降冷时数据还在写怎么办？直接搬会丢更新。我们试过加锁，但性能掉一半。最后用双写 + 位图标记：写操作同时落到热区和冷区，等冷区确认后，再清除热区并更新位图。位图本身的原子更新用版本号控制。这个坑不深，但特别容易出错。版本号没对齐，你会同时读到两份数据。
五、最佳实践：我们最后是怎么落地的
路径很清晰，但每一步都有反模式。具体如下：
第一步：做访问日志分析。统计每个数据的访问间隔分布，画出温度曲线。如果发现90%的访问集中在5%的数据上，恭喜，冷热分离适合你。如果不是，劝你放弃。
第二步：选介质。热区用DRAM或傲腾持久内存（如果你有钱），温区用NVMe，冷区用SATA HDD或对象存储。别反着来。
第三步：写调度器。我们实现了分层LRU：第一层用频率衰减排序，第二层用LRU处理短时间突发。调度器每30秒扫描一次热区，把温度降级的数据移出去。注意，迁移一定要批量，用异步DMA，否则同步I/O会卡爆。
第四步：做回温预案。上面的坑二必须提前设计，否则上线第一个月就会出事故。我们的经验是：冷分区必须维护一个粗粒度的访问计数器，一旦计数器超过阈值，立即触发预取。
最后，压测时一定要用真实访问模式。用随机数据压测，你会得到一份完美的假报告。
